Community | 2i2c

Report from the Jupyter and AI community meetup

Thu, 23 Apr 2026 00:00:00 +0000

A small group of Jupyter community members recently met in Seattle to demo Jupyter workflows augmented with AI tools and discuss what’s next. This is a quick report-out about what stood out.

The conversations focused on what agentic workflows could unlock for researchers and students - with broad acknowledgement that deployment, security, authorization, and ethics still have a lot to be worked out.

Here are a few highlights from the demos.

Jupyter AI and the Agent Client Protocol #

Jupyter AI v3 is adding support for the Agent Client Protocol (ACP), enabling multi-agent collaboration within JupyterLab. We saw how a single request could be split across multiple specialized agents based on each one’s skills, similar to this demo from JupyterCon 2025.

Some things still to figure out:

No tool isolation yet - agents aren’t scoped by user role or security group.
Manual configuration required - agents running locally need to be registered by hand.
A future goal is for JupyterLab to auto-detect locally installed agents, or for LLM providers to contribute integrations directly.

The Jupyter AI team also shared a new “Personas” abstraction that lets you define a skill-specific agent in just a few lines of Python. Personas open the door to domain-specific agents or agents with crafted “personalities”. They are written in a few lines of Python, though we discussed the possibility of using markdown instead. This seems to be evolving rapidly!

Jupyter AI v3.0.0 has since been released.

Notebook CLI #

nb-cli is a Rust-based tool for interacting with notebooks from the command line - changing cells, running them, checking errors, and rendering the notebook in the console. It can also connect to remote JupyterLab instances, making it useful for headless workflows like CI pipelines or batch grading.

Sidebar comments and Real-time collaboration #

A demo showed Google Docs-style side-panel comments for .ipynb files. Previous collaboration efforts used Conflict-free Replicated Data Types (CRDTs) for multi-cursor editing, but the team felt that approach may not have hit the mark. Side-panel comments felt more natural, though how this extends to .py files is still an open question.

Opportunities for 2i2c #

The meeting helped us understand the role we could play in this space. We think there’s opportunity to help facilitate the use of agents on shared infrastructure, particularly around the upstream control planes for deployment, administration, and authorization. We can also help facilitate community conversations about the ethics and impact of AI tools on open science.

Acknowledgements #

The Jupyter Foundation for supporting the event.
Zach Sailer (Apple), for organizing this meetup.
Chris Holdgraf for editing and adapting the original content for this post.

BIDS joins the mybinder.org federation with help from 2i2c

Thu, 09 Apr 2026 00:00:00 +0000

The Berkeley Institute for Data Science (BIDS) has joined the mybinder.org federation, contributing a new node alongside 2i2c and GESIS. BIDS is the birthplace of mybinder.org, so it’s great to see them back as an active federation member.

We helped out with development, setup, and operations for the new federation member on OVH. Here’s the initiative we just closed out ».

This is a win for the resilience of mybinder.org - the BIDS node runs on a different cloud provider than the existing nodes, reducing the risk that a single provider outage takes down the whole service.

Read the full details on the Jupyter blog.

Report from the Jupyter Security Working Group security tooling sprint

Wed, 08 Apr 2026 00:00:00 +0000

The Jupyter Security Working Group recently held a Security Tooling Sprint. It was a timely event given the recent spate of software supply chain attacks across the tech world.

The sprint covered two main areas:

Governance and strategy — conversations about responsibility and accountability in the face of AI, with emphasis on ensuring humans are ultimately responsible for code committed to Jupyter subprojects. The group also discussed how security could benefit from working group members regularly attending subproject meetings like the JupyterHub Collaboration Cafes.
Automation and tools — the group evaluated several tools for improving security posture across the Jupyter ecosystem. Here are a few that stood out:
- Semgrep as an alternative vulnerability scanner to CodeQL
- Grype, Checkov, and Kubescape for cloud infrastructure misconfiguration checks
- Schemathesis and restler-fuzzer for API fuzz testing

One challenge we discussed was how blindly running security scanning tools generates many false positives. There’s real effort needed to tune these tools for each project’s edge cases before they’re useful in automation. On a related note, we discussed the increase in AI-generated (or AI-assisted) vulnerability and security reports, and the challenges associated with sifting through all of those pieces of information.

Acknowledgements #

Thanks to the jupyter security working group for providing leadership and organizing, in particular Joe Lucas!
Thanks to the Jupyter Foundation for funding community meetings like these.

Jenny Wong joins the JupyterHub team

Mon, 09 Feb 2026 00:00:00 +0000

We’re excited to share that Jenny Wong has been invited to join the JupyterHub team as a contributor and maintainer.

Jenny’s contributions to nbgitpuller and grafana-dashboards, along with her active participation in project meetings and community planning, earned her this recognition from the JupyterHub community. Being invited to a project team means that existing team members have recognized a pattern of high-quality contributions and trust in a person’s ability to steward the project.

We’re particularly excited about this because our mission isn’t just about deploying infrastructure - it’s about being good citizens in the open source communities we depend on. We invest in upstream contributions, participate in community governance, and aim to build the kind of relationships that strengthen the whole ecosystem. When our team members are welcomed into upstream project teams, it’s a signal that we’re doing this well.

Learn more #

JupyterHub team compass - how the team is structured and how new members are added
JupyterHub proposal to add Jenny to the team
nbgitpuller and grafana-dashboards - projects Jenny contributes to

Acknowledgements #

The JupyterHub community for fostering an open and welcoming project culture
Support from our member communities gives us the capacity to invest in upstream open source engagement and build relationships like this

Announcing our public roadmap for open development

Fri, 06 Feb 2026 00:00:00 +0000

At the core of 2i2c’s service is a commitment to doing our work in a way that follows open principles and practices. We commit to doing all of our work in the open and only managing and developing open infrastructure. As part of this effort, we’re shifting our strategy to lean more heavily into co-creation with member communities and open source communities.

Today we’re excited to share a first step towards making our development process more participatory, transparent, and useful: we’re opening up our initiatives roadmap. You can find it here:

👉 2i2c.org/roadmap

You can find all of our roadmap initiatives in this GitHub repository (please comment and engage with us there!):

👉 github.com/2i2c-org/initiatives

Moving forward, the roadmap will be a key part of our service to member organizations.

Why we’re opening up our roadmap #

At 2i2c, initiatives drive most of our work. They represent major chunks of value with multiple steps needed to implement and unlock it. They range from making core infrastructure improvements to our member network, to making upstream contributions that enable new functionality on behalf of our member communities. While initiatives are generally public, they are spread across many places, and we’ve managed their prioritization, sequencing, and refinement in internal team spaces. This made it difficult for others to follow along, signal-boost, and potentially support initiatives they wanted to see done.

For this reason, we decided to build a public view of our initiatives roadmap. This reflects our current team priorities and what is coming down the pipeline.

We’ve also put our platform initiatives in a public repository. This gives us a public space for member communities (or anybody else) to discuss, collaborate, and support ideas in the open.

By opening this up, we hope to accomplish these goals:

Make it easier for everyone to see and influence our priorities.
Make it easier for member organizations to fund or collaborate on work.
Make it easier for open source communities to see what’s driving our contributions.
Make it easier to give credit to member communities that fund work.

In short, we want to model what sustainable open development can look like. Our hope is that this will both create more transparency and trust with our stakeholder communities, and invite them to tell us how we can best use our team capacity.

We hope to use a shared roadmap to funnel more resources into open source #

We also hope we can leverage this as a shared roadmap across our member communities that helps focus our attention and drive fundraising for our work. To begin, we’re inviting any member community to provide financial support for these items as a way to influence our timelines and priorities, and we’re exploring ways to facilitate fractional co-funding across our member communities to help share the cost of development across many organizations.

This is an early experiment in collaborative and radically transparent development, and we will iterate and learn as we get feedback from member communities. We’re excited to see where this goes!

Please give feedback on this idea. If you’re interested in being a member organization of 2i2c, reach out to us about membership.

STRUDEL enables rapid scientific GUI prototyping in partnership with 2i2c

Tue, 27 Jan 2026 00:00:00 +0000

What happened #

The STRUDEL team hosted an all-day workshop with over thirty participants prototyping web applications using the STRUDEL Design System and AI assistants in a custom hub environment designed and managed by 2i2c. By the end of the day, all of the participants had a working prototype that incorporated their own data (or dummy data) into complex flows facilitated by the STRUDEL Design System.

After a brief introduction to STRUDEL, participants were guided on setting up their personal coding environments using the STRUDEL Hub that 2i2c managed. The hub was configured to launch a unique code repository for each participant that was set up pre-workshop on the strudel-workshops GitHub organization.

“Having a startup environment was very nice, as often getting a good development environment set up is half the battle for smaller projects.”

The hub used VS Code for the Web, pre-configured with the Cline AI assistant extension. Participants configured Cline with a shared API key generated by the STRUDEL team via OpenRouter. OpenRouter enabled the team to load credits into a shared account and API key that, in turn, enabled participants to use premium models inside of Cline.

“Super easy to set up Cline in the VM, I appreciated that”

The day was split up into four sprints during which participants worked on different parts of their user interface application, with the majority of the participants working entirely in the 2i2c environment.

“I just want to express my gratitude for such an awesome day today. The workshop was really well structured and facilitated, and I learned a lot. Thank you so much for letting me come!”

Why we’re excited about this #

We think it’s a great example of setting up a complex environment once, and then providing rapid access to these environments via a centralized hub.

