Jupyter Blog - Jupyter Foundation

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.

2026 Jupyter Community Call For Funding Proposals

2026-07-06T19:32:00+00:00

The Jupyter Executive Council and Jupyter Foundation are pleased to announce a new Call for Proposals (CFP) for funding the Jupyter community to improve Jupyter. Visit the Jupyter Foundation Community Proposals webpage to learn more about the process and how to submit proposals. Submit a proposal by Wednesday, September 9, 2026.

The Jupyter Foundation began its operations in early 2025 with a mission to use its resources to support the Jupyter community. As part of this mission, we funded a round of community proposals in 2025. This funded work continues to bring many benefits to the Jupyter ecosystem (see the progress reports here). In this next call for proposals, we are iterating on this success.

Visit the Community Proposals webpage to learn more about past funded proposals and the Jupyter Foundation team compass for more detailed background about this funding call. In this second round, our goal is to continue learning how to best manage a community funding program. Based on feedback, we are updating the proposal process in several ways, including:

A new section of the proposal template has been added for Jupyter council or committee endorsements. We strongly encourage authors to seek and include endorsements from Jupyter councils or committees affected by the proposal. Each endorsement should be a brief paragraph about the impact of the proposed work from the council or committee’s perspective, and express support for the work and a willingness to receive it. We encourage authors to communicate early with relevant Jupyter councils and committees to make this endorsement process easier.
The de-risk section of the proposal is now optional for smaller funding requests.
The CFP is open for several weeks longer than the previous round. We do not anticipate extending the CFP deadline this time.

Submit a proposal by Wednesday, September 9, 2026.

As with the previous round, to help inspire proposals we are particularly excited to fund, we’ve defined funding priorities for the Jupyter Foundation. These are key outcomes that we must improve in order to grow the overall health and impact of the ecosystem. Briefly summarizing, these priorities are:

Grow the contributor capacity of Jupyter. We would like to grow the number of contributors, improve the efficiency of existing contributors, and facilitate learning across Jupyter subprojects. We’d love to see proposals that help us mobilize and support the total pool of energy available to contribute to Jupyter. Examples of recent activities in this area include hiring a community manager and hosting community workshops.
Improve the reliability, security, and consistency of Jupyter’s software and team practices. We believe that our technology will be more impactful and easier to contribute to and deploy if we improve our development infrastructure and team practices in ways that contribute to reliability, security, and consistency. Examples of recent activities in this area include investing in better testing infrastructure and linting rules, refactoring build systems, improving accessibility, funding security issue triage, and hosting a subproject roadmap alignment workshop.

While we’re particularly excited about these two outcomes and aim to focus funding on proposals that clearly feed into one or both of these priorities, we also encourage people to get creative and submit proposals for outcomes that have high impact and strategic value for the Jupyter community. We’re excited to see what others come up with, and are eager to work with you in unlocking critical funding in support of Jupyter’s community.

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!

Our new Jupyter Foundation Community Manager

2026-05-18T20:01:00+00:00

The Jupyter Foundation is excited to announce that we have contracted with Jason Grout to be a part-time Jupyter Foundation Community Manager. The primary purpose of this role is to strengthen the Foundation and assist the Foundation and its members in providing value to Project Jupyter.

In the year and a half the Foundation has existed, it has funded a number of strategic initiatives, including JupyterCon 2025, a series of Jupyter Workshops, community development and capacity grants, and a strategic marketing effort. In that time, we’ve found that planning, delivering, and improving these initiatives is difficult without dedicated capacity and expertise.

With the capacity and experience provided by this role, we are excited to continue growing our connection with and value in the community. Jason has a long history of service to the Jupyter project, and has spent several years serving on Jupyter’s Executive Council and more recently on the Jupyter Foundation Board. We’re excited for the expertise, wisdom, and positive spirit that Jason will bring to this role.

