Jupyter Blog - governance

JupyterLite Officially Joins Project Jupyter!

2026-02-12T16:14:00+00:00

We are thrilled to announce that JupyterLite is now an official part of Project Jupyter. This milestone marks a significant step forward for interactive computing in the browser and strengthens JupyterLite’s role within the Jupyter ecosystem.

What is JupyterLite?

JupyterLite is a JupyterLab distribution that runs entirely in your web browser. Kernels execute directly in the browser using WebAssembly, eliminating the need for an application server. This means:

Instant access: Start computing with a single click: no prior Python setup, environment configuration, or server management required.
Scalability: Host thousands of concurrent users from a static website (e.g., GitHub Pages) with zero per-user server costs.
Privacy and portability: Code and data remain in the user’s browser, making it ideal for embedding in documentation, tutorials, and interactive demos.

JupyterLite greatly expands the options available in the Jupyter ecosystem for education, documentation, and demos, where reducing friction is critical.

As Brian Granger reminded us during his JupyterCon 2025 keynote, Jupyter’s mission is “to empower people of all backgrounds to think, collaborate, and share knowledge using computational storytelling.” From this perspective, JupyterLite is a logical and key next step to take, letting Jupyter take advantage of the impressive strides made in recent years by the WebAssembly/JavaScript ecosystem (in reach and capability) to advance this mission. JupyterLite is an excellent complement to other forms of accessing Jupyter (whether through a local Python installation or a hosted infrastructure service), that facilitates new use cases and lowers barriers in many others.

Interactive computing in the browser with JupyterLite

The Journey of JupyterLite

JupyterLite’s development began in 2021, led by Jeremy Tuloup at QuantStack. Over the past four years, it has benefited from the dedication of several other team members, Martin Renou, Trung Le, and Ian Thomas — as well as invaluable contributions from community members like Nick Bollweg and many others.

Beyond the JupyterLite repository, the project includes comprehensive tooling for creating in-browser language kernels based on xeus. These kernels support languages like Python, R, C++, GNU Octave, Lua, and SQLite, sharing the same codebase as their backend counterparts, developed by Thorsten Beier, Isabel Paredes, Johan Mabille, and Antoine Prouvost. These kernels are built upon the emscripten-forge software distribution for WebAssembly. The project also includes a Python kernel based on Pyodide, and kernels for JavaScript and p5.js. This architecture means that the same language-agnostic model for kernels that Jupyter pioneered over a decade ago, carries over to the WebAssembly world.

The JupyterLite GitHub organization also features the JupyterLite Terminal, a terminal and shell emulator that runs entirely in the browser and was developed by Ian Thomas. It enables the use of basic Unix commands like grep, sed, cat, touch, and even vim or nano, all built to WebAssembly.

The JupyterLite terminal emulator, with basic Unix commands

JupyterLite now powers the official Jupyter website and is used by projects like numpy.org, sympy.org. It also underlies services such as Jupyter Everywhere and notebook.link.

A Natural Fit with JupyterLab

JupyterLite has always been closely tied to JupyterLab. It is increasingly becoming a set of JupyterLab extensions that replace core plugins to manage kernels, settings, and content in the browser. With contributors overlapping significantly with the Jupyter Frontends group, this integration formalizes what many in the community already recognized: JupyterLite is a core part of the Jupyter ecosystem.

The proposal to transfer JupyterLite to the Jupyter governance received strong support from the Jupyter community and by the Jupyter Frontends council.

Better integration with the rest of Jupyter

With JupyterLite now being an official part of Jupyter, it will be easier to find areas for better integration with other aspects of our ecosystem: we can reduce duplication, smooth out the documentation and model for creating and using both “traditional” (server-hosted) and WebAssembly kernels, and make JupyterLite a natural instant-access component of MyST/JupyterBook-based sites, and more.

Mission-wise, JupyterLite is a natural next step for Jupyter, and having it be an official part of the project makes it much easier for the community to integrate its benefits throughout. We hope you’ll try it, use it and contribute to its growth!

