Jupyter Blog - surveys

What you told us: results from the 2026 Jupyter User Experience and Product Enhancement Survey

2026-08-25T13:42:00+00:00

From time to time, Jupyter runs user surveys to understand how our communities use Jupyter technology (or alternatives) and how they feel about it. The Jupyter Foundation recently completed a user experience survey for 2026. It was open between 29 May and 29 June 2026, with 542 people providing answers. This post covers what we found, what you can do today about the most common problems, and where we are looking for proposals.

Each of the areas below rose to the top of pain points that users consistently felt. We would love to see applications in the 2026 Call for Proposals that address any of these areas by improving Jupyter technology. In some areas, there are already Jupyter or third-party open-source tools that address some of the issues, and we list them as a guide to readers who want to learn more.

About the responses: Three of the six questions were free text, and 246 people wrote something in at least one of them, some at considerable length. Writing several paragraphs about environment setup or version control at the end of a survey takes real time, and that detail shaped most of what follows. We want to extend our heartfelt appreciation to everyone who answered this survey, high-quality experience stories like this are crucial at shaping Jupyter’s priorities and technical direction.

Who answered

Two thirds of respondents (65%) use Jupyter for data science and analysis, and 55% use it in education. Smaller groups deploy Jupyter for others (14%), develop extensions (14%), or contribute to the open-source project (12%). These add to more than 100% because the question accepted multiple answers. See the Appendix below for a deeper dive into the respondents and the tools they reported using. Below we’ll focus on the pain-points and themes that were commonly reported, since those are the most actionable for our community to improve upon and learn from.

Common themes that people raised

We reviewed all 677 free-text responses and coded the recurring themes, cross-checking the coding against the source responses.

Environment and dependency management, and version control and collaboration, are the two largest friction themes, and between them account for 51 of the 246 people who wrote to us, with 7 raising both. Other themes follow closely: interface and editor parity (17 people), handling large data sets and performance (15), documentation and discoverability (14), respondents who use a different tool instead (13), deployment and multi-user operations (12), and security, authentication and compliance (6).

When we asked what is blocking people from using Jupyter more, 130 of 239 answers named something concrete, while 53 said that nothing is blocking them, either in a sentence or as a one-word “no”. Limited time and competing priorities appear throughout those 53 responses.

The Foundation is committed to finding ways to address these pain points across our community, and we’ll be exploring other ways to make progress in these areas in the coming months.

Environment and dependency management

This was the largest friction theme, raised by 32 people across 51 responses.

The responses concentrate in three sub-problems:

Installation and first run, and package and dependency management, account for 17 responses each.
Environment and kernel registration accounts for 13
Reproducing an environment on a second machine for 4.

What connects them is that the failures arrive early and are hard to diagnose from the error message alone. For example: an installation completes but the jupyter command cannot be found; packages install into one environment while the notebook runs a kernel from another; a course needs the same environment on thirty machines that nobody administers centrally. Each of these has a known cause, and in many cases, a known fix, but users struggle to find the right solution to these problems.

We welcome submissions in our Call for Proposals to improve upon these pain points! We’ve also listed a few open-source tools from Project Jupyter and the third-party ecosystem that partially address these challenges.

Open-source tools that partially address this problem:

From Project Jupyter:

JupyterLab Desktop bundles Python and JupyterLab in a single installer and removes most first-run failures. v4.6.2 was released recently.
JupyterLite and Binder avoid per-machine installation entirely, which is often the right answer for teaching.
python -m jupyter lab works when a pip install succeeds but the entry point is not on your PATH. This is a common cause of “command not found” straight after a successful install.
repo2docker fetches a git repository and builds a container image based on the configuration — useful for creating reproducible images for use with Binder or JupyterHub
%pip install and %conda install run inside a notebook and install into the environment the running kernel is actually using, which is usually what goes wrong when installing from a terminal

From third-parties:

better package installation from UI
- gator creates and manages conda environments from the JupyterLab interface
- package-manager browses and installs Python packages without leaving the interface
kernel per environment which encodes “lockfile”
- pyproject-local-kernel provisions kernels per environment for the project the notebook file resides in
- pixi-kernel Per-directory Pixi environments with multi-language Jupyter kernels
notebook itself can include requirements
- juv is CLI tool that encodes dependencies in the notebook using PEP 723 (inline script metadata) and creates ephemeral virtual environments for kernel execution
- juvio also encodes dependencies in the notebook using PEP 723 but also includes bespoke integration with jupyter kernel spec manager and a JupyterLab extension
better integration with other environment management tools
- nb-conda-kernels and nb-nebi-kernels provision kernel specs auto-discovered from all conda and nebi-tracked pixi environments respectively
- jupyterlab-launchpad replaces the launcher with one that has first-class support for kernels discovered from conda and nebi-tracked pixi environments
- jupyterhub-fancy-profiles allows JupyterHub users to select a Binder-like environment and build it at hub launch time

Several respondents asked for closer integration between Jupyter and environment managers, including a graphical option for people who do not work at a command line, which is part of what those extensions provide. A consistent environment and kernel story across package managers and operating systems still requires sustained work across several projects, and we would welcome proposals in this area. Another area where future work is needed is preventing the drift between server and kernel environments (join the discussion).

Version control and collaboration

This theme was raised by 26 people across 33 responses.

Git diffing and merging accounts for 13 responses, real-time collaboration for 9, sharing and publishing for 8, and review and commenting for 3.

The underlying cause is that the notebook format stores code, outputs and execution metadata in a single JSON document. Tools built to compare source line by line report changes that are technically accurate and hard to read: re-executing a cell without editing it can produce a large diff, and merges conflict on execution counts and output data rather than on anything a person wrote (which can be desirable when reproducibility is the primary goal, but less so when prioritizing iterative development). Reviewing a colleague’s notebook therefore costs more than reviewing an equivalent script, which pushes teams either toward exporting notebooks to scripts before review, or toward skipping review.

We welcome submissions in our Call for Proposals to improve upon these pain points! We’ve also sourced a few recommended tools within Jupyter and from third-parties that partially address these challenges, and list them below for readers that want to learn more.

Open-source tools that partially address this problem:

From Project Jupyter:

nbdime provides content-aware diff and merge that understands cells and outputs. Running nbdime config-git --enable --global once makes git diff on a notebook readable.
jupyterlab-git brings Git operations into the JupyterLab interface and uses nbdime for diffs.
jupyter-collaboration brings real time collaboration; it allows several people to edit the same notebook simultaneously and time-travel to older versions.

Third-party:

Jupytext pairs a notebook with a .py or .md file that diffs and merges like an ordinary source, which makes notebook changes reviewable in a normal pull request.
nbstripout tools remove most merge conflicts for teams that do not need outputs in version control. The community has produced at least three variants: nbstripout, the original; nbstripout-fast, a faster alternative; and fastai-nbstripout (no longer maintained). They differ in behaviour and performance, so pin whichever you adopt. We read this fragmentation as a consequence of the gap, and a single well-supported answer would be a reasonable thing to propose.

Most of the tools above ship separately from JupyterLab and have to be installed and configured before they help, which limits how many people find them. We are considering both closer integration of these tools into the default experience and approaches that reduce the underlying problem, and we would welcome proposals for either.

Review and commenting on notebooks remains the clearest gap. Nothing in the current open-source stack provides a way to leave a comment on a cell and resolve it later; that also works for colleagues who do not use GitHub.

The interface, and parity with editors

Seventeen people wrote about the interface, and their requests are concrete rather than architectural: completion as you type, a variable explorer, working drag and drop, faster scrolling in long notebooks, and a more modern appearance.

We welcome submissions in our Call for Proposals to improve upon these pain points! We’ve also sourced a few recommended tools within Jupyter and from third-parties that partially address these challenges (including a few JupyterLab plugins that directly solve the problem), and list them below for readers that want to learn more.

Open-source tools that partially address this problem:

From Project Jupyter:

JupyterLab Desktop. The project went through a period with little activity, which some respondents referred to. It now has active maintainers and regular releases, and v4.6.2 was published after the survey closed.
Jupyter Notebook v7 now includes multiple improvements covering features requested by respondents, inheriting them from JupyterLab; after reviewing the survey answers we improved the documentation to mention the variable explorer available in the debugger (which has basic support, while the plugin below has more in-depth support) and the opt-in as-you-type autocompletion.
jupyterlab-lsp adds better completion, jump-to-definition, signature help and diagnostics.