This setup accelerated prototyping by removing the burden of setting up a development environment. The setup enabled participants, many of whom had never coded a web application or used an AI coding assistant before, to work seamlessly towards the goals of their design and development projects. The work they produced may continue beyond the workshop and have an impact on scientific discovery and operations.

This setup is a valuable mechanism for encouraging people to build within a pre-existing design system. Being able to launch repositories that are preconfigured with design system tools and templates is a powerful way to promote the adoption of a design system and its embedded patterns and best practices.

It’s also an interesting example of non-Jupyter interfaces orchestrated on a JupyterHub. The combination of VS Code for the Web, Cline, and OpenRouter represent a stack that can be easily transferable to other similar workshops. OpenRouter enabled the workshop team to manage the costs of AI usage entirely themselves.

In all, the participants and instructors were allowed to focus on their work instead of managing and setting up their infrastructure.

Links to learn more #

Learn more about the workshop on the STRUDEL website: strudel.science/engage/news/10-23-2025-building-scientific-uis-with-strudel-and-ai-assistants/
Explore STRUDEL + AI assistant tips and tricks: strudel-science/strudel-kit/blob/main/docs/docs/usage-with-ai.md

Acknowledgements #

We would like to thank all workshop participants. STRUDEL is an open source project housed at the Berkeley Institute for Data Science (BIDS) at the University of California, Berkeley. The STRUDEL team includes members of the Lawrence Berkeley National Lab Scientific Data (SciData) Division UX team, Superbloom Design, The Carpentries, and 2i2c. The project is generously funded by the Alfred P. Sloan Foundation, Liz Vu & Josh Greenberg Program Officers, grants G-2022-19360, G-2023-21098, and G-2024-22557.

April joins the Jupyter Community Building Working Group

Fri, 23 Jan 2026 00:00:00 +0000

We’re pleased to share that our People Operations Lead, April Johnson, has joined the Jupyter Community Building Working Group!

This kind of work reflects how we think about foundational contributions and upstream support: strengthening the social infrastructure that helps open source communities grow and thrive, not just contributing code and running infrastructure. April brings deep experience building teams and communities, and we’re proud to support her upstream efforts in this way.

Acknowledgements #

Thanks to the Jupyter Community Building Working Group for their leadership in building a stronger Jupyter community, and for welcoming April

2026 Strategy Update: An increased focus on co-creation

Mon, 12 Jan 2026 00:00:00 +0000

As we wrapped up 2025, we felt compelled to incorporate what we learned over the year into our strategic direction, and to update our organizational documentation accordingly. Here’s a quick rundown of what we learned and how we’re adjusting.

You can check out all of our core strategy documentation in our Team Compass.

The macro view from 2025 #

2025 was a disruptive year. The shifting political and economic climate creates a lot of uncertainty around how the research and education space will be resourced and structured moving forward. Federal funding seems less likely in general, and private philanthropy has become more competitive as many organizations turn to these funding sources to make up the gap that the government has left.

At its core, this makes us more confident in our sustainability strategy, which is rooted in a self-sustaining service that delivers value to many different member organizations in exchange for funds to support our operations. In 2024 we received funding from The Navigation Fund to build this model, and it’s the path we’ve been exploring over the last year. We like the fact that this spreads the financial risk across many different organizations, rather than depending strategically on a single donor or government agency. That said, there may still be sector-wide changes that cause the entire ecosystem of research organizations to change behavior at once.

Frankly, it is hard to predict what the future is going to look like. 2i2c is a “second order” recipient of research funding, as our member organizations provide us support to manage infrastructure and facilitate open source contributions. How these institutions respond to funding cuts will have big implications for our sustainability. For example, these two outcomes both seem reasonable:

Scenario 1: Institutions cut all of their “nice-to-have” funding choices. That means 2i2c struggles to cover its costs under its current membership model.
Scenario 2: Funding cuts create an increased need for shared infrastructure and services, and 2i2c is seen as a more cost-effective provider compared with bespoke self-managed infrastructure.

Our goal is to learn which of these two realities will come to pass as quickly as possible, so that we can make the necessary organizational changes and get ahead of the outcomes.

We’re being conservative about our hiring and team structure - we don’t plan on making new hires until there’s more financial certainty. With our current membership and contract structure, we have somewhere around 10-11 months of runway. We consider ourselves lucky in the grand scheme of things, but this is still a shorter runway than we’re comfortable with in the long-term.

How member communities see value in our service #

We had a chance to test out several organizational hypotheses about the core value of our organization and service. We originally framed “premier” membership as a means of accessing “more” community hubs for larger communities. However, we learned that for many organizations “more hubs” is not what they want, even if they have a large community. It certainly isn’t the core driver of value for their service.

Instead, our most successful member organizations seemed to view their membership as a combination of a few things:

Collaboration with our team, and the ability to work with us in shaping and delivering open source work.
Proximity to others to learn from in open science and open source, and an ability to participate in open source spaces more effectively.
Managed infrastructure that acted as a technical scaffold to make iterations of development more efficient, and made new enhancements immediately accessible.

Managed infrastructure was a necessary, but not sufficient, part of our value proposition. This makes sense - managed open source infrastructure is a commodity, and our organization is simply not competitive on price when it comes to commodity-level infrastructure (even with constraints like the Right to Replicate).

At the same time, some of the biggest successes of last year came out of deeper partnerships and development efforts that were made more likely by membership. For example, we deepened our collaboration with NASA VEDA and Development Seed and created several interesting new pieces of technology, like jupyterhub-fancy-profiles. We also felt this strongly at JupyterCon 2025 - here’s a quote by Yuvi from our team’s JupyterCon retrospective:

The unique value we add is that we help communities navigate the fairly complex and fast moving ecosystem of interactive computing, by helping them make choices that work for them. We do this by understanding their needs, understanding the ecosystem, and both making connections when they exist, and creating new ones (in ways that integrate with the existing ecosystem) when necessary.

Historically, we’ve treated these kinds of deeper partnerships as “one-off” opportunities that we take on a case-by-case basis. Given the impact that we’ve seen out of these kinds of engagements, we’ve decided to incorporate them into our service and sustainability strategy directly.

How we’re adjusting the value proposition and operations of membership #

We’re updating our strategy to center the value of human connection, collaboration, and development as part of our service, and incorporating it in our business objectives as well. This is a way to dedicate more organizational resources to this kind of impactful work, and helps us hedge our bets against a slower potential growth from standardized memberships.

Here are a few highlights from these changes (taken from our core strategy):

Our theory of impact now includes an explicit callout to the need for 2i2c to facilitate an exchange of ideas and resources between research communities and open source communities.
We’ve adjusted the language of our strategy such that managed infrastructure is a “necessary but not sufficient” aspect of member value. Members must be able to trust their infrastructure, but the real value comes from cycles of development and collaboration that is made easier by managed infrastructure.
Our key challenge is thus building a shared “development and operations” service in a way that serves multiple communities without the cost structure of a bespoke consultancy.
We have a few ideas for how to do this, and a key starting point is to define a shared roadmap and a selective group of member organizations that we can engage collectively.

Or, if you’d like to just get a quick summary, here is the strategic approach that we’ve defined for the team:

We serve independent communities with a single roadmap and service team.

Operations must use the same 80% infrastructure stack across all communities. Say no to communities that need infrastructure that deviates from this rule.

Development work must be attached to roadmap items. Roadmap items must deliver value to many communities instead of just one. Say no to project opportunities that deviate from this rule.

Our assumption is that by constraining ourselves to serve multiple member communities, we’ll force ourselves to make the technology useful for the broader open source user ecosystem as well. By choosing communities that are aligned in their workflows and values, we’ll be able to do this with a single team and roadmap in a cost-effective way.

Hypotheses we’d like to test next #

You can find more information about how we’re operationalizing this in our service model and annual plan pages - we’ll adjust these as we learn. Our next step is to test these hypotheses as quickly as we can:

By choosing the right communities for membership and building an accessible process around our team’s priorities, we can define a shared roadmapping and development system that is scalable to all of our members, and that they all view as valuable.
By engaging member communities in this way, we will have a significant new stream of revenue to sustain the organization while making open source improvements that are broadly useful.
By engaging member communities in this way, we’ll be able to advertise the value of this service as collectively improving a public good. This will increase our hit-rate for new member growth and participation.

What we’re watching for in 2026 #

2026 is going to be a pivotal year for the organization - I suspect it’ll force us to either double down on our current sustainability model, or to pivot towards something that is lighter given the new funding realities that the sector is facing. We are watching for whether research institutions begin cancelling or scaling back their contract work en-masse, and we’re also being mindful for whether our assumptions about a “shared roadmap” across our communities are actually delivering the value to them that we’d expect.

We’re excited to lean into this more active and collaborative aspect of our service. We’re confident this will be more impactful for our member organizations, and for the broader ecosystem. We’ll keep folks updated with our progress via our blog and our mailing list as always.

Supporting NASA Openscapes Champions with Cloud Infrastructure

Sun, 30 Nov 2025 00:00:00 +0000

Openscapes ran a NASA Champions program in November, bringing 30 participants together to learn about NASA Earthdata and the earthaccess Python library. We provided JupyterHub infrastructure for hands-on breakout sessions - a good example of using shared infrastructure to facilitate learning and collaboration in remote events.

They used their JupyterHub for co-working, where participants practiced streaming techniques for accessing cloud data without downloading. Multiple NASA Data Centers (NSIDC, ORNL, ASDC, PO.DAAC) collaborated to co-teach using the shared environment, succeeding despite the event happening the day after a government shutdown.