This is a new role, and we’ll shape the responsibilities and key deliverables as we learn. In the meantime, keep an eye open for Jason across the community and alongside various initiatives that the board is excited to continue this year.

-RP

Jupyter Foundation Governing Board Chair

Announcing our first Jupyter Community Funded Proposals

2025-11-04T19:19:00+00:00

We are thrilled to announce the results of our first round of Jupyter Community Funding proposals. This is the first funding call from the Jupyter Foundation to directly solicit proposals from the Jupyter community.

We received many outstanding ideas from community members. We are so grateful for the time and effort everyone put into their submissions. This is a new process for us, and we’ve already learned a lot. We’re excited to take this first step in directly supporting community-driven work.

After a careful review, we are happy to fund the following proposals:

More reliable visual testing for Jupyter frontends: This project will improve visual regression and integration testing across Jupyter frontends. We hope this will lower maintenance costs and reduce maintainer burnout by making testing more reliable.
Separating JupyterLab’s build system for easier maintenance: This work will finish separating JupyterLab’s build system into a standalone tool. This will make maintenance easier for both core developers and extension authors.
Improving keyboard accessibility in JupyterLab: This proposal will focus on making JupyterLab fully navigable via keyboard and testing with disabled users. The goal is to find and fix key accessibility blockers, making the tools more usable for everyone.
Growing the contributor community for JupyterHub and JupyterBook: This project will tackle efforts like team coordination and mentorship pipelines with clear entry points for contributions. We hope this will grow our contributor base by making it easier to attract, retain, and leverage community contributions.
Improving code quality with custom linting rules: This proposal will develop custom linting rules to enforce project-specific standards in the JupyterLab and Notebook codebases. This will help catch common issues early and improve the long-term health of the code.
Reviving the extension playground for easier prototyping: This project will revive and improve the extension playground, a tool for prototyping new extensions. We’re excited for this to lower the entry barrier for extension development and help the ecosystem grow.

A huge thank you to everyone who submitted a proposal and participated in the review. We also want to thank the authors of proposals that were not funded in this round. We particularly appreciate their effort and hope they will continue to engage with this process.

We’re excited to see these projects develop and support the dedicated people behind them. This is just the beginning, and we look forward to more community funding opportunities in the future.

We want to send a special thank-you to Savannah Ostrowski, former Jupyter Foundation board treasurer, for her work in setting up this initial round of funding.

Your Ideas, Our Support: Jupyter Community Call For Funding Proposals

2025-08-28T15:18:00+00:00

The Jupyter Executive Council and Jupyter Foundation are pleased to announce a call for proposals for the Jupyter community. Visit the Jupyter Foundation Community Proposals webpage to learn more about the process and how to submit proposals. The call for proposals is open through Sunday, October 5th, 2025.

edit: We’ve decided to extend this by one week to give a few in-progress proposals time to write and submit! The new deadline is October 5th.

The Jupyter Foundation began its operations in early 2025 with a mission to use its resources to support the Jupyter community. We’ve set up the operations, structure, goals, and strategy of the Jupyter Foundation and published them on the Foundation team compass. We’ve had several rounds of feedback from the Jupyter community and defined the Foundation’s overall goals for its first year of operation.

Our first funding allocation supported events that grow the connections within the Jupyter community via the community workshops series as well as our connection with the broader data science community via JupyterCon 2025.

For the next wave of funding for the community, we’re running an experiment to directly solicit funding proposals from the Jupyter community. We think this will result in a strong clear connection between the Foundation’s funds and the needs of Jupyter’s maintainers, contributors, power users, and advocates.

The call for proposals is open through Sunday, October 5th, 2025.

Visit the Community Proposals webpage to learn how to submit a proposal and the Jupyter Foundation team compass for more detailed background about this funding call.

In this first round, one of our goals is to learn. We’d like to learn how to administer a community call like this as well as what kind of value it delivers to the Jupyter community. We’ve set minimum targets for funding disbursement and hope to grow our funding allotment as we iterate from here.