Third-party: the variable explorer people asked for, plus several conveniences carried over from mainstream editors.

jupyterlab-variableInspector and variable-inspector both provide the variable explorer that came up more than once
jupyterlab-quickopen jumps to a file by name.
jupyterlab-unfold gives a tree-style file browser.
jupyterlab-code-formatter formats code cells.
jupyterlab-favorites pins frequently used directories.
jupyterlab-vim for vim users
jupyterlab-search-replace for search and replace across file

Thirteen respondents told us they use another tool instead: VS Code, Google Colab, Spyder or Positron, marimo, or plain Python scripts. We are glad that support for Jupyter notebooks and kernels has landed in many editors and has inspired other notebook-based applications. Maintaining an open ecosystem where people can move between the tools that suit their workflow matters to us. For reactive execution in particular, ipyflow brings dataflow-aware execution inside the JupyterLab interface.

Artificial Intelligence

Twenty-four of the 246 people who wrote free text mentioned AI. Of those, 14 asked for more AI capability in Jupyter, 1 asked for it with explicit caveats, 3 objected to AI being a priority, and 5 mentioned AI (e.g. as a use case) but did not take a stance.

Three requests recur:

Explanation at the point of failure. Clearer error messages and guidance for people who are learning, including one request for a “fix code” action placed directly below an error.
Working with self-hosted and third-party models. Support for running against “own LLM-servers”, compatibility with proxy layers, and simpler installation of Jupyter AI, which one respondent described as too complicated to set up.
Help with libraries, and checking generated code. Finding relevant packages within a research field, and being able to validate generated code before running it against real data.

The objections are about prioritisation, and specifically that AI work displaces maintenance and work on features aimed at human users.

Over the past twelve months the Foundation has facilitated several rounds of AI workshops and summits, and more are planned. Anyone is welcome regardless of their stance. Working out how the project should respond to increasing AI usage in data analysis and teaching needs both positions in the room. Proposals through the funding process are welcome here too.

Other themes

Here we list a few more themes that showed up in the survey responses along with some open-source tools that can help as of August 2026.

Theme	People	What might help today
Performance with large data	15	Recent versions of JupyterLab/Notebook improve UI performance. Large outputs freezing the browser can be prevented by using visualisation and tabulation libraries that make use of rasterization and canvas renderers (e.g. plotly, ipydatagrid or newcomers like xy). Third-party extensions streamline work with large dataset in dedicated big data formats (e.g. jupyterlab-h5web for HDF5, NeXus, ANNData, etc; Arbalister for Parquet, CSV, Avro, ORC, SQLite, Arrow IPC).
Documentation and discoverability	14	Jupyter documentation and Discourse. We are aware that changelogs and breaking-change notes are missing or inconsistent across subprojects, and this needs addressing.
Deployment and multi-user operations	12	The Littlest JupyterHub for single-server teaching and Zero to JupyterHub on Kubernetes. batchspawner for Slurm and HPC, systemdspawner for resource limits and sandboxing. Third-party: jupyterhub-usage-quotas and jupyterhub-cost-monitoring.
Security, authentication and compliance (including accessibility)	6	JupyterHub authenticators cover most institutional identity providers, and Zero to JupyterHub documents TLS and network configuration. jupyterlab-a11y-checker is a UC Berkeley CDSS extension for assisting authors of extensions. New versions of Jupyter software include notable accessibility improvements: JupyterLab, myst-theme
Teaching and grading	8	nbgrader for assignment distribution and autograding, usually alongside JupyterHub.
Execution model and cell state	8	In IPython `%load_ext autoreload` followed by `%autoreload 2` gives hot reload while developing a package against a live kernel. Third-party ipyflow brings reactive execution to Jupyter interfaces.
Publishing and export	7	`jupyter nbconvert --to webpdf` produces PDFs without a LaTeX installation. Jupyter Book for longer documents and Voilà for dashboards. Third-party: Quarto.
Mobile and tablet access	3	No good answer today. Recent work on lumino is addressing certain limitations.
Non-Python kernels	3	Maturity varies by language. Specific bugs are best filed on the relevant kernel’s issue tracker, where they can be followed up.
Excel and spreadsheet interop	3	JupyterLab opens CSV and TSV files in a data grid without any extension. Third-party: jupyterlab-spreadsheet-editor makes CSV and TSV files editable in place, and jupyterlab-spreadsheet opens Excel workbooks read-only.