They also used this to grow the OpenScapes community by getting attendees to join their slack and sign up for their December Earth Access hack day. It’s a great example of leveraging shared community infrastructure to help newcomers learn quickly and join a science community.

Read their full event summary to learn how they structured the program and engaged their community.

2i2c at JupyterCon 2025: Helping communities navigate the Interactive Computing ecosystem

Thu, 20 Nov 2025 00:00:00 +0000

This year several team members attended JupyterCon 2025 to show off our own work and the upstream work that we’ve been doing in open source. JupyterCon recently shared the videos of all talks, so here’s a quick run-down of 2i2c’s contributions and where you can watch more.

Building computational narratives with Jupyter Book #

Introducing Jupyter Book 2: Next-generation Tools for Creating Computational Narratives - Chris Holdgraf and Rowan Cockett ( Curvenote) introduce the next generation of Jupyter Book, built on modern tooling and designed for creating rich computational narratives.

Tutorial: Build-a-Jupyter Book With the Turing Way - Angus Hollands co-led this hands-on tutorial teaching participants how to create their own Jupyter Books using examples from the Turing Way.

JupyterHub’s evolution and sustainable operations #

Not Just for Notebooks: JupyterHub in 2025 - Yuvi Panda explores how JupyterHub is evolving beyond just notebooks to support a wider range of interactive computing workflows.

Cloudy With a Chance of Savings: Per-User Usage and Cost Monitoring for JupyterHubs in the Cloud - Jenny Wong presents our recent work improving tools and approaches for monitoring per-user cloud costs in JupyterHub deployments, helping communities operate more sustainably.

Lightning Talk: Controlling Home Directory Costs (with User Empathy) on the Cloud - Yuvi Panda shares practical strategies for managing home directory storage costs while keeping user experience in mind, using jupyterhub-home-nfs.

Finally, there were also several talks that weren’t by 2i2c team members, but were partially enabled by 2i2c’s collaboration. We’re particularly proud of these, because it’s an example of us bringing others into the ecosystem and empowering them to contribute.

Understanding the JupyterHub community #

Findings from the Voices of JupyterHub report - This community strategy talk shares insights from conversations with JupyterHub users and operators about their needs and challenges. It’s not given by a 2i2c team member, but many of us have been involved in guiding (and being participants in!) this project.

MyST-ifying Project Pythia - Julia Kent of NSF NCAR discusses Project Pythia, an open-source platform dedicated to educating geoscientists on Python for complex Earth data analysis. Learn how Project Pythia manages its expansive repository of “cookbooks” and educational content, detailing their strategic shift to MyST Markdown and Jupyter Book 2 to drastically improve project sustainability and reduce maintenance overhead.

How CryoCloud built a healthy open science community #

Building a successful open science community in the cloud - Tasha Snow shares key insights from running the CryoCloud JupyterHub, emphasizing that a successful scientific community relies on both technology and social innovation. She shares data-driven results on how shared JupyterHubs can significantly reduce research computing costs and accelerate scientific iteration. She also explores the critical balance between platform capabilities and the need for social infrastructure to overcome technical barriers and foster true collaboration.

Yuvi on scaling maintainer intuition to facilitate PR review with PR triage boards

Wed, 19 Nov 2025 00:00:00 +0000

Yuvi has a recent post on the Jupyter blog on how his “maintainer intuition” about reviewable pull requests grew into the open-source pr-triage-board-bot, a reusable workflow that keeps GitHub Project boards curated for the JupyterHub, JupyterLab, and GeoJupyter communities. Foundational contributions are rellay important to 2i2c. This is a great example of building clever technical systems that help maintainers prioritize the social work of facilitating contributions to keep ecosystems healthy.

The JupyterHub PR Triage board.

Our favorite quote shares the vibe and cultural principles that drive this effort:

If the author of the PR is a newish contributor, I want to encourage them to stick around by being responsive to their gift. All PRs are gifts that we may or may not choose to accept, but should do so with grace.
Yuvi

Yuvi frames the problem here:

Reviewing PRs is a critical way that maintainers keep an open source project moving forward, but identifying PRs that can productively be merged is hard.

And notes that human scalability is often a big bottleneck:

One key bottleneck we identified in the process was Step 2. In particular, I was relying on my maintainer intuition to pick a single PR that I believe can be merged, so others in the team can do review work. I started exploring what this intuition is, and if it can be scaled.

Here’s his list of “intuitions” that he uses to choose PRs to work on:

PRs that aren’t too big, and are a reasonable size that can be merged within a 2 week window

CI tests passing, so at least our automated checks haven’t caught any issues with it Features or bug fixes that I believe add value to the project and move us in the right direction towards being able to support our users as they need (this is the hardest!)

If the author of the PR is a newish contributor, as I want to encourage them to stick around by being responsive to their gift. All PRs are gifts that we may or may not choose to accept, but should do so with grace.

How long ago the PR was opened. There is such a big difference between a response to your PR 2 days after you make it vs 2 months vs 2 years. I prioritized newer PRs.

What kind of contribution is it primarily? Different engineers on our team have different skillsets (JS, Python, etc) and I wanted to match the PR to what the engineer preferred code reviewing.

And the board essentially tries to capture many of these intuitions by signal-boosting them in one place:

we can roughly say ‘Pick a PR that looks good to you from the top of the “First Time Contributor” or “Seasoned Contributor” list’, and that relieves me from being the bottleneck quite a bit.

Read more in the original article: Scaling “Maintainer Intuition” with Pull Request Triage Boards.

Acknowledgements #

Project Jupyter for trusting us to incubate and now donate the bot code to the broader ecosystem.
JupyterHub and GeoJupyter contributors who tested the triage views and fed real maintainer workflows back into the design.
Jason Grout, Raniere Silva, and Matt Fisher for spotting the experiment early and helping it land across multiple orgs.

Debisree Ray on her positive JupyterCon 2025 experience

Mon, 17 Nov 2025 00:00:00 +0000

We spotted a great post by Debisree Ray about JupyterCon 2025 on the Women in Technology blog. It’s full of thoughtful reflections about the community and the conference, and we wanted to share a few highlights.

Image from Debisree Ray’s post

On the JupyterLab Extensions workshop:

I chose to attend Developing JupyterLab Extensions, led by the Jupyter core contributors. It was one of the most practical, empowering workshops I’ve attended.

Once you understand the architecture, building a JupyterLab extension feels less intimidating and more like unlocking a creative superpower.

On the community spirit:

On the first day, while setting up my extension environment, I got stuck during execution — and before I knew it, several attendees (not just instructors!) jumped in to troubleshoot with me. That moment captured the true spirit of JupyterCon: a room full of brilliant people who genuinely want to help one another succeed.

The openness, kindness, and inclusiveness of this community are unmatched. Everyone — from first-time contributors to long-time maintainers — collaborates with respect and a sense of curiosity.

On the Jupyter ecosystem’s growth:

Jupyter is no longer just about notebooks — it’s powering AI workflows, enterprise analytics, and reproducible research pipelines at scale.

Read the full post for more about Debisree’s week in San Diego, the community sprint, and other key takeaways.

Acknowledgements #

We didn’t do any of the work in this post but do have some context from the Jupyter community that led to it being written and discovered, so here’s a brief “thank you” nonetheless…

Thanks to Debisree Ray for writing such a thoughtful reflection and sharing it publicly. And thanks to Matt Fisher from GeoJupyter for spotting the post and bringing it to our attention. Thanks also to Rick Wagner and Jason Grout for creating the slide as part of the executive council update.

Community learning: Hub config to pass oauth tokens into user environments

Thu, 06 Nov 2025 00:00:00 +0000

One of our favorite things to see: communities learning from and building on each other’s work!

MAAP recently contributed infrastructure configuration inspired by EarthScope’s approach to handling authentication tokens. Both communities need to pass OAuth tokens into user environments so their SDKs can access protected data - and MAAP adapted EarthScope’s pattern to fit their needs.

This is the kind of peer-to-peer knowledge sharing we hope to foster with our open infrastructure model. When infrastructure is open and communities can see each other’s solutions, they can adapt and build on proven approaches rather than starting from scratch.

Learn more #

MAAP’s PR adapting the configuration
EarthScope’s original config
Our infrastructure repository where all community configurations live

Acknowledgments #

MAAP team for adapting and contributing this configuration
EarthScope Consortium for the original implementation

Refactoring Jupyter Book 2 documentation ahead of a major release

Sat, 01 Nov 2025 00:00:00 +0000

Documentation is what turns open source code into products that people actually want to use. We recently spent a few days refactoring the Jupyter Book documentation to prepare for the upcoming Jupyter Book 2 release, and we’re excited about how much clearer the docs have become!

What we did #

We restructured the docs using the Diataxis framework to better organize content by user type and task:

Reorganized into clear topic areas with landing pages for easier navigation
Added missing content like the feature voting table and contributing guides
Created upgrade guidance to help users understand the relationship between Jupyter Book 2 and MyST

This work helps users find what they need faster and gives the project a stronger foundation to build on going forward.

Why we’re excited about it #

Better documentation reduces maintainer burden by helping users answer their own questions, and it makes the project more welcoming and useful to new contributors. We hope this makes Jupyter Book more accessible to everyone and lays a good foundation for the new release!

We’re also excited because so many others helped provide edits and comments!

Learn more #

Acknowledgements #