To help inspire proposals we are particularly excited to fund, we’ve defined funding priorities for the Jupyter Foundation. These are key outcomes that we must improve in order to grow the overall health and impact of the ecosystem. Briefly summarizing, these priorities are:

Grow the contributor capacity of Jupyter. We would like to grow the number of contributors, improve the efficiency of existing contributors, and facilitate learning across Jupyter subprojects. We’d love to see proposals that help us mobilize and support the total pool of energy available to contribute to Jupyter.
Improve the reliability, security, and consistency of Jupyter’s software and team practices. We believe that our technology will be more impactful and easier to contribute to and deploy if we improve our development infrastructure and team practices in ways that contribute to reliability, security, and consistency.

While we’re particularly excited about these outcomes and aim to focus funding on proposals that clearly feed into one or both of these priorities, we also encourage people to get creative and submit proposals for outcomes that have high impact and strategic value for the Jupyter community. We’re excited to see what others come up with, and are eager to work with you in unlocking critical funding in support of Jupyter’s community.

Acknowledgements

We are grateful for the support of the Jupyter Foundation and its members that makes this opportunity possible. If your organization would like to support this program, please contact the Jupyter Foundation.

Project Jupyter’s 2025 Executive Council Elections

2025-03-06T16:26:00+00:00

Project Jupyter recently completed its 2025 Executive Council (EC) election, marking an important transition in its leadership. The newly elected members — Afshin Darian, Chris Holdgraf, and Rick Wagner — will serve two-year terms, helping guide strategic and operational direction for Project Jupyter.

Rick Wagner, San Diego Supercomputer Center (2025–2027)
Afshin Darian, QuantStack (2025–2027)
Chris Holdgraf, 2i2c (2025–2027)
Ana Ruvalcaba, Cal Poly State University San Luis Obispo (2024–2026)
Jason Grout, Databricks (2024–2026)
Zach Sailer, Apple (2024–2026)

Who Are the Newly Elected EC Members?

The three elected members bring deep expertise and long-standing contributions to Jupyter:

Afshin Darian was part of the inaugural Executive Council in 2023 and is continuing in his role as an EC member. He has contributed to Jupyter’s transition to the Linux Foundation, alongside his work on the architecture of Jupyter and accessibility.
Chris Holdgraf has played a key role in JupyterHub, Binder, and Jupyter Book, helping to sustain and grow these vital subprojects. He is also the executive director of a non-profit called 2i2c that manages JupyterHub infrastructure for communities in research and education.
Rick Wagner has been active in Jupyter’s Security Subproject, advocating for secure development practices and leading major security initiatives.

Their collective experience spans technical innovation, community governance, security, and sustainability, ensuring that Jupyter continues to evolve in a way that serves users, contributors, and the broader ecosystem. Darian, Chris, and Rick will join the members serving in their current two-year terms, Jason Grout, Ana Ruvalcaba, and Zach Sailer. Together, the EC members represent industry, academic, and non-profit organizations.

Creating Open, Sustainable, Leadership

When Jupyter was created, it followed a “Benevolent Dictator for Life” (BDFL) style of governance that was popular in open source communities at the time. Throughout the 2010s, the project learned (along with many others in the open source ecosystem) that BDFL models for complex projects are not sustainable for both the project and for its contributors. As a result Jupyter began a long-term initiative to move away from its BDFL decision-making structure. It began by adopting a Steering Council model, where a group of peers made consensus-based decisions across the entire project. This distributed Jupyter’s decision-making authority, but did not efficiently represent the breadth and complexity of Jupyter’s ecosystem.