Submit a proposal

Most of what people asked for needs sustained work rather than a configuration change. The Jupyter Foundation’s Community Funding Proposals process is open through the 9th of September, 2026. Proposals do not need to come from existing maintainers, and you can propose work without intending to be the person who carries it out.

Larger changes may warrant a new Jupyter Enhancement Proposal, or completing work on an existing one. Both are in scope for community funding, and are expected to involve support and consensus building in the community.

Thank you

Once again, thank you to the 542 people that offered their time and expertise to provide responses to our user survey. For those interested in the 2026 Call for Proposals, we’d love to see submissions that address these pain points. Keep an eye open for future surveys, as they have a big impact on where Jupyter improves its technology moving forward.

Appendix

Here is some more information about the survey respondents and the kinds of tools they used in general. We share it below in case it helps provide context for the analysis above.

The data, and how to read it

An anonymized version of the dataset is available at jupyter.org/surveys (repo here: github.com/jupyter/surveys), together with the analysis notebook that produced every figure in this post, including its caveats and the checks that did not work.

Analysing the questionnaire turned up several problems worth fixing before reusing the questions, and worth taking into account when re-analysing the data: a question that asked for a single primary answer while accepting several, a list that mixed applications with libraries and server components, and a question that asked two things at once.

Around 6% of this dataset shows clear quality problems, rising to roughly 11% under a stricter definition that also counts respondents who selected every available option. We even had two self-identified AI assistants fill in the survey. We re-ran the headline figures with those responses removed and none of the percentages moved by more than a point.

Product-use numbers

We asked participants to note the Jupyter tools that they use, and share the results below. A caveat for this data: we learned that many Jupyter users do not easily distinguish between the many different tools in the “Jupyter Stack”, and respondents often only chose one tool while many were likely in-use (e.g. only choosing “IPython” but not choosing “Jupyter Server”, which is almost always used alongside IPython). We’ll try to improve our methodology to tease this out more effectively in the future, but share the data below for others.

To understand whether the above question was skewed by the effect of mistakenly only responding with one selection, while many selections were more appropriate, we broke down the answers to the above question by whether the respondent also selected at least one other option. Of 542 respondents, 303 ticked exactly one box.

Nearly half of all IPython/ipykernel selections came from people who ticked nothing else, which suggests that some respondents ticked the single item they recognised rather than enumerating everything they use. For example, jupyter-server usage should be equal or greater to that of JupyterLab and Notebook (while alternative servers such as jupyverse exist, adoption of these would not explain the gap). We would treat these percentages as reflecting name recognition at least as much as adoption. Which products are used together holds up better: among the 239 people who ticked more than one, Binder, JupyterHub, Jupyter Server, Jupyter Book and ipywidgets form a clear cluster.

Usage patterns

Just over half (53%) use Jupyter daily for more than thirty minutes, 15% once a day for shorter sessions, 17% weekly, and 16% monthly or less. The sample leans heavily toward regular users. The survey was open for a month, with almost all responses arriving in the final nineteen days.

Jupyter User Survey

2026-06-18T15:04:00+00:00

The Jupyter Foundation is excited to gather your feedback on the Jupyter user experience through a brief survey. If you had a magic wand, what would you change or add to Jupyter? Your insights are incredibly important as we continue to invest in making Jupyter better for everyone.

The survey takes only about 3 minutes to complete, and we highly encourage you to participate. The survey will close on Sunday, June 28th.

TAKE THE SURVEY

Thank you for your time, your input, and your continued support of the Jupyter ecosystem!

Community Building Report: Project Jupyter

2024-08-29T19:21:00+00:00

The Jupyter Community Building Working Group would like to share a report and community building recommendations from interviews with members of Project Jupyter subprojects. We invite you to view the full report by clicking here and we welcome feedback on the Jupyter Discourse channel.

Community Building Report: Executive Summary

In late 2023, the Jupyter Community Building Working Group (JCB) launched a series of discussions with subproject representatives to better understand and support their community-building needs: a Jupyter Community Building Survey. The goals of the survey were to understand community-building needs and goals for each subproject, to gather information necessary to advise the Executive Council (EC) on where and what types of resources would be most impactful to meeting these needs and goals, and to identify and share community practices across Project Jupyter.