Thanks to @rlanzafame, @FreekPols, and @bsipocz for their helpful reviews, edits, and feedback on the PR!
Project Pythia, CryoCloud, NASA Open Science / ScienceCore, and the Berkeley educational projects are our primary member communities using MyST and Jupyter Book. Their support covers the cost of these kinds of foundational contributions.

2i2c Supports the Science Platforms Coordination IHDEA Working Group

Thu, 30 Oct 2025 00:00:00 +0000

The Science Platforms Coordination IHDEA working group (which includes our own Jim Colliander) is developing international standard software computing environments for Heliophysics. The working group recently presented their work at two major conferences: ML-Helio in Madrid and DASH/IHDEA in San Antonio.

The DASH/IHDEA 2025 conference brings together the heliophysics community to advance data, analysis, and software standards

When the working group received $2k from NASA SMCE for cloud infrastructure, they were already member organizations of 2i2c. This meant we could quickly stand up a JupyterHub with their Heliophysics-tailored environments for the conferences:

Easy access - Shared password authentication for conference attendees
Persistent storage - Work saved across sessions
Serious compute - Up to 119 GB RAM and 15 CPUs (much more than a typical laptop!)

The team successfully demonstrated how cloud resources can enable computational work that laptops simply can’t handle, and conference attendees responded positively to the presentations.

Why we’re excited about this #

This showcases a key benefit we want to create with 2i2c membership: reducing the accidental complexity of leveraging the cloud. Because the working group was already a member organization, deploying and managing infrastructure for the conferences was straightforward once they secured cloud funding. No lengthy setup, no new contracts - just quick deployment of the tools they needed.

Learn more #

ML-Helio Conference - Machine learning in heliophysics
DASH/IHDEA Conference - Data, analysis, and software in heliophysics

Acknowledgements #

NASA SMCE for providing $2k funding and AWS infrastructure
Shawn Polson for being the community champion leading this effort
The IHDEA working group for their collaborative partnership in advancing Heliophysics research infrastructure

BIDS joins as 2i2c's first premier member organization

Wed, 29 Oct 2025 00:00:00 +0000

We’re thrilled to announce that the Berkeley Institute for Data Science (BIDS) has joined as 2i2c’s first premier member organization! This partnership marks a significant milestone in our sustainability strategy and recognizes a relationship that’s been central to 2i2c’s story from the very beginning.

BIDS Executive Director Kirstie Whitaker and 2i2c Executive Director Chris Holdgraf discuss the partnership at the membership launch event.

What this partnership means #

As our founding premier member, BIDS is financially supporting 2i2c while helping us design our member network services and relationships. Together, we’ll work on:

Co-designing member services - BIDS will provide feedback and guidance as we develop how our member network operates
Technical collaboration - Partnering on JupyterHub development, cloud infrastructure improvements, and other open source projects
Strategic input - Advising on 2i2c’s direction and approach to strengthening open source communities

This gives us a foundation for both technical and social collaboration, and we hope it opens doors to deeper partnerships across the Berkeley community.

Berkeley has long been a leader in open source software development. This partnership lets us share our knowledge and support community development of open source infrastructure across institutions.

Kirstie Whitaker, BIDS Executive Director

Why we’re excited about this #

For open source: BIDS has been a leader in supporting open source and cross-disciplinary open science for many years - helping to shape projects like NumPy, scikit-image, NetworkX, and JupyterHub. Their feedback and partnership will help us improve our impact across the entire ecosystem.

For sustainability: This is the first paying member of our new membership model, which is a key part of our long-term sustainability strategy. It demonstrates that organizations value what we’re building and want to invest in shared open source infrastructure.

For 2i2c: BIDS has been part of our story from the beginning, and this partnership recognizes the continuing influence and support we’ve received from the organization.

Learn more #

Read the full announcements from our partners:

Acknowledgements #

The Berkeley Institute for Data Science and the entire BIDS team
UC Berkeley’s College of Computing, Data Science, and Society

Communities learning from one another - Project Pythia and ICESat-2 Hackweeks

Tue, 21 Oct 2025 00:00:00 +0000

We wanted to share a short vignette about two of our communities learning from one another.

At the latest Project Pythia community meeting, Project Pythia met with representatives from ICESat-2 to share learning about notebooks and cookbooks in educational settings.

Anthony Arendt from UW’s eScience Institute shared how they’ve used educational notebooks in their hackweek programs. The discussion explored ways to improve cookbooks, especially for large collections that require different computational environments, sparking ideas about higher-level abstractions for organizing educational content. There is a lot of overlap in the needs and workflows of these communities, and we’re hopeful they can find ways to re-use one another’s ideas, content, and infrastructure.

One of our service goals is to make it easier for our member communities to learn from one another - using standardized tools and infrastructure means we can learn what works, what doesn’t, and collectively improve our workflows more quickly. We’re working on ways to encourage this kind of interaction in our member networks, so we wanted to celebrate this little win.

Learn more about these communities #

Project Pythia - An educational resource for geoscience computing with open-source Python
Project Pythia Cookbooks - Domain-specific example workflows for geoscience
ICESat-2 Hackweeks - Collaborative learning events combining tutorials, peer learning, and team projects

TIL: A few ways to track web traffic for open source projects

Sun, 19 Oct 2025 00:00:00 +0000

Understanding how people discover and navigate your project’s web presence is valuable for open source communities, but there are a lot of options out there and many maintainers may not know about them. Recently Chris did some research to improve the web analytics for Jupyter, and learned about several options for tracking web traffic¹. Here’s a quick report of what stood out.

Three analytics tools we found helpful #

Plausible.io - A privacy-friendly, GDPR-compliant analytics service

Clean interface with public dashboards (see Jupyter’s dashboard)
Paid service but offers 15% discount for open source projects
Cost scales with traffic volume. It can get expensive for a project as big as Jupyter!
This is the service we ultimately ended up using…

ReadTheDocs Analytics - Built-in traffic tracking for documentation sites

Available as a free add-on for ReadTheDocs projects, it provides traffic data specific to documentation pages.
There’s no additional cost if already using ReadTheDocs, though if you’re on a business plan you may need to pay for it.
The analytics are a bit barebones, but quite useful for learning where your readers are navigating.
Enable in Settings > Addons > Analytics.

GitHub Repository Analytics - Native analytics in GitHub.

Shows clones, views, and referring sites. This is also fairly barebones, but it’s really useful to see who is actually looking at your repository.
Free for all GitHub repositories.
Access via Insights > Traffic on any repository.

Learn more #

GitHub issue coordinating Jupyter’s analytics work
Plausible.io public dashboard for jupyter.org (this might be down for now, but we’re working to bring it back up)
ReadTheDocs Analytics documentation
GitHub Traffic Analytics API

Acknowledgements #

Thanks in particular to Jason Grout from the Jupyter Executive Council for collaborating on this investigation and helping test these tools.

Chris has been serving on the Jupyter Executive Council as a Foundational contribution. This was related to that effort! ↩︎

Celebrating BIDS as 2i2c's first premier member at UC Berkeley

Wed, 15 Oct 2025 00:00:00 +0000

We’re celebrating BIDS (the Berkeley Institute for Data Science) as 2i2c’s first premier member at an event at UC Berkeley on Thursday, October 15th. If you’re in the Berkeley area, we’d love for you to join us! Event page here.

This is a milestone for 2i2c and demonstrates BIDS’s commitment to open infrastructure and partnership. As our first premier member under our new membership model, BIDS is helping us build a more sustainable path forward while strengthening our collaboration for shared impact in open science.

Learn more #

Acknowledgements #

Thanks to The Navigation Fund for funding the strategic roles that have led to this new membership model.

Openscapes is hiring a new team member

Tue, 07 Oct 2025 00:00:00 +0000

Openscapes is hiring a NASA Openscapes Suborbital Team Member to engage with NASA suborbital science teams and support open science practices. This is a part-time contract position (20 hrs/week) starting as early as December 1, 2025, with a 6-month initial term and potential for extension. The position is fully remote ($100/hr) with applications due by October 26, 2025.

Learn more #

Openscapes job posting

Acknowledgements #

Openscapes for their continued work in empowering the research community

2i2c's submissions to JupyterCon 2025

Sat, 19 Jul 2025 00:00:00 +0000

Update: The talks are now live! See this blog post with links to our videos.

We were excited to hear that JupyterCon is happening again in 2025. The Call for Proposals just wrapped up, and our team was involved in preparing and submitting several directly from 2i2c as well as from the ecosystem in general.

Enjoy brief summaries of the proposals we contributed to below. Let us know if you have ideas for future talks you want to hear from us?

Note: Many of these submissions were written in collaboration with others in the open-source projects we participate in. Particularly, in JupyterHub and JupyterBook.

JupyterHub: A multi-user server for Jupyter notebooks #

This is how JupyterHub was described when it was announced in 2015, 10 years ago. The focus was on bringing Jupyter Notebooks to multiple users on shared infrastructure. The Jupyter Notebooks focus was so strong that Jupyter was even in the name of the project! Fast forward 10 years, & this is still the most common perception of JupyterHub.

However, this has not been true for a long time now. Instead of setting up 5 different kinds of infrastructure to support your users based on what kind of interface they like to use ( JupyterLab, RStudio, Linux Desktop tools like QGIS or Napari, Visual Studio Code, full ssh (!?), etc) for their interactive computing, you can set up a JupyterHub that supports all of those! Meet your users where they are, rather than force them to conform to using only a specific set of tools.

Come to this talk to:

See cool demos of various popular applications running on JupyterHub seamlessly
Understand the security model of JupyterHub & how that enables these cool demos
Learn how you can set up your own application to run in JupyterHub
Influence the future of how JupyterHub is marketed

Cloudy with a Chance of Savings: Per-User Usage and Cost Monitoring for JupyterHubs in the Cloud #

Cloud cost monitoring is moving beyond just preventing runaway cost explosions – it’s about empowering JupyterHub administrators with the guardrails they need to run efficient, transparent, and sustainable infrastructures. A cloud cost bill can show a broad view of services and machines provisioned, but how can we provide granular insights into each user and the value they are deriving from the hub on an application level?

We’ve developed several open-source components towards answering this question:

Metric Collection – Prometheus collects resource usage metrics (including CPU, memory, and storage) from individual user pods via standard and custom exporters.
Cost Estimation – Usage is correlated with AWS cost data to estimate per-user costs.
Visualization – Grafana dashboards display rich, interactive views of usage and cost data, making it easy to monitor trends, identify high-cost workloads, and generate reports for funders and decision-makers.

This approach delivers cloud observability and cost transparency that can be reliably deployed using Kubernetes and integrated with Zero to JupyterHub distributions.

Controlling home directory costs (with user empathy) on the cloud with jupyterhub-home-nfs #

User home directories on JupyterHubs deployed in cloud providers has been a pain point for both end users and administrators. Administrators feel the pain of cloud costs for home directory storage (sometimes higher than compute!). No user wants to receive an email saying “well, this code you copy pasted downloaded 3TB of netcdf files into your home directory, and now we have used up our entire team’s cloud budget for the next 2 years” (true story).

The jupyterhub-home-nfs open source project is a JupyterHub native, cloud agnostic solution to these problems. Administrators can do per user limits, tune performance, report on usage and make cloud cost conscious choices around overprovisioning. It provides users empathetic guardrails to prevent them from overuse, rather than punitive gates that zap them after the fact.

In this short talk, we will:

Describe the core of the problem, and how it manifests for users and admins.
Review current solutions and their limitations
Introduce jupyterhub-home-nfs and how it moves the solution space forward
Demo how this looks like for an end user
Talk about future direction, and opportunities for collaboration

Rebuilding user trust in `mybinder.org` #

Have you clicked a mybinder.org link, waited for it to start and gave up after it took far too long to start? Or just failed?

Have you stopped using mybinder.org for your tutorials, repositories and presentations because you could no longer rely on it to work each time?

mybinder.org is open infrastructure run by incredible volunteers (who go above and beyond constantly) in the Jupyter community. Is ‘slow fade into unreliability’ just the fate of all openly run infrastructure?

But perhaps maybe, just maybe, you have tried doing that again recently, & noticed improvements! Launches are more reliable. Faster. The UI looks better. Maybe things are getting better?

This talk will go through the problems facing mybinder.org & what we are doing about it. Come to this talk to find out:

How is mybinder.org run?
What are the structural issues facing open infrastructure services like mybinder.org?
What sustainability experiments are we running to improve reliability and rebuild user trust?
Has reliability actually improved?
How can I help?

Can your JupyterHub handle your workload? Performance testing with `jupyterhub-simulator` #

Your JupyterHub is all set up, and you’re excited to use it for your workshop of 60 students. Or your class of 600 students. Or your research group of 5 people with complex workflows.

You feel your infrastructure should hold up fine, but do you know if your infrastructure will hold up fine? Is that just excitement, or is there a little bit of nervousness in there too? Wouldn’t it be nice to test and know for sure?

jupyterhub-simulator is an open source project that allows you to describe what you expect your users to be doing - starting servers, clicking on nbgitpuller links, running notebooks, etc. Once you have described it, you can then simulate any number of users doing that workflow simultaneously, and verify that your JupyterHub can handle that workload. If it can’t, tweak your infrastructure and try again until it does!

In this talk you will learn:

What is jupyterhub-simulator?
How can I describe my expected workflow?
How can I test if N users can do this workflow all simultaneously?
How can I visualize the performance of my infrastructure so I can tweak its configuration and try the simulation again?

Not just for notebooks: JupyterHub in 2025 #

JupyterHub: A multi-user server for Jupyter notebooks

Come to this talk to:

See cool demos of various popular applications running on JupyterHub seamlessly
Understand the security model of JupyterHub & how that enables these cool demos
Learn how you can set up your own application to run in JupyterHub
Influence the future of how JupyterHub is marketed

Introducing Jupyter Book 2.0 #

This is a community talk from the Jupyter Book team, detailing the principles behind the new MyST Document Engine and Jupyter Book 2’s upcoming release. We’ll share the text when the Jupyter Book team posts it publicly.

You don’t need to contribute more to open source, you need to go to therapy #

Open source communities can be incredible and irreplaceable sources of human connection in our lives, offering a unique kind of fulfillment hard to find elsewhere. This feeling of fulfillment and approval can, for some people, be a soothing balm in an otherwise rough life. However, it has the be part of a healthy, balanced ecosystem of different kinds of connections offering different kinds of fulfillment . If a significant chunk of fulfillment in your life comes from the open source work you do, unbalanced by other sources, that can quickly become unhealthy for both you and the community. Disagreements are more likely to become high stakes. Interactions can quickly become emotionally charged and filled with hard to interpret subtext. This can both burn you out, and drive away potential new community members.

This talk explores the why emotional regulation is a critical skill for participating in open source communities, and how therapy can be a tool for learning that skill. Come to learn:

What is emotional regulation?
Why should I care?
What is therapy and how can I access it?
Wait that’s not what I thought therapy was! Are you telling me Missy Armitage lied in Get Out?!
What negative effects do communities feel?

What 2i2c has learned while trying to build sustainable relationships with Jupyter’s community. #

2i2c is a non-profit organization that fosters co-creation and collaboration between science communities and open source communities. We are deeply embedded in an international network of research and education communities, as well as open source communities that underlie their infrastructure (particularly in the Jupyter ecosystem). Our technical infrastructure is built entirely with open source components that we contribute to, but do not control. This is a really hard problem to solve!

We’ve learned a lot in the first four years of our existence. This talk will describe how our organization approaches a healthy and productive open source relationship with the Jupyter (and broader scientific python) ecosystem. It’ll cover some of the major mistakes we’ve made, lessons learned, and where we think we’ve had impact. We aim to make this talk full of practical learnings that others can follow in building sustainable open science organizations that contribute to a healthy and vibrant open source ecosystem. Our goal will be to provide inspiration to others that are interested in building on top of open source projects like Jupyter, and want to do so in a way that is healthy and sustainable.

Solving classes of problems, rather than just an instance of a problem (with an example)

Mon, 09 Jun 2025 00:00:00 +0000

The Problem #

Two of our the communities we serve ( NMFS Openscapes and CryoCloud) reported issues with starting GPU nodes on their hubs. Upon investigation, I discovered that the cluster autoscaler seems to not recognize that GPUs were available in the cluster at all suddenly, and hence wasn’t provisioning the nodes. A restart of the cluster-autoscaler pod fixed the issue for both these communities.

An incomplete solution #

But is that the end of the story? Not if we want to provide reliable long term infrastructure to communities with minimal toil on the part of 2i2c engineers!

One of the engineering principles I’m trying to have us more intentionally and structurally embody is the idea that we don’t fix individual instances of problems, but whole classes of problems, rather than just an individual instance of the problem. Fixing the immediate issue is not enough - we need to understand what class of issues was manifesting itself in this particular fashion, and fix that.

What was the class of issues we could fix here? #

Digging in, I realized that our version of cluster-autoscaler was a little behind and not the latest. I presumed this was a bug in cluster-autoscaler (given a restart fixed it, implying it is a bug about state). To me, the class of problem here is that we were not rolling out releases to our “supporting infrastructure” fast enough. Perhaps if we were on the most recent cluster-autoscaler release, this issue would have never happened.

Additionally, this failure to scale up was reported to us by the community rather than by an automated alert. We should change that too!

Structured solutions #

We follow a two week sprint cycle, and I love the (hard won) structure it provides us. I don’t want to arbitrarily start doing work that upsets prior committed work from that structure. However, we also treat support requests seriously and try to work them into the sprint. So I timeboxed myself for one hour, and saw what I could accomplish. Turns out, a lot!

I upgraded all our support components, tested them, and rolled them out to all our communities! This included upgrading Grafana, Prometheus, nginx-ingress as well as the cluster-autoscaler. This also restarts the cluster-autoscaler across our clusters, fixing this issue for other communities (if any had it).
I re-enabled the automatic once a month PR for upgrading these support tasks. We had switched to doing them on a manual sprint cadence, but clearly that was not fast enough nor automated enough. We will instead work these into the sprint once the bot opens the PR. Credit to Erik Sundell for initially setting this up
Create an issue to track the alert creation, and put it in our sprint backlog.
(In an additional fifteen minute timebox) Write this blog post, to communicate out both to the affected communities and others what we have done.

By timeboxing myself, I didn’t upset our sprint cadence and was able to continue doing other work I had committed to in the sprint, while also fixing this class of issues to the best of my ability.

Moving forward #

While we have been implicitly trying to solve whole classes of issues rather than individual instances of an issue as a team for a while, I want us to explicitly do it from now on. Communicating this out to our communities is an important part of that, as is internal team training. This blog post is the former, and we are continually working on the latter :)

Acknowledgements #

Thanks to the OpenScapes and CryoCloud communities for working with us closely on infrastructure to identify improvements like this.

