Jupyter Blog - Jupyter Foundation

Mark Your Calendars: Jupyter Day 2026 is Coming to San Jose!

2026-09-04T10:01:00+00:00

Project Jupyter has always grown around its community. From early notebook hacks to large-scale deployments across research labs and universities, what makes this ecosystem work is the people building tools, running infrastructure, and sharing workflows.

That is why we are excited to announce Jupyter Day 2026, happening on Monday, October 19, 2026, at the San Jose Convention Center in California!

This year, we are co-locating with PyTorch Conference North America. If you are already planning to be in town for PyTorch, you can easily add Jupyter Day to your week — or you can simply register to attend Jupyter Day on its own!

What We Are Covering

Jupyter Day is a focused event for developers, maintainers, data scientists, educators, and system admins to talk about real-world setups and future project architecture.

Here are the main tracks and suggested topics for the event:

Data Science: How Jupyter is used by data science practitioners across industry, government, research, and beyond.
Community & Ecosystem: Insights into the Jupyter community, frontends, kernels, custom extensions, and essential ecosystem tools.
Research and Scientific Discovery: Practical applications in specific scientific fields, including medical research, astronomy, physics, climate science, meteorology, social sciences, and the humanities.
Education: Practical methods and strategies for teaching and learning with Jupyter across diverse educational settings.
Jupyter Infrastructure: Deploying Jupyter and JupyterHub at scale across high-performance computing, cloud environments, enterprise, and academia — covering DevOps, scaling, security, and compliance.
AI & Machine Learning: Leveraging AI and machine learning inside Jupyter and using Jupyter environments to drive ML development.

Whether you want to showcase a JupyterLab extension you built, explain a tricky deployment setup, or discuss new open standards, we want to hear from you.

Call for Proposals is Open!

The Call for Proposals (CFP) is live right now. We are looking for technical talks, panel ideas, and poster presentations from every part of the community.

CFP Deadline: Sunday, September 13, 2026 at 11:59 PM PDT
Submit your proposal: Jupyter Day CFP Portal

Put your organization front and center at Jupyter Day 2026! Sponsoring this event connects your brand directly with core developers, researchers, and AI leaders building the future of open-source interactive computing.

View opportunities: Download the Jupyter Day 2026 Sponsorship Prospectus.
Get in touch: Reach out to jupyterevents@linuxfoundation.org to reserve your sponsorship or ask questions.

You can find full event details, hotel info, and registration links directly on the Linux Foundation event page.

We hope to see you in San Jose this October!

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.

Positron Server available for academic use via JupyterHub

2026-07-29T18:19:00+00:00

Editor’s note: This is a guest blog post from Posit, a Jupyter Foundation member

Academic institutions can now offer Positron directly within their existing JupyterHub environments, giving students access to a modern, full-featured data science IDE without requiring local installation or additional infrastructure. Licensed under the permissive, source-available Elastic License 2.0, Positron as a desktop app is free for everyone to use, build on, and extend across personal, academic, and commercial projects. Through a free educational license, universities and other academic organizations can additionally make Positron Server available to currently enrolled students for coursework, helping create a consistent learning experience across classrooms, labs, and remote environments.

By integrating Positron into JupyterHub, educators can provide students with a powerful development environment alongside the tools they already use. Students simply launch Positron from the JupyterHub interface, just as they would open JupyterLab or a different environment, and can begin working immediately.

Bringing a Modern Data Science IDE to the Classroom

Positron combines the familiarity of notebook-based workflows with the capabilities of a professional integrated development environment (IDE). Once launched through JupyterHub, students have access to the complete Positron experience, including:

Comprehensive support for both Python and R
Access to the OpenVSX extension marketplace
Built-in data viewer and variables explorer
Integrated help pane, debugging tools, and version control
Advanced development features that help students grow their data science skills over time

This approach allows instructors to standardize course environments while reducing the technical barriers often associated with software installation and configuration.

Designed to Work with Existing JupyterHub Deployments

Positron Server is built to integrate directly into existing JupyterHub environments, making adoption straightforward for administrators already managing Jupyter-based infrastructure.

The solution is compatible with:

JupyterHub deployments running JupyterLab 4
Python 3.9 and later environments

Installation is provided through the jupyter-positron-server Python package, which is built on Jupyter Server Proxy. For administrators who have previously configured services within JupyterHub, the setup process will feel familiar.

Rather than functioning as a standalone desktop application, Positron Server extends existing JupyterHub deployments by making the Positron IDE available as another launch option within the environment.

Free Educational Licensing for Teaching

Academic institutions using Positron for instructional purposes are eligible for a free teaching license. Under this license, access can be provided to:

Currently enrolled students
Course participants
Faculty and staff involved in delivering educational programs

This licensing model enables institutions to incorporate Positron into coursework without additional software costs, helping educators provide professional-grade tools to learners.

Getting Started

Institutions interested in offering Positron through JupyterHub can get started in three simple steps:

Review the eligibility requirements outlined in the Positron Education License Rider.
Contact Posit to request a free teaching license.
Follow the jupyter-positron-server installation and configuration documentation to deploy Positron within your JupyterHub environment.

Supporting the Next Generation of Data Scientists

As data science and computational research continue to grow across disciplines, educational institutions are looking for ways to provide students with professional tools that are easy to access and manage. By bringing Positron directly into JupyterHub, universities can deliver a modern, scalable development environment that supports both teaching and learning while minimizing setup complexity.

Whether students are writing Python code, analyzing data in R, or exploring advanced development workflows, Positron Server helps create a seamless experience from the first day of class through more advanced coursework and research projects.

Jupyter Blog - Jupyter Foundation

Mark Your Calendars: Jupyter Day 2026 is Coming to San Jose!

What We Are Covering

Call for Proposals is Open!

Sponsor Jupyter Day 2026

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

Who answered

Common themes that people raised

Environment and dependency management

Version control and collaboration

The interface, and parity with editors

Artificial Intelligence

Other themes

Submit a proposal

Thank you

Appendix

The data, and how to read it

Product-use numbers

Usage patterns

Positron Server available for academic use via JupyterHub

Bringing a Modern Data Science IDE to the Classroom

Designed to Work with Existing JupyterHub Deployments

Free Educational Licensing for Teaching

Getting Started

Supporting the Next Generation of Data Scientists