Try it in your browser

If you would like to try JupyterLite in your browser, click on the following link:

Acknowledgments and team credits

JupyterLite’s success is thanks to the support of individuals and organizations who believed in its vision. This includes:

QuantStack, for their continued investment in the project since 2021 and the broader Jupyter ecosystem,
Bloomberg, for funding improvements to JupyterLite by QuantStack since 2023,
The Gates Foundation, for funding the development of the xeus-R kernel and its port to WebAssembly,
The Pyodide project, whose pioneering work on Python in the browser via WebAssembly made JupyterLite possible.

Key developers to this stack include:

Jeremy Tuloup (Director at QuantStack, creator of JupyterLite, and JupyterLab maintainer),
Nicholas Bollweg (JupyterLite maintainer and #2 all-time committer),
Martin Renou (Director at QuantStack, JupyterLite maintainer, responsible for integrating xeus with emscripten-forge, and creator of JupyterLite-Sphinx),
Thorsten Beier (Software developer at QuantStack, lead developer of emscripten-forge, and xeus-lite),
Isabel Paredes (Software developer at QuantStack, led the packaging of R and GNU Octave in Emscripten-forge),
Anutosh Bhat (Software developer at QuantStack, C++ kernel in the browser),
Ian Thomas (Software developer at QuantStack, creator of the JupyterLite terminal, and the cockle shell emulator),
Johan Mabille (Director at QuantStack, creator of xeus),
Agriya Khetarpal (Pyodide contributor, JupyterLite-Sphinx maintainer),
Albert Steppi (JupyterLite-Sphinx maintainer).

Thank you for being part of this journey, we cannot wait to see what you build with JupyterLite!

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.

ipydatagrid is now part of Project Jupyter

2024-08-22T15:01:00+00:00

Today, we are proud to announce that the ipydatagrid open source project has been incorporated into Project Jupyter as part of the Jupyter Widgets subproject.

What is ipydatagrid?

ipydatagrid is a fast data grid widget for Jupyter Notebooks and JupyterLab. Since its inception in 2019, it has been developed as an open source project in Bloomberg’s GitHub organization.

It offers a high-performance fully-featured DataGrid interface, fully integrated with ipywidgets. Built upon the Lumino datagrid, which also powers the JupyterLab CSV viewer, ipydatagrid provides users with a robust and versatile tool for data visualization and manipulation.

Key Features

Users can customize the way data is represented in their grid using a variety of renderers.

ipydatagrid includes a sophisticated selection model with two-way data binding.

It enables conditional formatting powered by Vega Expressions.

The transfer to Project Jupyter

We would like to extend our gratitude to the developers and contributors who have significantly improved the ipydatagrid project over the years: Itay Dafna, Martin Renou, Mehmet Bektas, Kaia Young, Bernát Gábor, Vasilis Themelis, Supriya K., Greg Mooney, Ian Thomas, Olly Hensby, and John Gunstone. Special thanks to Chris Colbert, the creator of the Lumino Datagrid, which forms the foundation of ipydatagrid’s front-end.

Bloomberg’s contribution to Project Jupyter

The transfer of ipydatagrid to Project Jupyter is just one of many contributions that Bloomberg has made to Project Jupyter. As a long-standing sponsor, Bloomberg has been instrumental in the development and success of Jupyter. Home to core maintainers and a major funder of JupyterLab since its inception, Bloomberg has also sponsored all editions of JupyterCon. The sustained support by Bloomberg has been crucial to Jupyter’s growth and impact.

We are excited about the future of ipydatagrid within Project Jupyter, and look forward to continued innovation and collaboration within the broader community.

— on behalf of the Jupyter Widgets Council, Sylvain Corlay

Announcing a New Jupyter Governance Model and Our First Executive Council

2023-01-13T21:08:00+00:00

After a lengthy planning and preparation process, Project Jupyter is proud to announce its new governance model, including an Executive Council (EC), Software Steering Council (SSC), Distinguished Contributors, Standing Committees, Working Groups, and Subprojects. We have also elected our first Executive Council, a group of contributors who are now leading Jupyter in 2023.

This governance transition was motivated by lessons we’ve learned as the project grew dramatically in the last decade. Our previous model, used since the project’s early days as IPython and influenced by the BDFL (Benevolent Dictator for Life) model of Python itself, had proven insufficient to meet our current needs. Our former Steering Council consisted of members who had made significant contributions to Jupyter and IPython. We decided that it would be better for the project if we separated the roles of “major contributor” and “decision maker.”

First, we developed the Jupyter Distinguished Contributors program to recognize the contributions of our community members. Distinguished Contributors do not have active responsibilities or decision-making authority. Next, we designed a model that would allow a project as broad as Jupyter, both in terms of technical architecture and use cases, to grow in a healthy way. We aimed to create structures to help us make technical decisions effectively, to grow the human and social aspects of the project and community in a sustainable manner, and to manage the diverse, multi-stakeholder nature of Jupyter with fairness to all. Jupyter’s stakeholders range from individual volunteers to some of the largest tech firms in the world, from academics to government and industrial users. Our intention is that with our new governance model, all of our stakeholders can create ideas, tools, spaces and communities around interactive computing.

Jupyter’s new governance model

The project website provides an overview of the new governance model as well as details on its individual components. Please refer to those pages for specific information. In summary, the BDFL+Steering Council structure has been replaced by a small, elected Executive Council (EC) that works together with a Software Steering Council (SSC) made up of representatives from our subprojects, working groups, and standing committees. Every year, we will continue to recognize new Distinguished Contributors. This new governance model has replaced the previous model as of January 2023.

The BDFL, Steering Council, and institutional partners have served us well in the past, and Jupyter is grateful for all of their support. We are optimistic about the work to be done by our new Executive Council, by our Software Steering Council, by our large community of contributors, and by all of our users who constantly provide thoughtful and informed feedback.

Executive Council (EC)

Our first executive council includes Afshin Darian, Brian Granger, Jason Grout, Fernando Pérez, Ana Ruvalcaba, and Steven Silvester.

The EC is ultimately responsible for many aspects of Jupyter’s governance, including legal, financial, and operations matters. The members of the EC actively work to carry out Jupyter’s mission in accordance with its values. The EC delegates some work to the Software Steering Council, Software Subprojects, Standing Committees, and Working Groups. These other bodies report to the EC, and the EC is expected to support, oversee, manage, and ensure the success of operations across Jupyter. For more detail, see the Executive Council document.

The first EC includes the following individuals, serving either full 2-year terms or partial 1-year terms:

Afshin Darian, QuantStack, 2 year term
Brian Granger, AWS and Cal Poly San Luis Obispo, 2 year term
Fernando Pérez, UC Berkeley, 2 year term
Jason Grout, Databricks, 1 year term
Ana Ruvalcaba, Cal Poly San Luis Obispo, 1 year term
Steven Silvester, MongoDB, 1 year term

Our first three EC members, who will serve a two-year term, are Darian, Brian, and Fernando. These three people elected one new member for the EC; voters elected two others from a slate of nine candidates. These newly elected members are Jason Grout, Ana Ruvalcaba, and Steven Silvester. All three of these new members will serve a shortened one-year term on the council. In the future, we will have elections every year, selecting new members for two-year terms. Members can serve up to two consecutive full terms.

We held an election in November and December 2022 in which all members of the Union of Councils (UoC) could participate, both as candidates and as voters. The UoC includes all members of all Standing Committees, Working Groups, and Subproject Councils. A person who nominated a candidate (either themself or someone else) wrote a statement of their interest, qualifications, and experience. In total, we received nine nominations for this election. We collected the candidates’ statements into a voter’s guide, and also included instructions about how to vote. We used ranked-choice voting with a single transferable vote, as implemented by Apache STeVe. We collected votes from UoC members via Google Forms. Each voter could select one or more candidates, in descending order of preference, without ties. A tabulator then ran the results through a data prep script, then into Apache STeVe’s tabulation script, to determine the winners through a series of rounds. (In our first election, because I was neither an EC member nor a candidate, I volunteered as tabulator.)

In each round, the tabulation script looked for two candidates with more than a quota, a winning threshold, of votes. If it found two, then it was done. If not, then any winner with more votes than the quota had its surplus votes reallocated to lower-priority candidates, and a candidate with too few votes was eliminated, then in the next round, the script repeated the process from the beginning. In total, it took 8 rounds to select 2 winners from our slate of 9 candidates.

Software Steering Council (SSC)

The SSC has jurisdiction over software-related decisions across Project Jupyter, with a primary focus on coordination across projects and decisions that have impact across many Jupyter Subprojects. It is also a mechanism for representatives of each project to share information and expertise. Technical decisions and processes where the SSC isn’t explicitly involved are automatically delegated to the individual projects to manage their day-to-day activities, create new repositories in their orgs, etc., with independence and autonomy. For more detail, see the Software Steering Council document.

The first SSC includes the following individuals who each represent one subproject or working group:

Jupyter Accessibility: Isabela Presedo-Floyd
Jupyter Foundations: Paul Ivanov
Jupyter Kernels: Johan Mabille, QuantStack
Jupyter Notebook: Eric Charles, Datalayer / Anaconda
Jupyter Security: Rick Wagner
Jupyter Server: Zach Sailer, Apple
Jupyter Standards: Carol Willing, Noteable
Jupyter Widgets: Itay Dafna, Netflix
JupyterHub and Binder: Min Ragan-Kelley, Simula Research Lab
JupyterLab: Frédéric Collonval, QuantStack
Voilà: Sylvain Corlay, QuantStack

Each of the above individuals was elected by the Council of their respective subproject or working group.

How to get involved

The Jupyter EC holds office hours every Tuesday at 10:00 AM, U.S. Pacific time. You can find information about joining these office hours on the Jupyter Community Calendar. You can also contact the EC at jupyter-executive-council@googlegroups.com.

Jason Weill is a Senior Front-End Engineer at Amazon Web Services; a contributor to JupyterLab, Jupyter Governance, and Jupyter Scheduler; and a member of the JupyterLab Council, the Jupyter Security Working Group, and the Jupyter Diversity, Equity, and Inclusion Standing Committee. This article does not represent the official position of amazon.com or any of its subsidiaries.

Xeus is now a Jupyter subproject

2020-02-04T12:08:00+00:00

It is a great pleasure to announce that the Xeus project has been incorporated as a Jupyter subproject. Xeus will now be subject to the Jupyter governance and code of conduct.

For reference, the Jupyter Enhancement Proposal (JEP) for the Xeus incorporation is available here.

What is Xeus?

The Xeus project is a C++ implementation of the Jupyter kernel protocol. Xeus is not a kernel, but a library meant to facilitate the authoring of kernels.
Several Jupyter kernels have been created with Xeus:

xeus-cling, a kernel for the C++ programming language, based on the Cling C++ interpreter. The cling project comes from CERN and is at the foundation of the ROOT project.

The xeus-cling Jupyter kernel for the C++ programming language.
xeus-python, a kernel for the Python programming language, embedding the Python interpreter.

The xeus-python Jupyter kernel for the Python programming language
xeus-calc, a calculator kernel, meant as an educational example on how to make Jupyter kernels with Xeus.

Beyond these three kernels built on top of Xeus by the Xeus maintainers, third-parties have developed other Jupyter kernels with Xeus:

JuniperKernel, a kernel for the R programming language by Spencer Aiello.
xeus-fift, a kernel for the fift programming language by Michael Zaikin. The fift programming language was developed by Telegram to create TON blockchain contracts.
SlicerJupyter, a kernel for the Python programming language by Kitware which integrates into the Qt event loop of the Kitware “Slicer” project.

Finally, the xeus-python kernel includes a first implementation of the Jupyter debugger protocol used by the Jupyter debugger project. xeus-python enables the Debug Adapter Protocol over the Control channel through new debug request/reply and debug event messages.

Why moving Xeus under the Jupyter governance?

While Xeus started as a side project for QuantStack engineers, the project now has several stakeholders who depend on it. We think that moving the project to an open governance organization may be a better way to reflect this situation.

Acknowledgements

Xeus was started by the team of open-source developers at QuantStack as a separate project, but with the full intent to incorporate it into Jupyter. The initial project development at QuantStack was funded by Bloomberg.
Now, Xeus contributors work in many institutions, including Université Paris-Saclay and École Polytechnique.

About the Author

Johan Mabille is a Scientific Software Developer at QuantStack, specializing in high-performance computing in C++. He holds master’s degree in computer science from Centrale-Supelec.

As an open source developer, Johan coauthored xtensor, xeus, and xsimd. He also made major contributions to the JupyterLab debugger project and bqplot.

Voilà is now a Jupyter subproject

2019-12-29T12:11:00+00:00

It is a great pleasure to announce that the Voilà project has been incorporated as a Jupyter subproject. Voilà will now be subject to the Jupyter governance and code of conduct.

For reference, the Jupyter Enhancement Proposal (JEP) for the Voilà incorporation is available here.

What is Voilà?

Voilà helps you communicate insights, by transforming a Jupyter Notebook into a stand-alone web application you can share. It gives you control over what your readers experience in a secure and customizable interactive dashboard.

The easiest way to get started with Voilà is to install it via pip or conda and type voila some_notebook.ipynb to turn the said notebook into a dashboard.

Besides, Voilà includes a templating system that allows to overload the behavior of the front-end. Using this templating system, Voilà can be used to create

slideshows (with voila-reveal)

A Voilà slideshow created with the voila-reveal template.
dashboards (with voila-gridstack)

A Voilà Dashboard based on the voila-gridstack template.

Why moving Voilà under the Jupyter governance?

While the project was initially started by QuantStack, the team now comprises developers from Bloomberg, UC Berkeley, JP Morgan, and Cal Poly San Luis Obispo. OVH has been supportive of the project by kindly providing the free hosting of the gallery on their infrastructure.

We believe that the multi-stakeholder nature of the Voilà project is well-suited for the Jupyter organization.

The Voilà project is largely built upon Jupyter subprojects and standards.

The standard notebook file format is the main entry point to Voilà.
nbconvert is used for the conversion to progressively-rendered HTML.
naturally, we use jupyter_client for handling the execution of notebook cells
jupyter_server is the default back-end.
JupyterHub is at the foundation of the voila-gallery project.
JupyterLab components (mime renderers, input and output areas) are used in the front-end implementation. Voilà also includes a preview JupyterLab extension.
ipywidgets and custom jupyter widget libraries such as bqplot, ipyvolume, ipyleaflets provide the bulk of the interactivity of Voilà applications.

Voilà is more a remix of existing Jupyter components (with changes to enable that use case) than a completely new application.

Resources

Should you be interested in Voilà, feel free to try it on Binder or locally! You can also engage with the developer community during our public team meetings and the various GitHub repositories of the project:

the Voilà GitHub repository is available here: https://github.com/voila-dashboards/voila.
the Documentation is hosted on Read the Docs: https://voila.readthedocs.io.
the Team Compass holds the calendar for the public developer meetings, as well as the meeting minutes: https://voila-dashboards.github.io.
the Announcement of the first Voilà release was published on this blog: And voilà!

Acknowledgements

Voilà was started by the team of open-source developers at QuantStack as a separate project, but with the full intent to incorporate it into Jupyter. The initial project development at QuantStack was funded by Bloomberg.
Now, Voilà contributors work in many institutions, including UC Berkeley, Cal Poly San Luis Obispo, JP Morgan, and Faculty (formerly ASI Data Science).
The Voilà Gallery is kindly hosted by OVH.