Harnessing Marine Open Data Science for Ocean Sustainability in Africa, South Asia and Latin America

Tue, 11 Mar 2025 00:00:00 +0000

Thank you to Emilio Mayorga for sharing this publication.

Several community members, including Paige Martin (Australian Climate Simulator), Eli Holmes (NOAA Fisheries), and Emilio Mayorga (University of Washington) published case studies in Oceanography magazine’s “Vision for Capacity Sharing” issue.

Their article Harnessing Marine Open Data Science for Ocean Sustainability in Africa, South Asia, and Latin America highlights the benefits of hackweek-style collaboration and learning events to build capacity in underrepresented communities, using 2i2c-supported JupyterHub for seamless set up and effective data sharing.

More on these three specific initiatives is available at their respective websites:

COESSING, Coastal Ocean Environment Summer School In Nigeria and Ghana.
OHWe - OceanHackWeek en Español (in Spanish).
ITCOocean Hack2Week (an Indian Ocean program). Training Course & HackWeek On Machine Learning Based Species Distribution Modeling.

We’re happy to see these communities extend their impact and make interactive computing more accessible to participants around the world.

Chris is joining Project Jupyter's Executive Council

Mon, 10 Mar 2025 00:00:00 +0000

We are proud to announce that 2i2c’s Executive Director, Chris Holdgraf, was recently elected to Jupyter’s Executive Council. The 2i2c team discussed whether Chris should run for this position last year, and concluded that it was a way for our non-profit to both support Jupyter’s mission at a strategic level, and represent the interests of research and education communities in Jupyter’s direction. Chris wrote a blog post about his reasons for running with more information.

One of Chris’ goals is to be a transparent source of information about what the council is working on, where its priorities lie, and what are the major challenges it is trying to tackle. He’s written two blog posts that describe some of his experiences so far, at the links below:

We’re hopeful that this is a way for 2i2c to scale its impact and lean into its commitment to open technology. Chris intends to keep writing about his personal experience via his blog, and we’ll provide updates here for major developments that are relevant to 2i2c’s network of communities. We’re proud to have Chris in this role, and excited for his contributions to the Jupyter community!

Acknowledgements #

Strategic open source support like this is supported by a grant from The Navigation Fund and fees from our member organizations.

We need to improve the diversity of our leadership

Fri, 28 Jun 2024 00:00:00 +0000

As an organization committed to broadening access to interactive computing for global communities, we believe that a team embedded with diverse insights and lived experiences can more effectively advocate for underrepresented voices in our socio-technical partnerships. A diversity of team experiences helps us deliver a service that broadens and empowers participation in open-source science for all communities and leads to more effective teams that make better decisions.

As a young and growing organization, we have had mixed success in building diversity within our team. We’ve leaned into the values of our service that build trust and attract a broad coalition of community partners (and potential employees). For example, we’ve used the following pillars in describing our service:

Transparency – our transparent and participatory model keeps our incentives aligned with community needs.
Empowerment – our service gives communities agency to design the service they need, and to manage it without 2i2c if they wish.
Partnership – our communities are partners working towards shared impact, not customers to grow revenue.
Sustainability – our service should have a self-sustaining model that ensures continuity, growth, and funder independence.

We’ve also invested in creating an inclusive organizational culture via documents like our Team Compass and our Code of Conduct¹. We’ve experimented with inclusive hiring practices to encourage a diverse pool of applicants for our open positions, such as running open office hours for job postings in the hopes that this would encourage more people to apply who might otherwise have been hesitant (something that often correlates with people from historically marginalized communities).

The importance of diverse leadership #

However, over the past few months, we have reflected on our organization’s structure and future plans. In particular, we recognize that there is a worrying lack of women in staff leadership roles. This imbalance does not live up to our values of diversity in our team and service.

We need to do better.

2i2c is at a moment of maturation and growth as an organization, kicked off by our organizational audit from 2023 as well as our three-year retrospective. We believe that improving the diversity of leadership throughout the organization is a necessary part of that maturation over the next three years.

Below are a few ideas for how we aim to make improvements, and we invite feedback from others who are interested in helping us improve this aspect of our organization.

What we plan to do #

Over the next few months, we will work on a long-term DEI strategy in tandem with our sustainability strategy as we work towards scalable and sustainable networks of community hubs.

Here are some steps we aim to take to improve the diversity of our leadership across the organization:

Define our goals for diversity. First, we need a better understanding of the most important axes of diversity that we wish to design around. Gender is clearly a critical gap to cover, but there are many other important axes of diversity as well. For example, as an organization that serves a global community, it is important that we have global perspectives represented in our leadership.
Define mechanisms for leadership and governance that includes representation along these axes. Leadership at a staff level is one way to ensure representation of diverse perspectives, but there are many other ways to bring voices into the conversation. We aim to explore new ways of bringing diverse voices into the strategic direction of the organization and provide mechanisms for holding us accountable to our values. For example, we intend to grow a board to guide 2i2c’s strategy and hold its Executive Director accountable for achieving impact - this is another opportunity to bring diverse perspectives into our leadership.
Make a plan for improving leadership diversity within our team. Whatever mechanisms we create for diverse leadership, we know that one of them needs to be improving our diversity at a staff leadership level. Our staff are the ones that spend the most time working on - and have the most leverage over - our strategy and mission, and it’s important that our staff leadership is a good representation of the diverse perspectives of the communities we serve. This might mean investing more heavily in reaching broad applicant pools for new positions, seeking external consultation for how we can avoid unintentionally sending exclusionary signals to others in our communications and outreach and developing incentives to retain our talent over time.
Continue improving our systems of delivery and work. Finally, we believe that a crucial aspect of improving the diversity in our organization is to continue transforming our systems for delivery, reliability, and accountability across the organization. This effort is a crucial step for fostering an inclusive and equitable culture. We have made a lot of progress in improving our delivery systems and will continue this improvement as an organization.

We hope that this post both makes transparent a distinct lack of diversity within our organizational leadership and provides clarity for some of our plans to improve. We are excited about the organization that we have built so far, as well as being fiercely proud of our open-source culture and development practises. We still know that we must do better, and we’re fully committed to doing so over the coming years.

We often refer to the Project Include documentation in creating an inclusive culture and set of policies. ↩︎

Researchers at LEAP-Pangeo investigate overlooked sub-grid air-sea heat flux in climate models

Tue, 21 May 2024 00:00:00 +0000

Figure from the preprint showing large and small scale air-sea fluxes are separated. By Julius Busecke et al., licensed under CC BY 4.0

Julius Busecke et al. of the LEAP-Pangeo¹ hub, have recently published a preprint² that investigates “The Overlooked Sub-Grid Air-Sea Flux in Climate Models” using 2i2c infrastructure.

See Julius’ social media post for a more bite-sized outline of the work done.

Well done all! 🎉

Acknowledgements #

This research was conducted using the Pangeo ecosystem and infrastructure provided by 2i2c.