In 2022, Project Jupyter took the next step towards formalizing and decentralizing its governance. It adopted a more dynamic, distributed, and community-driven structure. Jupyter’s governance model guides the development of over a dozen distinct software components and several groups focused on specific activities, including accessibility and security. Software design and development is handled by individual Subprojects, with each Subproject typically responsible for one or more software components or packages. Subprojects elect representatives to the Software Steering Council which has jurisdiction over software-related decisions across Project Jupyter. The Executive Council is chosen via elections and has the ultimate responsibility for all aspects of Project Jupyter, including its software, finances, trademark, operations, etc. In 2024, this extended to the creation of the Jupyter Foundation, a directed fund of the Linux Foundation 501(c)(6) whose purpose is to raise, budget and spend funds in support of Project Jupyter and its mission. The Foundation Governing Board controls the resources of the Foundation, and works to build a healthy collaboration between the Jupyter community, Jupyter leadership, and members of the Jupyter Foundation.

Jupyter recently completed its 2025 election for the Executive Council. This election is especially significant because it marks the first time that Fernando Pérez and Brian Granger, two of Jupyter’s founding figures, will not serve in the executive leadership body of the project. Their voluntary departure from the EC reflects their confidence in the governance model established in 2022 and is an indication that the new model is progressing toward its goal: creating a self-sustaining leadership structure where contributors from across the Jupyter ecosystem can contribute their talents. Going forward, Brian will continue to be involved in Jupyter’s software and will serve on the Governing Board of the Jupyter Foundation. Fernando will remain actively involved with various parts of the Jupyter ecosystem, including JupyterHealth, MyST, Jupyter uses in science and education through 2i2c, Jupyter-AI, and the nascent GeoJupyter (independent) community effort.

What This Means for Jupyter’s Future

The success of this election signals a healthy, evolving open-source project, where leadership is dynamic, inclusive, and community-driven. It shows that Jupyter’s governance changes have not only ensured continuity but have also empowered new voices to take on leadership roles to serve the community.

The departure of Fernando and Brian from official leadership positions is not an end, but a milestone — a testament to our vision for an open, thriving, and community-led project.

The Jupyter community now looks ahead to the next era of innovation, collaboration, and sustainability with support from all of its contributors.

Project Jupyter joins LF Charities

2024-10-23T19:00:00+00:00

We are excited to announce that Project Jupyter is entering a new phase in our journey: we are joining LF Charities, a 501(c)(3) non-profit under the Linux Foundation. See the official press release from Linux Foundation and the blog post from NumFOCUS.

In the last decade, Jupyter has grown tremendously. From our roots as an evolution of the IPython project, Project Jupyter is now the de facto standard for interactive computation in data science, scientific computing, and machine learning. The software and standards developed by the Jupyter community span a rich and diverse ecosystem that includes data science, geospatial data analysis, physics, chemistry, CAD, and many other areas.

In order to sustain this momentum, continue innovating in the space of interactive computational tools for thinking and collaborating, and better serve our community, we are introducing the new Jupyter Foundation, a vehicle for the project to formally engage with industry partners and other organizations. We invite organizations of all types, including companies, government agencies, and non-profits who support our mission to join us through the Jupyter Foundation. For information on joining, please see https://jupyterfoundation.org.

As background for this change, the Project Jupyter Executive Council began exploring options for the next phase of our growth over a year ago. In March 2024, we presented a high-level proposal to the community for Jupyter to transition to LF Charities as its legal home. An open discussion was hosted on GitHub for the community to discuss this idea, generating a lot of feedback, which was incorporated into the main proposal document. Once discussion settled, on June 14, 2024, we moved to a formal vote as per our governance model, in which the Jupyter Executive Council and the Jupyter Software Steering Council jointly approved moving forward with the transition to the LF Charities. We have since then worked with both NumFOCUS and Linux Foundation leadership to formalize the transition, which is completed today. We sincerely thank NumFOCUS for their support of IPython and Jupyter, and we look forward to continuing collaborating with the entire community of NumFOCUS projects.

If you are a user or supporter of Jupyter in any capacity, please help us spread the word about this new phase for the project, and encourage organizations to support our mission through the Jupyter Foundation.