The JCB used a hybrid approach including a written survey followed by a 30 minute in-depth interview. The report includes our methodology and findings broken out by cross subproject topics and by subproject interviews. A copy of the interview questionnaire is included as Appendix A. This report will be publicly shared and sent to the EC to inspire or serve as a catalyst for strategic activities moving forward. If you have ideas or feedback, we invite you to reach out to us on Discourse.

Here is a brief summary of our recommendations (in no particular order).

1. Create a sustainable events program for subprojects
Project Jupyter should establish stable sources of funding, allocation procedures, and logistical support specifically for subprojects to conduct synchronous, in-person, collaborative meetings on an annual basis. The Project should also provide a way for associated events funded externally to label themselves as “affiliated” or “endorsed” by Project Jupyter.

2. Establish a mechanism for requesting resources
Project Jupyter should establish a procedure for accepting, reviewing, and funding proposals from subprojects. This could include support for external consulting services, infrastructure, or other items that have the potential to benefit the subproject itself and by extension the wider Jupyter ecosystem.

3. Increase Cross Project Coordination
Project Jupyter should create a regular program of Jupyter-wide meetings (virtual and in-person). These meetings should include opportunities to share news between subprojects, discuss best practices and lessons, and also provide opportunities for the wider user community to share information with contributors.

4. Improve onboarding processes for contributors
Project Jupyter should establish a dedicated effort to improve onboarding processes for contributors. This could be a working group, strategic initiative, or paid staff and should focus on creating a more streamlined, consistent, and inclusive onboarding experience for all contributors. An approach that includes code and non-code contributors is important to success.

For more context on these four recommendations and some idea of what next steps are for implementing them, please visit section 4 of the full report.

Acknowledgements

The members of the Jupyter Community Building Working Group — Rollin Thomas (Berkeley Lab NERSC), Martha Cryan (Plotly), Ana Ruvalcaba (Cal Poly, San Luis Obispo), and Jason Grout (Databricks) — would like to thank all involved in this survey. We extend our gratitude to the subproject participants who found time in their busy schedules to respond to our survey questions and meet with us for interviews! We enjoyed learning more about the different subprojects and connecting with their contributors. This report represents a significant investment of time and we hope that its contents will help drive new strategic initiatives at Project Jupyter.

Survey — JupyterLab and beyond

2020-12-14T21:30:00+00:00

The 2020 end-user survey is live!

https://www.surveymonkey.com/r/LCB7GBF

Survey Goals

The purpose of this survey is to gather information from the community in order to enable data-driven decision making about the future of JupyterLab.

The content of the survey focuses on the following categories:

Use Cases — who are they, what are their usage patterns, and what are they doing?
Tooling — what type of data & tools are they using for data science, and what are their pain points in doing so?

By participating in this survey, end-users will guide the roadmap of JupyterLab toward their use cases. Even if you don’t use Jupyter, your input is welcome (see initial questions).

Please share with your teams and friends.

Thank you.

Jupyter Notebook User Experience Survey

2015-12-22T05:13:00+00:00

[A Guest post by Peter Parente, from the IBM team developing several of our current incubator projects]

For the past few weeks, a handful of folks and I have been working on a survey about the Jupyter Notebook user experience. The purpose of this questionnaire is to gather information from you, the Jupyter community, about how you are using (or not using) Jupyter Notebook today. We hope that your answers will help uncover pain-points to address, identify core features to retain, and generate new ideas to consider in Jupyter Lab.

We’d like to invite you now to take part in this survey. It should take you no more than 5-7 minutes to complete. Click the link below to get started. When you finish, please consider sharing the link far-and-wide so that all Jupyter Notebook users have a chance to respond.

https://www.surveygizmo.com/s3/2490075/Project-Jupyter-Notebook-Survey-2015

Be aware that the results of this survey will be published anonymously and publicly. Please do not include private information in your responses.

I’d like to thank Julie Santilli for drafting and revising this survey over the past month. I’d also like to thank Fernando, Brian, Min, Matthias, and Jason for their early-access reviews and feedback.

Thanks in advance for your participation!