NSF Science and Technology Center (STC) Learning the Earth with Artificial intelligence and Physics (LEAP) (Award # 2019625) ↩︎
doi.org/10.31223/X5WQ47 ↩︎

Improvements to our team's planning and delivery

Mon, 15 Apr 2024 00:00:00 +0000

This is a follow-up to our 2023 report of organizational strengths and weaknesses, describing some improvements we’ve made on our team’s coordination and delivery.

In 2023, we released a report describing our organizational strengths and weaknesses. This uncovered a key challenge for our team: improving our coordination and delivery. Over the previous two years, our service had grown significantly in its scope and complexity. We were working on more than 7 active grants and were serving more than 70 active communities with around 7,000 monthly active users.

This was taxing our small team, and we found ourselves struggling to efficiently deliver on our work. For example, a collaboration with GESIS to bring image building functionality to JupyterHub took longer than we wished, and we felt that our planning and execution was not transparent enough to their team. In addition, in a collaboration to serve communities in Latin America and Africa we felt that 2i2c was not responsive enough to onboarding and deploying infrastructure for new communities.

Steps we’ve taken to improve delivery #

At the beginning of 2024, we hired our first Delivery Manager and Chief of Staff role as well as our first Product Lead role. Both of these roles are meant to develop systems and team practices that improve our planning and delivery.

In Quarter 1 of 2024, we designed and initiated an organizational transformation with the following goals:

Provide clarity about our overall organizational goals and strategy.
Define our near-term goals and major projects that drive our work.
Define and prioritize the major work items that feed into these goals.
Break this major work items into actionable items that our team can work on from day to day.
Provide visibility for all of this information across the entire organization.

Below is a brief description of the major changes that we’ve made. These are still a work in progress, and organizational transformation takes months, if not years, but we hope that this provides a useful snapshot in time as we kick off this process.

Our system of work #

Our team-wide system of work can be found in the Team Compass at the link below:

compass.2i2c.org/cross-functional/workflow/

This system of work attempts to link our strategic goals with concrete chunks of work to deliver. You can see an overview of this system below:

Our work system shows how initiatives are made up of lists of actions that accomplish them. These actions are distributed across our team’s operational boards for delivery.

It is roughly broken down into these major areas:

Our value proposition: Our system of delivery starts with a value proposition. This is a north-star statement for the value that 2i2c aims to provide to our communities in order to achieve our mission. It is a guiding principle for where we prioritize our time and improve our service.

While updating our delivery model, we decided it was time to update the value proposition we’d been informally using. We’re in the process of validating this value proposition with communities, and will share a draft for public comment soon!

Strategic goals and major projects: Next we define strategic goals that describe the most important progress we must make as an organization. This considers our current capabilities and challenges, as well as the major projects that we’re already committed to (like grants). Our initiatives (described below) should each represent progress towards one or more of our goals and major projects.

Strategic initiatives: These are major thrusts of work that represent progress towards our goals. They range in time from weeks to months, and generally require coordination and action across each of 2i2c’s functional areas. Initiatives exist in a dedicated board, where we shape and scope them with enough information to understand them and prioritize. Once an initiative is in progress, it begins driving work on a two-week planning cycle. All in-progress initiatives should make up a significant percentage of 2i2c’s total work allocation.

Operational boards: Operational boards are used to track our day-to-day workstreams. We organize into two-week sprints, with a collection of work pulled into each sprint according to in-progress initiatives and the other types of reactive and operational work on our plate (for example, responding to support tickets is reactive work). Within each initiative, we coordinate across our teams in order to understand the next steps needed and who is responsible for doing it. This helps teams plan the work for their next iteration.

This system is very much still a work in progress, and we’ve already identified a number of ways that we’d like to improve it moving forward. For example, we’d like to find more efficient ways of coordinating across our team, and encouraging team members to own their own work.

Changes to our team culture #

In addition to our system around planning work, we’ve also identified a number of ways that we can improve our team’s culture related to work. As a distributed organization, one of our biggest challenges has been the additional friction that comes with communicating across many time zones. It’s much harder to solve a problem or get help when responses come with long gaps of time.

As a result, we’ve defined several practices that will help our team members grow their autonomy and independence, while still moving towards the same targets and goals. This is ongoing work that we aim to continue developing over the next few months.

Professional growth. First, we’ve started an audit of 2i2c’s organizational roles and the responsibilities and the pathways for growth with each of them. This began with our engineering team, but will continue with other areas of the organization as well. We believe that defining professional growth trajectories will help identify the gaps in our team’s skills that make it more difficult to act efficiently and independently.

Giving and receiving feedback. We’ve defined team practices around giving feedback, and are encouraging a team culture of regular and constructive feedback to one another. We know that this will be a long-term investment in team practices, and we believe that any team (especially a distributed one) must be able to rely on its team members to help one another grow. We’ve begun this effort by creating a guide to giving feedback for 2i2c which we hope will be useful for others as well.

Decision making. We’ve defined a set of principles around decision making at 2i2c that encourage more autonomy and creativity. In a knowledge-driven field such as ours, it is important that team members have the freedom to be creative and take risks, and that we design systems that are resilient to mistakes. We aim to make mistakes Safe to Fail to encourage creativity and learning while de-risking major negative consequences. This document is a first step towards improving our team-wide practices at taking more initiative and action.

Iterative delivery and process improvement. Across each level of the organisation, we have been experimenting more deliberately with Agile delivery practices. These experiments shape our approach to planning (at both the team and organization-level), visualizing and managing our work streams, and improving our internal product delivery processes. We are agnostic to a specific Agile framework, and have found the most value in blending elements of Kanban, Scrum and Flight levels. We will continue to experiment with these practices, seeking to find a happy medium for 2i2c. We’ll share more on this soon :)

Coaching. Some members of our team have also begun benefiting from having regular 1:1 coaching to help their interpersonal development. Our team’s coaching support includes work to empower improving self-awareness, overcoming self-limiting challenges and gaining technical leadership mastery. Coupled with our growing practices around team feedback, we aim to build a culture where team members have both internal and external support to help them grow.

This work was done in partnership with

April Johnson, a Transformation Consultant and Coach. If you’re interested in working with April around any of this work we highly recommend doing so!

A continuous process of improvement #

We are still in the early days of this transformation. We hope that these practices will improve both our operational efficiency and also create a more enjoyable work environment where team members are empowered to have impact in the ways that they see best. We’re excited to lean into these challenges and grow as a team, because this is how we can grow the impact of 2i2c and deliver more value for the communities that we serve.

Principles and considerations for ethically accepting funding for open source

Sun, 08 Jan 2023 00:00:00 +0000

This is a brainstorm to consider the principles and guidelines that 2i2c should follow in defining its strategy towards open source communities. See our open source policy documentation for the product of this brainstorm.

Over the past year the 2i2c team has focused its efforts on deploying, configuring, running, and managing cloud infrastructure that supports open source workflows in research and education. We’ve also done a lot of upstream contribution as a part of our work.

However, we have shied away from taking direct funding for direct development work in open source projects. This is for two primary reasons:

Our focus has been on managing cloud infrastructure, not developing it. We want to facilitate access to open workflows in interactive computing, which is a different skillset and kind of work than creating those tools.
While 2i2c is aligned with the interests of open communities, we are still a distinct organization with our own mission and strategy. We want to be conscious that 2i2c team members have more than one hat, and that their 2i2c hat is necessarily not the same thing as their open source hat. As such, we don’t want to leverage our “other hats” to drive resources to 2i2c without being thoughtful about it.

In the last year we’ve found that running infrastructure for research and education gives us great visibility into the kinds of things that these communities want to do, and ways to improve the infrastructure. It also means we can potentially be a conduit of resources from those communities into open source development workflows. For example, we recently partnered with GESIS to make improvements in Binder and JupyterHub.

So, this post is a brainstorm to identify some of the major considerations that we should take before agreeing to this kind of work. Its goals is to drive policy that streamlines our ability to seek and accept funding for open source work. It tries to answer this question:

How can a stakeholder accept funding on behalf of an open source community in a way that is inclusive, equitable, and effective.

Some assumptions #

First off I want to note that this only applies to open source projects that I’d call “Open communities”. For example, those that follow the principles of open scholarly infrastructure. The ideas here don’t apply to open source projects that are run by single organizations or people. You can assume I’m talking about projects that:

Have inclusive multi-stakeholder governance and operations.
Care about having a broad contributor and leadership base, and want to follow best-practices in inclusive and equitable operations.
Need funding to drive major new efforts, or to sustain pre-existing maintenance and community management work.

Why is this important? In short, because open projects should care about good governance, and about building sustainable and diverse multi-stakeholder communities around their operations and strategy. While it’s easy to ignore these considerations and just bring in money however you can (open source is perpetually under-funded, after all), it’s crucial that we think about how to do so in a way that aligns with the values of open communities, and that doesn’t simply propagate a “rich get richer” dynamic. Ultimately, the unique value of open communities is not in the technology they create, but in the way that they create it.

`tl;dr`: An overview of major considerations #

After working with several open source projects over the years, there are a few issues that I’ve seen come up again and again. Here’s a quick summary and I’ll note each in more detail below.

Governance: funding should follow major decisions, not make them. It should represent the interests of the project rather than those of a single stakeholder or payer.
Transparency: stakeholders that accept funding should be transparent in their accounting (the sources of funding, deliverables attached with it, and operational costs), their plans (the work they plan to do and how they want to do it) and in their strategy (the reason they’re applying for funding in the first place, and how the work fits in with their other operations).
Accountability: stakeholders that accept funding should be accountable to the open communities that they are supporting. There should be mechanisms for open communities to provide feedback about and influence their operations, ideally in a powerful position like a board seat.
Equity: funding should be shared with others in the project, particularly those that need it or that couldn’t get funding on their own. Moreover, people should be paid for their time - if funding requires work from others, they should be compensated somehow.
Inclusion: funding opportunities should be shared with others in a project, particularly those from historically disadvantaged communities. Stakeholders with funding “connections” should use them to boost others in the community as partners, not just as contractors

Here is a more in-depth discussion of each below.

Governance: funding should follow decisions #

As a general rule, funding should not be a decision, it should only be fuel that helps execute a decision that has already been made by the community. Moreover, responsibilities attached to funding should only be given to people with the power to actually carry them out.

The most common mistake that I’ve seen in open communities is when funding creates an unintended decision on behalf of many others.

For example, a new funder shows up with an agenda and offers it to a subset of maintainers. Those maintainers accept, implicitly making a decision to do the bidding of the funder (this could be a grant, a contract, etc). They begin doing the work, and run into resistance from other maintainers who weren’t on-board with these changes in the first place. This creates a stressful situation where one party has legally committed to doing some work, but they may not have the buy-in from others in the community to let it happen. This is particularly problematic when the funding commitment was not advertised publicly to others in the project early on.

Here are a few tips to ensure that funding is aligned with good governance principles:

Make it clear who is allowed to accept money for a project. First and foremost, projects should be explicit about who is allowed to accept money that involves doing open source work for them (e.g., only steering council members can approve new funding). Moreover, they should define basic policies about how that money can be used (e.g. does the project have a cap on the amount that can be paid to individuals).
Tell others about your funding opportunity and get buy-in. If a stakeholder wants to take advantage of a funding opportunity, they should first tell others on the team about the opportunity and what they hope to do. This is the bare minimum - give others an opportunity to object to your plan and/or ask for clarifications or modifications.
Make decisions before funding opportunities arise. If the community has already agreed that something is a good idea, then it is much simpler if funding simply helps implement something rather than propose something new.

Transparency: make it easy for others to see your interests and operations #

Most open projects are community-led, while funding tends to be awarded to one or more stakeholders within that community. At a minimum, communities should ask stakeholders to provide transparency about why they’re looking for funding, what they’re agreeing to do, and how they spend the money.

Transparency is a way of building trust with other stakeholders by being clear about what you’re up to. It makes it easier for others to hold you accountable, and makes it easier for others to understand whether your actions are in line with the goals and values of the community.

Here are a few tips to follow:

Share your budget with the community. Money is always a sensitive subject, but communities have a right to know if funding is being spent towards roles and operations that align with their interests. Some communities may also have policies about how much funding can be awarded to an individual person, and making this clear (even if it is in aggregate) helps others understand what you’re doing with funds.
Declare conflicts of interest. We all have multiple hats when working with an open source project (unless we’re paid full-time by the project itself). Any participating organization has their own mission, strategy, and interests. Some of these may be aligned with a community, and some may be aligned with a funding opportunity. It’s important to declare how these interests align and where they differ, especially as it pertains to power dynamics and how funding is used.
Carry out project planning and execution in public. Dedicated staff have more time than normal to decide and act quickly. If they don’t leave a paper trail for their work, it becomes difficult for those with less time to remain engaged and follow along. Make sure that you make your intentions, and the results of your actions, easily discoverable by those who do not have the same amount of time as you do to engage.

Accountability: allow others to decide if you’ve done a good job #

Accountability is a complement to transparency - you need to show others what you’re up to, and let them tell you if you’re doing a good job. At a minimum this should happen at the level of the specific funding opportunity, but ideally you should give key community members visibility and agency into your organization’s broader strategy.

Ask for feedback about your strategic plan and how this funding fits into it. Tell a community about what you’re up to, and why you think this funding is in both of your interests to receive. Let them know how it fits in with the big picture.
Give strategic oversight to community members that work for a different stakeholder. Give special attention to at least one community member that does not work for the same organization (for example, by creating an advisory board and briefing them on your progress and planning). This will help a more neutral perspective represent the interests of the community and avoid potential conflicts of interest.
Perform an audit of your work and share it with others. Do your best to objectively assess your own progress towards your goals, and whether you believe you’ve represented the community’s interests in working towards them. Other community members may not have the resources to do this on their own, and you should use your dedicated funding to perform this yourself (while understandably declaring a conflict of interest in assessing your own work).

Open communities are a vehicle for building collaborations that span countries, economic situations, and use-cases. They are powerful because of their diverse and multi-stakeholder nature. However, they also exist in a society that is deeply inequitable and that perpetuates centers of wealth and power. This means that most open communities will have a subset of stakeholders with connections and resources that are unavailable to others. To ensure that we follow the principles of open culture, it is crucial that we find ways to push against this inequitable system by sharing resources with one another wherever possible.

Moreover, getting funding often means centralizing the ability to act in a small subset of people. This runs the risk that decision-making (see above) and organizational knowledge become centralized with those individuals. If you’re paid full-time to work on an open source project, there’s a good chance you will personally come to understand the codebase better than anybody else just because you have the time to learn it. This can turn into an anti-pattern where those with access to resources have an unfair power advantage in their perspective over the project.

Finally, running open source projects requires work on both the creating and the receiving end. You can pay somebody to write a bunch of code, but somebody else still has to review it, lead discussions, and ultimately decide to merge.

Here are a few tips to follow:

Share funding with others. If your work is going to require reviews and input from others, find a way to compensate them for their time (if they wish). Prioritize sharing resources with orgs from historically marginalized or disadvantaged communities. When dedicated resources are available, use them for these kinds of groups.
Prioritize documentation and knowledge sharing. It can be attractive to work on shiny new things, but it is crucial that you put in the work to share knowledge with others in a community so that your funding doesn’t become a source of knowledge and power centralization. Document your planning and work, and use that funding to make extra efforts to share your experience with others.
Define practices for making changes that require at least two stakeholders. This helps ensure that those funded to work on open source cannot overpower others in the community just because of their dedicated time. It also encourages healthier collaboration and communication between stakeholders.

Inclusion: bring others along with you #

A differentiating aspect of open communities is the way in which they share power among stakeholders. Funding is inherently tied to power, as it gives you the ability to pay people to do things. Moreover, a stakeholder that controls funding also controls what it is used for. As a result, it’s not enough to simply share funding with others in a project, if that funding comes with strings attached. It is also important to share opportunities for funding with others, and to build coalitions of equals when pursuing new funding.

Collaborators should be given agency over what they want to do with funding. They should be part of grant planning, project planning, etc. They should be seen as co-leads in discussion and announcements. Obviously any funding opportunity will come with obligations, but the important thing is who gets to decide what the team commits to in the first place, and how they plan to accomplish their goals.

Here are a few tips to follow:

Invite others to participate in funding opportunities, especially if they need it. If you identify a funding opportunity, tell others about it. Invite them to collaborate with you on a proposal, or encourage them to write their own proposal.
Treat other stakeholders as partners, not contractors. Treat collaborators as co-equals that have a say in leadership, strategy, and planning. Funding shouldn’t solely come in the form of “strings attached” and contract work. It should center others as collaborators and leads that bring their own ideas to the table.
Find ways to give power to those who historically do not have it. Consider the power dynamics of who applies for funding and actively invite participation from those that need it or that wouldn’t have access to these resources on their own. If you have a personal connection, use it to bring others to the table. If you’re at a well-known organization, use it to boost the profile of others.

How do I actually implement any of this? #

The ideas in this post are principles and goals to strive for. They also touch on very complex subjects, and following them all perfectly is unrealistic given the state of most organizations. The point is not to define a specific roadmap of actions that must be followed, but to note a few major anti-patterns and ways to avoid them. Fundamentally, your goal should be to build trust with a community and to live up to the community’s mission and values. Do what you can, and be honest and open with others in your efforts. A little bit of transparency and effort goes a long way.

As for 2i2c, we hope to use the ideas in this post to define a strategy and set of policies for how to engage with directed funding for open source. We’ll share new ideas in the coming weeks.

Acknowledgements #

This post draws on our practical experience in collaborative funding arrangements, including our partnership with GESIS to make improvements in Binder and JupyterHub infrastructure.

References and more reading #

There are many resources that discuss how to equitably and inclusively seek funding as part of collaborations¹. Here are a few that I found useful in writing this blog post:

And many thanks to several people in the Invest in Open Infrastructure, The Turing Way, the Chan Zuckerberg Initiative, and Code for Science and Society Slacks that helped me brainstorm these ideas. ↩︎

Community | 2i2c

Report from the Jupyter and AI community meetup

Jupyter AI and the Agent Client Protocol #

Notebook CLI #

Sidebar comments and Real-time collaboration #

Opportunities for 2i2c #

Acknowledgements #

BIDS joins the mybinder.org federation with help from 2i2c

Report from the Jupyter Security Working Group security tooling sprint

Acknowledgements #

Jenny Wong joins the JupyterHub team

Learn more #

Acknowledgements #

Announcing our public roadmap for open development

Why we’re opening up our roadmap #

We hope to use a shared roadmap to funnel more resources into open source #

STRUDEL enables rapid scientific GUI prototyping in partnership with 2i2c

What happened #

Why we’re excited about this #

Links to learn more #

Acknowledgements #

April joins the Jupyter Community Building Working Group

Acknowledgements #

2026 Strategy Update: An increased focus on co-creation

The macro view from 2025 #

How member communities see value in our service #

How we’re adjusting the value proposition and operations of membership #

Hypotheses we’d like to test next #

What we’re watching for in 2026 #

Supporting NASA Openscapes Champions with Cloud Infrastructure

2i2c at JupyterCon 2025: Helping communities navigate the Interactive Computing ecosystem

Building computational narratives with Jupyter Book #

JupyterHub’s evolution and sustainable operations #

Understanding the JupyterHub community #

Pythia sharing their MyST journey #

How CryoCloud built a healthy open science community #

Yuvi on scaling maintainer intuition to facilitate PR review with PR triage boards

Acknowledgements #

Debisree Ray on her positive JupyterCon 2025 experience

Acknowledgements #

Community learning: Hub config to pass oauth tokens into user environments

Learn more #

Acknowledgments #

Refactoring Jupyter Book 2 documentation ahead of a major release

What we did #

Why we’re excited about it #

Learn more #

Acknowledgements #

2i2c Supports the Science Platforms Coordination IHDEA Working Group

Why we’re excited about this #

Learn more #

Acknowledgements #

BIDS joins as 2i2c's first premier member organization

What this partnership means #

Why we’re excited about this #

Learn more #

Acknowledgements #

Communities learning from one another - Project Pythia and ICESat-2 Hackweeks

Learn more about these communities #

TIL: A few ways to track web traffic for open source projects

Three analytics tools we found helpful #

Learn more #

Acknowledgements #

Celebrating BIDS as 2i2c's first premier member at UC Berkeley

Learn more #

Acknowledgements #

Openscapes is hiring a new team member

Learn more #

Acknowledgements #

2i2c's submissions to JupyterCon 2025

JupyterHub: A multi-user server for Jupyter notebooks #

Cloudy with a Chance of Savings: Per-User Usage and Cost Monitoring for JupyterHubs in the Cloud #

Controlling home directory costs (with user empathy) on the cloud with jupyterhub-home-nfs #

Rebuilding user trust in mybinder.org #

Can your JupyterHub handle your workload? Performance testing with jupyterhub-simulator #

Not just for notebooks: JupyterHub in 2025 #

Introducing Jupyter Book 2.0 #

You don’t need to contribute more to open source, you need to go to therapy #

What 2i2c has learned while trying to build sustainable relationships with Jupyter’s community. #

Solving classes of problems, rather than just an instance of a problem (with an example)

Rebuilding user trust in `mybinder.org` #

Can your JupyterHub handle your workload? Performance testing with `jupyterhub-simulator` #

`tl;dr`: An overview of major considerations #