2i2c

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.

Introducing Jupyter Book 2 at FOSDEM 2026

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

Our teammate Angus Hollands gave a talk at FOSDEM 2026: Introducing Jupyter Book 2.

The talk shares why the Jupyter Book 2 and MyST stack was rebuilt, and how it supports open, reusable computational publishing workflows.

Slide from the FOSDEM 2026 session introducing Jupyter Book 2.

Learn more #

Acknowledgements #

Thanks to Project Pythia and to BIDS for supporting deeper foundational contributions like this in Jupyter Book.
Thanks to the Jupyter Book team for helping out with slide creation and doing all the work Angus spoke about here!

Better sharing UX with nbgitpuller and contextual error handling

Thu, 05 Feb 2026 00:00:00 +0000

TL;DR #

nbgitpuller now has improved UX context-aware error handling. Try out the pre-release version 1.3.0b1 and let us know what you think by opening an issue or via the feedback form below 🚀

What is nbgitpuller? #

nbgitpuller is a way to sync content with compute through the click of a link. Example use cases include:

Interactive research demos, such as Spyglass (HHMI)
Workshops and training scenarios
University exams

In the case of Spyglass, the content is LorenFrankLab/spyglass-demo hosted on GitHub, the compute is a 2i2c cloud hub hosted at spyglass.hhmi.2i2c.cloud, and by using the handy nbgitpuller link generator, you can generate this nbgitpuller link to share with others to seamlessly explore content on the desired compute platform with the relevant data and toolchains installed.

How does nbgitpuller work? #

nbgitpuller is installed in the compute environment. The compute environment now has an /git-pull endpoint URL that can understand where to pull content from using URL parameters. Syncing content critically depends on git operations to fetch, checkout, clone, merge, commit, etc.

When it goes wrong #

Based on the data sent through by the kind folks running the Berkeley DataHub, there were 2163 logs available, of which:

983 (45%) were ‘merge’ conflicts
493 (23%) were ‘fetch’ errors
467 (22%) were ‘ls-remote’ errors

The remaining errors (10%) were mostly ‘checkout’ errors. This represents most frequent errors as seen by students.

In the same set of logs, there were 172 unique errors: most ‘ls-remote’ errors come from mistakes in the content repo URL. This represents most uniquely common errors made by instructors.

Merge conflicts #

If the link author changes content after the link consumer clicked a link, then nbgitpuller needs to sync updates for the consumer on subsequent link clicks. The nbgitpuller merging strategy makes opinionated choices so that the link consumer never has to interact with git, and will always preserve the consumer’s working changes.

Things can go wrong when

Consumers can diverge the git history if they perform a git commit
Authors can diverge the git history if they perform force push commits

Error UX (old) #

Problems with the old UX include:

a scary terminal
difficulty for the user to figure out what went wrong
no suggestion for the user to fix the problem or signpost to continue to the compute platform

Error UX (new) #

New improvements to the UX include:

terminal closed by default, but you can optionally toggle this open
there is a copy to clipboard button to easily share the error log from the terminal
more user-friendly and context aware helper message is displayed
a link to the general documentation for reference
a ‘Proceed without syncing’ button take the user to the compute platform without making any changes
in the case of merge errors an extra Backup and resync button option is presented

Give us feedback! Click here to provide feedback that will help us make this more impactful.

Learn more #

Acknowledgements #

UC Berkeley and the CloudBank Classroom project
CAL ICOR for co-funding
Eric Van Dusen and Sean Morris for championing this work
Balaji Alwar for providing the data and sharing feedback
Nicolas M. Thiéry for feedback on the UX design

New Jupyter Book / MyST stack release (Jan 2026)

Thu, 29 Jan 2026 00:00:00 +0000

The MyST/Jupyter Book stack shipped new releases this week. Release pages:

Where we contributed #

We’ve spent extra time lately trying to fix bugs and generally improve stability, reliability, and UX papercuts. Here are some of the things we focused on:

Extra review time to get in concurrent executions in mystmd
Fixing broken edit URL logic so our community “edit buttons” worked again
Standardized link styles so users know what to expect from links
Added extra hover metadata for github issues and PRs for communities that often link to their GitHub issues
Made all of these releases and wrote up the release notes!

Most of our contributions were foundational in nature - we fixed a bunch of bugs, did review on the PRs of others, and managed the release process itself. Check out the changelogs for more details!

Acknowledgements #

Thanks to our member communities - their memberships cover the cost of foundational upstream contributions to projects like these.

Particular thanks to Project Pythia which currently supports much of our upstream contributions in Jupyter Book.

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

Enabling CloudBank to safely manage their own cluster infrastructure

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

We recently enabled CloudBank to run Terraform changes for their cluster without needing to wait on 2i2c engineers for each request. They run 50+ hubs for various community colleges, and we want to enable them to self serve as much of that as possible. When we introduced home directory quotas, they were no longer able to set up hubs by themselves without help from 2i2c engineers. Our goal was to empower them to be able to set up new hubs in a safe way while still benefiting from the home directory limits work.

CloudBank simplifies cloud access for computer science research and education.

To do this safely, we needed to avoid granting access to shared Terraform state that could impact other communities. Following Yuvi’s suggestion, we migrated CloudBank’s Terraform state to CloudBank’s own GCP project so that infrastructure changes from the CloudBank team are isolated to their cluster only, making this safe to try. This unblocks CloudBank to run changes like terraform plan and terraform apply themselves, meaning that CloudBank can deploy and update a hub without 2i2c engineers in the loop.

This is a good example of how we aim to balance community autonomy with infrastructure safety. CloudBank can now self-serve routine operations while our broader infrastructure remains protected.

Learn more #

Acknowledgements #

Thanks to Sean Morris and the CloudBank team at UC Berkeley for collaborating on this workflow.

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.

Improving our community hub reliability and stability in Q4 2025

Tue, 16 Dec 2025 00:00:00 +0000

This year we’ve prioritized making the cloud safe to try for our member communities. This has driven work in monitoring, alerting, and automating infrastructure so that we resolve small problems before they become big problems. In the last quarter of 2025, we wrapped up this effort by testing the following hypothesis:

We can reduce P1 incidents if we shorten the time to act on current alerts and learnings from prior incidents.

Here’s what we accomplished and what we learned.

What we accomplished #

In short: we’re now much more confident in the stability of community infrastructure. Here’s a snapshot of our new incident dashboard, which shows high-level trends for the stability of our infrastructure:

See the real-time status of our community hubs at status.2i2c.org

We improved infrastructure reliability for our communities #

We made several technology and team process improvements that led to these benefits for our communities:

We are now more likely to catch outages before a community reports them to us.
We are now less likely to have an outage happen more than once, or affect more than one community, because we consistently fix the issues that cause outages.

We saw a consistent drop in critical alerts that required immediate response:

For August and September we had an average of 7 outages/month (6 from alerts, 1 from community)
In October, November, and December we had an average of 3 outages/month (9 in October, 0 in November, 1 in December, with only one of these being reported by a community)

We became more efficient, responsive, and focused #

We also got several team benefits from this work:

We get fewer interruptions and distractions from deeper work.
We have clear assignment policies to make it clear who is responsible for acting in response to alerts.
We avoid invisible work from falling down rabbit-holes when responding to outages.
We decreased the stress and pressure of doing upgrades, making them easier to split into sprint items and more likely to get done consistently.

The improvements we made #

Infrastructure improvements #

Created a status page for all 2i2c community hubs, giving our team and communities visibility into the status of our infrastructure.
Created an alert that triggers when two servers fail to start consecutively in a 30-minute time window.
Improved deployment infrastructure so that we can roll out sub-chart upgrades to individual clusters, allowing us to roll out major changes in batches.
Removed our “configurator” application from community hubs, because it was causing more confusion than it was resolving.
Allowed servers to start even when users hit their storage quotas.
Provided a number of upgrades to Kubernetes and the support services that we run alongside each community hub.

Process improvements #

Made a team commitment to prioritize issues from incident reports and other stability-related problems.
Defined incident escalation policies using the status page to calibrate the urgency of our response to the severity of incidents.
Defined “on-call” procedures so our team knows when and how to be more responsive to outages.
Time-boxed our alert response process to avoid accidentally falling down rabbit holes for non-urgent problems.
Created a more reliable process for responding to incidents and writing incident reports.

Looking forward #

After this push around infrastructure reliability, we’re significantly more confident in the stability and transparency of our community hub infrastructure. This will deliver better service for our member communities and free up more of our time to engage with them instead of fighting infrastructure fires.

We will continue to improve our infrastructure, and have a better foundation to do so incrementally in the coming quarters. Here are a few things we’d still like to improve:

We still need to improve how reliably we complete follow-up actions from incidents (e.g., writing incident reports). When a process doesn’t fit into planning & scoping ceremonies, we struggle to follow it consistently.
We’d like to improve our testing framework for major upgrades across all hubs (e.g., Kubernetes version upgrades) to catch bugs before communities do.

Learn More #

Faster reporting of user home directory sizes

Tue, 09 Dec 2025 00:00:00 +0000

Storage quotas help users avoid running out of space unexpectedly and give administrators visibility into capacity planning. However, storage usage can change rapidly, and it’s important to have quick information so that administrators know whether they are close to hitting limits.

We’ve improved how quickly hub administrators can see user home directory sizes across our JupyterHubs. This makes monitoring more responsive and adds quota limit visibility that wasn’t possible before.

Using `jupyterhub-home-nfs` for near-instant disk usage metrics #

Our existing storage monitoring tool, prometheus-dirsize-exporter, deliberately runs slowly to avoid excessive disk I/O. This meant home directory metrics could be hours out of date on systems with many users or large directories. Plus, there was no way to report user quota limits at all.

Our home directory storage is managed by jupyterhub-home-nfs, which enforces per-user quotas. It could also expose usage and limit information as Prometheus metrics using data from the underlying filesystem quota system. Because this information is already tracked by the filesystem, it’s available immediately without scanning individual files.

We made two key improvements:

Make disk usage reporting almost instantaneous. We made jupyterhub-home-nfs export total_size_bytes and hard_limit_bytes metrics to Prometheus for near-instant reporting. We used the same metric names and namespace as prometheus-dirsize-exporter for compatibility. See 2i2c-org/jupyterhub-home-nfs#76
Allow this to be used upstream in JupyterHub Grafana Dashboards so that it can support both types of disk usage reporting. This means users of the upstream JupyterHub Grafana dashboards get the same useful view about home directory usage, regardless of whether the metric comes from prometheus-dirsize-exporter or jupyterhub-home-nfs. See 2i2c-org/prometheus-dirsize-exporter#29

These changes were deployed across all our communities, so administrators can now access current home directory information within minutes regardless of directory size.

Home Directory Usage dashboard showing total size metrics from jupyterhub-home-nfs and other data from prometheus-dirsize-exporter

Try it out #

2i2c member organizations can try this out now. If you have access to your hub’s Grafana instance, you can see these new metrics in the Home Directory Usage dashboard:

Open your hub’s Grafana dashboard.
Go to Dashboards -> JupyterHub Default Dashboards -> Home Directory Usage.
Check the table for up-to-date total size and quota limit values.

For more details, see our docs on filesystem and disk dashboards.

Coming next #

We’d like to build on this work to enable alerting when individual users near their disk quotas. This will make it easier to more reliably track user disk usage across a community. See this issue for tracking: 2i2c-org/infrastructure#7166

Acknowledgements #

This was a directed contribution supported by NASA VEDA to enable more proactive monitoring and alerting for hub administrators.

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.

Adding User Group Insights to Cloud Cost Dashboards with Grafana

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

We are excited to announce that we have extended our cloud cost dashboards to support display costs filtered by user groups using Grafana! This new feature allows administrators to monitor and manage cloud expenses based on user group memberships in JupyterHub.

Available for dedicated AWS clusters only (and excluding CloudBank managed accounts). Other deployments on GCP will be supported in the future.

Learn more #

Take a look at the Community Hub Guide to see what’s new
Check out the documentation of the 2i2c-org/jupyterhub-cost-monitoring project to see how it all works
Jenny recently presented her work on the cost monitoring system at JupyterCon 2025 earlier this month. Watch a video or look at the slides.

Give us feedback! Click here to provide feedback that will help us make this more impactful.

Acknowledgements #

Tarashish @ Development Seed for collaborating on this project with us.
NASA VEDA and the DSE Team at NASA MSFC ODSI for funding much of this work.
Kyle Lesinger from the NASA MSFC Office of Data Science and Informatics for providing valuable feedback and bug reports during development.

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.

Creating a re-usable redirect generator for Jupyter Book 1 migrations

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

When migrating documentation from Jupyter Book 1 to Jupyter Book 2, URL structures change dramatically and break external links. We spent some time createing a re-usable tool to solve this problem across multiple projects.

You can check out the tool below:

jupyter-book/jb1-redirect-generator

It’s designed to be run in a self-contained way by putting the dependencies in script metadata at the top. This means you can run it like this:

uv run https://raw.githubusercontent.com/jupyter-book/jb1-redirect-generator/main/generate_redirects.py

This let’s you generate redirects from JB1 -> JB2 URL structures and dump them in a _build/html folder with your JB2 built pages.

We tested this out by converting the Jupyter Governance docs to Jupyter Book 2 and running it there. You can find a noxfile that runs these commands here:

jupyter/governance/blob/bcdae30efdecbe75bc4751ef1fe1e602fe82ee10/noxfile.py#L25-L37

And its use in a GitHub Workflow here:

jupyter/governance/blob/bcdae30efdecbe75bc4751ef1fe1e602fe82ee10/.github/workflows/deploy.yml#L39-L44

Learn more #

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, 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

NASA Openscapes mentors run airborne data machine learning workshop with 401 participants from 68 countries

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

NASA Openscapes mentors recently hosted a workshop attended by 401 participants from 68 countries to learn how to use airborne data and machine learning for environmental research!

They gave participants computational environments on a community hub managed by 2i2c to teach skills in data science like image classification with airborne spectroscopy and accessing data from NASA JPL AVIRIS-NG data from Earthdata cloud.

We’re proud to enable participants from all over the world to easily access standardized compute and NASA Earthdata data in the cloud for a seamless learning experience.

Learn more #

Acknowledgements #

Thank you to the Openscapes team for sharing this post with us, and
- Michele Thornton
- Rupesh Shrestha
for authoring the blog post.
NASA Openscapes mentors for running a great workshop

A thank you to CZI for its impact on 2i2c and Jupyter

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

As I attend the CZI Open Science 2025 meeting, it’s a good moment to reflect on the many ways CZI has positively impacted both 2i2c and the Jupyter Project.

The funders who support organizations like 2i2c and Jupyter have a difficult task. In the day-to-day work of building open infrastructure, it’s easy to focus on the next challenge or grant, and lose sight of the cumulative, long-term impact of strategic support. This post is an attempt to pause and celebrate that impact.

CZI has played a unique role in the open source and open science ecosystem since its creation. It has taken an approach to funding and coalition-building that has genuinely changed how many think about supporting open source. Their model has driven an incredible amount of impact, and I’m very grateful for our collaboration.

Here are a few ways their support has stood out.

This was collected quickly, so please let us know of other ways we may have missed! And most importantly, we’re only trying to gather a high level view here, so we’re including many efforts where all the work was led by teams and organizations other than 2i2c/Jupyter. The Jupyter Community has many leaders that are part of this effort as well.

Strengthening the foundations of Jupyter #

Through its Essential Open Source Software for Science (EOSS) program, CZI has funded several initiatives in the Jupyter ecosystem that have strengthened the project in foundational ways. Here are a few that stand out:

JupyterHub’s Contributor in Residence: Allowed JupyterHub to explore a new maintenance and community support model and support maintainer growth. Georgiana’s journey from this program to becoming 2i2c’s first engineer shows how CZI’s investment in people creates lasting impact.

Community Strategic Lead: Focused on diversity, equity, and inclusion at a strategic level. This created space for us to rethink how we build our teams to be more accessible and equitable. It helped us create pathways for underrepresented groups to become community leaders and led to a key partnership with The Turing Way.

Real-Time Collaboration: Built the foundation for collaborative notebook editing, which is very useful for remote scientific collaboration. This was complex technical work that involved collaboration with many stakeholders. It laid a foundation that Jupyter continues to build upon, and may facilitate AI-based workflows in unexpected ways.

Jupyter Accessibility: Funded key improvements in accessibility for JupyterLab and the broader Jupyter stack, including WCAG compliance, automated testing, and documentation. This was one of the first times an open source community received significant support for accessibility and internationalization, highlighting CZI’s leadership.

They also enabled a wide variety of contributions throughout the Jupyter ecosystem that can be traced back to the capacity that CZI’s funding provided for core support alongside broader initiatives.

Enabling 2i2c to grow from an idea to an organization #

CZI also played a key role in 2i2c’s birth, growth, direction, and impact. When 2i2c was only an idea, the possibily of initial support from CZI was pivotal in helping us turn it into a reality. Then as the organization took shape and started to grow, this support gave us the strategic capacity to develop key frameworks for healthy open source contribution practices, our value propositions, and ideas around community network funding. It was a stepping stone towards building out our own sustainability model via membership.

Here are a few milestone moments:

Our Seed funding (2020) CZI provided core support to bootstrap 2i2c from its inception, funding organizational capacity rather than just technical deliverables. This was critical, enabling strategic partnerships, community coordination, and 2i2c’s first hires (Georgiana Dolocan, formerly the CZI-funded JupyterHub Contributor in Residence, and Chris Holdgraf, 2i2c’s Executive Director). This was the primary funding that drove our creation and operations for the first three years. We published a comprehensive report and retrospective documenting the impact of this seed funding.

Catalyzing Global Communities (2022) This collaborative grant brought together six organizations (2i2c, The Carpentries, CSCCE, IOI, MetaDocencia, Open Life Science) to provide cloud infrastructure and training for communities in Latin America and Africa. The project emphasized “train the trainers” approaches and community co-leadership. It was a much bigger challenge than we all realized, and the relationships between our organizations grew stronger as a result.

Strategic Support for Sustainability (2024) CZI provided a bridge funding gift to sustain 2i2c’s mission during a critical growth phase. This gave us the runway to refine our service model and explore paths to financial sustainability. Combined with funding from The Navigation Fund, this gave 2i2c approximately two years for strategic planning.

What Makes CZI’s Approach Different? #

Here are a few things that have stood out to me about CZI’s unique approach to funding:

Funding the foundation of open infrastructure: Through its EOSS program, CZI recognized that science was building on open source infrastructure that was often under-supported. Explicitly targeting that foundation demonstrated the need to fund core technology, not just new innovation.

Funding communities, not just code: CZI made efforts to support projects that invested in social infrastructure, recognizing that building open source is a deeply social process that needs social skills and capacity to succeed.

Funding connections in a network: CZI took a network approach, actively building connections between its grantees. It flew us together annually for its open science meeting, made targeted efforts for collaborative grants, and connected grantees to work together.

Actively growing that network: CZI made clear efforts to bring in new participants, particularly from communities in Latin America and Africa, and was thoughtful about respecting the agency and leadership of these communities.

Developing its own expertise and understanding: CZI also builds its own tooling, often in partnership with open source projects. This gives its team empathy for our challenges and a deeper institutional understanding of the open source world, leading to more impactful contributions.

Thank You, CZI #

We’re profoundly grateful to CZI for their support for 2i2c, Jupyter, and the broader open source ecosystem. Their investments have enabled Jupyter to serve millions of scientists more effectively, allowed 2i2c to grow from an idea to the organization it is today, and enabled contributions that benefit the entire open science ecosystem.

Thanks, CZI, for all the work you’ve done!

A helpful contribution to our JupyterHub SSH README from OpenScapes

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

We love when collaborators contribute back to the tools we maintain! Andy Teucher from OpenScapes recently fixed a documentation issue in jupyter-sshd-proxy that benefits everyone using the tool.

jupyter-sshd-proxy is a tool originally created by Yuvi to help 2i2c communities connect to their JupyterHub instances via SSH. Andy ran into an issue when using it with the VS Code fork that uses the open-remote-ssh extension - it failed unless double quotes were used around the authorization token in the ProxyCommand.

Through experimentation, Andy figured out the fix and contributed it back to the README. Now everyone using this tool will have clearer documentation.

While small, we think this is a nice example of a “Foundational contributions” from a community:

2i2c creates and maintains open source tools to help our communities
Our communities use those tools and run into issues
They debug, figure out solutions, and contribute improvements back
Everyone benefits from the improvements

This is exactly how we want 2i2c to help our communities - by making it easy for them to contribute back to the ecosystem and strengthen the tools everyone relies on.

Acknowledgements #

Thanks to Andy Teucher for the contribution and debugging!
Thanks to OpenScapes for being great collaborators places where can work with people like Andy

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.

Fixing the mybinder.org usage analytics archive

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

The analytics archive at archive.analytics.mybinder.org powers the mybinder.org usage dashboards and provides a daily-published dataset that researchers and communities use to understand how Binder is being used across different domains and scientific communities.

While updating our quarterly Binder impact report, we discovered the archive index page had stopped updating. The analytics publisher was writing index files to temporary storage before uploading to Google Cloud Storage, but for some reason the upload step stopped working. We deployed a fix that eliminates the temporary files entirely - the code now generates the HTML index as a string in memory and uploads directly.

The mybinder.org analytics archive shows a list of daily usage reports that anybody can download.

Fortunately, we didn’t lose any data! Thanks to some smart design decisions, the daily analytics files were being collected properly the entire time, only the index page listing them was broken. You can find the full archive here.

Learn more #

Pull request with the fix
mybinder.org usage dashboards
The binder-data/ repository is where we aggregate and publish archive data to be more accessible.
Our quarterly impact report from mybinder.org

Acknowledgements #

Thanks to the JupyterHub community for their collaboration on mybinder.org infrastructure

Impact report from 2i2c's Binder federation instance

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

The mybinder.org service provides reproducible and interactive computational environments for the open science community. It is financially supported by a federation of BinderHubs. 2i2c is part of the team that manages mybinder.org, and we’re committed to supporting this critical infrastructure for open science and reproducibility.

We developed a more cost-efficient process for deploying BinderHub on a single VM and are now running a BinderHub at 2i2c.mybinder.org. This post highlights the impact we’ve had through our support of the mybinder.org federation, we’ll update it periodically.

Usage over time #

Here are weekly launches on mybinder.org. Launches from 2i2c.mybinder.org are in red. Source: mybinder analytics dashboard.

In Q1 of 2025, 2i2c.mybinder.org launched 417,048 reproducible sessions. In this time, mybinder.org was primarily driven by our new Hetzner node as we worked with GESIS to stabilize their own BinderHub instance.

In Q2 of 2025, 2i2c.mybinder.org launched 249,750 reproducible sessions. In this time, we worked with GESIS to deploy their BinderHub instance on the same Hetzner node setup, which let us distribute more of Binder’s load onto them.

In Q3 of 2025, 2i2c.mybinder.org launched 118,083 reproducible sessions. We experienced a typical summer dip in sessions, had to fix the analytics dashboard as well as fix a TCP scanning abuse case that briefly brought down the 2i2c node.

Where we’ve made improvements #

As part of this effort, we’ve made several improvements to the Binder and JupyterHub ecosystem. Here are a few links where you can read more:

Deploying BinderHub on a single VM with k3s - Our approach to making BinderHub deployment cheaper and simpler
Hetzner cloud infrastructure experience - Cost-effective cloud hosting for mybinder.org
Combating TCP scanning abuse on mybinder.org - Developing anti-abuse tools to prevent an abuse use-case.
Improving Binder’s usage dashboard - This helps us create posts like these and is useful to others as well.
Integrating BinderHub with JupyterHub - Working with GESIS to bring Binder’s dynamic image building capabilities to persistent JupyterHubs, empowering users to manage their own environments

Acknowledgements #

This work is made possible by:

GESIS for their continued support as mybinder.org federation members
The JupyterHub community for collaboration and support
Our member communities whose fees support this work

Combating tcp scanning on mybinder.org with the tcpflowkiller

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

We’ve deployed a new tool to mybinder.org that automatically detects and stops port scanning activity, helping us maintain service reliability while being responsible citizens of the internet.

Port scanning is a common part of network-based exploits, and many server hosts prohibit this activity (including Hetzner, where the 2i2c mybinder.org infrastructure lives). We developed a little tool called tcpflowkiller as part of the cryptnono project (our anti-abuse set of tools for hosted JupyterHub and Binder infrastructure) to automatically kill processes that exhibit port scanning behavior. This reduces the likelihood of triggering our server host’s abuse policies and helps keep mybinder.org running reliably.

Why this matters #

As providers of public compute, it’s our responsibility to make sure people can’t use our infrastructure to abuse others. This is part of being responsible citizens of the internet. It also saves us time in dealing with outages because cloud providers (understandably) block access when they suspect there is abuse.

Hetzner and similar hosts have many benefits (including significant cost savings), and tools like tcpflowkiller help keep hubs and binders running smoothly on such hosts, which have different abuse policies than the big commercial cloud providers.

AWS and other cloud providers have proprietary ways to combat abuse (like AWS GuardDuty). We could have spent our time investing in developing rules there. Instead, contributing to cryptnono helps provide the same set of features in a cloud-agnostic way, in line with our principles of supporting open infrastructure that gives communities control over their infrastructure.

This tool has now been deployed to mybinder.org, and we’ll monitor its effectiveness over time. We may roll this out to 2i2c public BinderHubs in the future based on patterns we observe.

Learn more #

Acknowledgements #

Thanks to GESIS for their continued support of mybinder.org and to Raniere Silva for collaborating on this deployment with us.

TIL: GitHub Action secrets are only available from non-forked repositories

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

If you’ve worked with GitHub Actions in open source projects, you might encounter a hard-to-debug error where repository secrets are simply empty. That’s probably because the PR is from a forked repository! Here’s a little learning we had after losing a bunch of time figuring this out:

Our PR from a fork was using empty strings for repository secrets #

github-activity is a tool we help maintain for generating changelogs from a wider variety of contributions than GitHub’s defaults. We needed to set a secret to raise the API rate limits for the tool’s tests. These tests pull data from repositories outside of the github-activity repository itself, which quickly hit GitHub’s rate limits without authentication.

The problem seemed straightforward at first: we added the secret, but the workflow was acting as if the secret didn’t exist at all. After updating the code to explicitly check for empty strings, we discovered the authentication token was actually an empty string, even though it had been set.

After some debugging, we uncovered the root cause: the PR was opened from a fork of github-activity. GitHub intentionally makes secrets appear as empty strings when a PR originates from a forked repository. This is a security measure to prevent unauthorized access to sensitive credentials.

A quick fix: re-open the PR from the base repository #

The immediate fix was simple: re-open the PR from a branch in the base repository rather than from the fork. This worked perfectly, but it’s not a sustainable solution for open source projects that rely on community contributions from forks. We don’t want to create a dynamic where maintainers have different PR workflows because they’re operating on the base repository.

How use secrets with forked repositories in a safe-ish way #

If you need to make secrets available to PRs from forks, there are a few approaches we learned about, each with security trade-offs:

The `pull_request_target` workflow #

GitHub provides a pull_request_target workflow that can access secrets even when triggered by forked PRs. In this case, GitHub will always run the test suite on main, instead of any changes your PR introduces.

Why this is dangerous: malicious actors could add code to a PR that exfiltrates your secrets (for example, Python code that prints os.environ["MY_SECRET"]).

As a result, only use secrets that you’re OK with being public. In this case, we generated a read-only token with restricted permissions. However, this is still kinda risky so use at your own peril.

If your repository workflows require a secret that absolutely cannot be public (e.g., a publishing key for a package repository), try a method like the following:

Using GitHub Environments for granular control #

A safer approach is to use GitHub Environments, which let you restrict which secrets are available to specific jobs. This way, you can ensure that only non-critical secrets (like those needed for testing) are available to jobs that run on forked PRs, while keeping sensitive secrets (like PyPI publishing tokens) restricted to trusted contexts.

This is the approach we implemented in github-activity, and it provides a good balance between security and community contribution workflows. We created a separate environment for publishing to PyPI so that its secret is never available to the job that runs with pull_request_target.

We hope this saves you time! #

Hopefully this learning is useful to others who run into the same confusing behavior. We’ve added a few improvements to github-activity to more reliably check for empty strings to surface this kind of condition, but knowing the basic behavior of GitHub environments and forked PRs is even better.

Learn more #

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

Enabling transparent cloud cost monitoring with user-level dashboards

Tue, 30 Sep 2025 00:00:00 +0000

We are excited to announce that dashboards to monitor cloud usage and costs at a per-user level are now available! See the cost monitoring documentation for more information.

A key goal of 2i2c is to make the cloud safe for science. By providing transparent cost monitoring, we give communities the confidence that they won’t face unexpected bills and can better understand how their usage patterns translate to cloud costs. This visibility is especially valuable in our shared platform model, where each community gets their own independent hub while benefiting from shared infrastructure expertise.

The user-level cost breakdown allows communities to identify individual usage trends and manage their resources more effectively. Communities can now see exactly how their computational work translates to cloud spending, enabling better resource planning and budget management.

Give us feedback! Click here to provide feedback that will help us make this more impactful.

Learn more #

Cost monitoring documentation

Acknowledgements #

Tarashish @ Development Seed for working on this with us.
NASA VEDA for funding much of this work.
Andy @ Openscapes, Alex @ Development Seed and Sarah @ Earthscope for giving us close feedback.

From scattered effort to strategic impact: How we're systematizing our Foundational open source contributions

Fri, 26 Sep 2025 00:00:00 +0000

Over the past year we’ve experimented with being more strategic about supporting upstream communities as a team. This post summarizes our current plan, including team targets and practices we’ll continue to pilot. We’ll revisit this as we learn more.

Note: This document is about the Foundational contributions we make so that open source communities are healthier and more impactful. It is not about Directed upstream contributions we make as part of our own product work. See On being a good open source citizen: supporting a healthy ecosystem through directed and foundational contributions.

The challenge: Why scattered individual efforts aren’t enough #

Healthy open source communities rely on both individual and institutional contributions. 2i2c aims to be an excellent “upstream citizen”, so we need a structured approach with clear goals and rationale for why it’s the best use of our team’s time.

Without a coordinated approach, we risk two problematic outcomes:

Best case: Scattered, individual efforts that are subject to the Tyranny of Structurelessness. We help at the margins but not meaningfully.

Worst case: Our organizational capacity inadvertently dominates communities, making 2i2c the sole stakeholder capable of meaningful development and maintenance. We functionally take over the project.

By setting explicit goals, both our member communities and upstream projects can hold us accountable for actions that strengthen rather than undermine community health.

Our long-term goal: Multi-stakeholder, resilient communities #

With this in mind, we’ve chosen the following outcomes as our major goals for upstream contribution:

We want the Jupyter¹ community to be a multi-stakeholder², diverse³ community with a very high bus factor, because we believe this is a critical pre-requisite for advancing our mission and value proposition.

We want to build team processes that help upstream communities make progress towards this goal, so everyone can equitably participate with the support they need.

Two key objectives #

Starting with JupyterHub, we’ve identified two objectives that will guide our work:

Objective 1: Increase the number of casual but returning contributors to the JupyterHub community

Objective 2: Increase the number of total maintainers in the JupyterHub community

We’ve chosen these objectives because (1) they have impact, (2) we can make meaningful progress on them, and (3) we can integrate this work into our team’s workflow.

For each activity below, we’ve brainstormed some Key Performance Indicators (KPIs) to track progress and ensure we’re learning effectively.

Four pilot activities #

We’ll experiment with these four activities⁴:

Review pull requests from non-maintainers
Issue Triage office hours
Sponsoring and Mentoring new Maintainers
Increase bus factor and diversity of people making releases

Review Pull Requests from non-maintainers #

Imagine two different scenarios:

You casually contribute a PR to some OSS project. Someone responds the next day, you have a pleasant back and forth, and it gets merged (or rejected) within a few days.
You casually contribute a PR to some OSS project. Nobody responds for a year. Eventually someone leaves a comment. You have forgotten everything, and don’t even respond. Much later, your PR gets closed as stale.

Which experience will encourage you to come back and contribute again?

It’s clearly (1). We should use our institutional capacity to bring the community closer to (1).

We’ll accomplish this by including the following work item in every sprint:

Review of N PRs by non-maintainers of JupyterHub

We will build skills (via pairing, training, etc) inside 2i2c, as not everyone will feel comfortable reviewing pull requests for all projects, nor have rights to merge or close PRs. We may also do additional work like new contributor drives, better documentation, and policy advocacy. We will include pull requests of all types, not just code contributions.

KPIs #

We imagine two KPIs for this activity:

Number of PRs merged (or closed) through our sprint planning activity.
Number of returning contributors whose PRs were reviewed by us.

Issue Triage office hours #

Issue Triage involves combing through an upstream repository’s issue tracker, engaging with new issues, refining them to be actionable, and signal boosting important ones for team action. This is hard for newcomers, as it often requires deep knowledge of various components to understand how to direct an issue or refine it. It’s also challenging for team members still learning open source community dynamics. We’d like to upskill our team members within 2i2c and our upstream open source communities.

As part of our sprints, we will run regular “Issue Triage” office hours. We’ll begin by upskilling our own 2i2c team members in effective issue triaging. We’ll then explore opening issue triage sessions to the broader upstream community.

KPIs #

Number of issues triaged by 2i2c team members.⁵

Sponsoring and Mentoring new Maintainers #

OSS communities must grow their contributors into maintainers, or they will die.

XKCD comic about dependency

Growing new maintainers takes time and effort from both the potential maintainer and existing maintainers who mentor and sponsor them. The focus on sponsorship is important, as laid out by Lara Hogan. This work takes years, not months, to manifest.

We will build structures to identify potential maintainers and create pathways for them to gain maintainership status. As JupyterHub lacks an explicit maintainer pathway, we will build our own process via these focus areas:

Identifying potential candidates for maintainership
Identifying potential community work they can do to help get involved (contributing bug fixes, code reviewing, issue triage, helping answer questions, contributing code / documentation, release management, etc)
Build pathways for candidates to do (2) as appropriate.
Iteratively continue until candidates have done ’enough’ work to gain maintainership status.

This work is nebulous but worthwhile. We will coordinate this effort closely with community leaders, recognizing it takes time to actualize.

In the Jupyter community, maintainership status is tied to individuals, not to organizations they work for. Nobody should get maintainership status simply because they work for a specific organization (such as 2i2c). We should look for diverse candidates, ideally funded by different organizations, who are interested in becoming maintainers.

Note: We’d also like to start with individuals in our collaborator network. For example, we’re using an engagement between NASA VEDA and Development Seed to onboard several team members into these projects.

KPI #

This measurement moves slowly, but is very clearly impactful:

Number of people who have become maintainers due to our concerted efforts.

Increase bus factor and diversity of people making releases #

Making releases is often thankless but important to community health. It involves coordinating testing, writing changelogs, and providing upgrade instructions. Institutions can help by dedicating team time to perform this task regularly. To advance the ‘multi-stakeholder’ and ‘high bus factor’ aspects of our goal, we will have many different people do releases, via mentorship and sponsorship. This will integrate into our regular workstreams.

KPIs #

Number of releases performed by 2i2c engineers
Number of releases performed by others with sponsorship / mentorship from 2i2c engineers

Criteria for upstream projects to support #

Our long-term goal applies to upstream communities that:

We strategically depend on to serve our member communities as part of our community hub service
We need to help sustain, given upstream community dynamics
We have the ability to help sustain

For example, Kubernetes satisfies (1) but not (2) or (3), while JupyterLab meets (1) and (2) but not (3) (presently). Currently this policy only applies to JupyterHub, but may change as our organization evolves.

How we’ll implement this #

Who is responsible #

Implementation is the responsibility of 2i2c’s Product & Services team. These activities must integrate into the team’s daily practices, not become an external shadow process for some members.

How we’ll fund this work #

Foundational upstream support requires significant work and expertise. We plan to fund this through:

Fees from our member communities. A percentage of our membership fees includes covering the cost of Foundational contributions like this.
Targeted contributions from some of our collaborators. Some collaborators have funds and want to support open source at a foundational level, in some cases we use funds from these collaborators to cover our costs.

We still need to explore what these efforts cost and mechanisms to recover those costs.

Next step: Learning in public #

We’re excited to experiment with more effective upstream contribution and eager to learn. We’ll share our experiences so others can learn from and comment on our process.

Acknowledgements #

@MinRK and - @bsipocz for helping review a draft of this!
@choldgraf for feedback, guidance, and editing for this post and the team practices in it.
JupyterHub, JupyterBook, and Project Jupyter for teaching us a lot about open source over the years.

Currently this is particularly JupyterHub and Jupyter-wide leadership. We’re exploring how to incorporate JupyterBook into our service and are thus investing Foundation contributions there as well. ↩︎
With different kinds and sizes of organizations (companies, non-profits, universities, etc) and individuals being stakeholders. We want to avoid a single organization monopolizing power within any community. ↩︎
Across the power spectrum - from users to bug reporters to casual contributors to maintainers to people on governance duty ↩︎
Implementation note: We will not start doing all these immediately! We will consult with the rest of the team, and start these 1 at a time so we can build these processes sustainably and equitably. ↩︎
This requires a definition of “an issue that has been triaged”, and to our knowledge no such definition exists. We’d like to learn how to measure something abstract like “issue triage” - perhaps it is something specific putting it on a board for further action or applying a label, or something more abstract like “increasing how clear and actionable the issue is”. We’ll explore this when we start to make progress towards this objective. ↩︎

Demonstrating our infrastructure's reliability with a hub status page for our communities

Tue, 23 Sep 2025 00:00:00 +0000

One of 2i2c’s goals is to make the cloud safe for science. A big part of this is making the black box of commercial cloud infrastructure more predictable and reliable for our member communities, across our network of community hubs that all operate autonomously.

Give us feedback! Click here to provide feedback that will help us make this more impactful.

To that end, we’ve created a status page for 2i2c’s network of community hubs. This is a source of truth to provide a high-level picture of the stability of our infrastructure, let a community know if their hub is experiencing a problem, and to give us a heads up when things aren’t working as expected. You can check it out at:

👉 status.2i2c.org

The 2i2c Status Page gives communities a high-level view of the uptime for our entire network of community hubs.

While we make status more visible, we’re also streamlining our incident response processes in order to more quickly respond to outages when they occur (ideally, before a community has even noticed!).

There are still plenty of improvements we’d like to make: for example, we’re focusing on major outages right now, but would like to extend some level of reporting for degraded service, like unexpectedly slow start times.

Learn more #

👉 The status page
👉 The status page documentation
👉 Our new process for incident response
👉 Follow an in-progress initiative to improve the reliability of our infrastructure

Updates from Chris' position on the Jupyter Executive Council and Foundation Board

Tue, 23 Sep 2025 00:00:00 +0000

This is a running blog post for Chris to share out community updates from his time on the Jupyter Executive Council. See context for this page.

Updates for the Jupyter community from Chris #

Chris aims to write monthly updates for Jupyter’s community in the Jupyter Community Forum to share his perspective on what the council is up to. We’ll update this index post as new posts are available.

Blog posts about Chris’ experience on the executive council #

Chris blogs now and then to share his thoughts, important announcements, and provide major updates from his perspective on the executive council. Here are the posts that have come out of this effort.

Your Ideas, Our Support: Jupyter Community Call For Funding Proposals
Why open source foundations try to fund systems, not development - May 31, 2025
Jupyter can align the needs of its community and its foundation by enabling contribution - Mar 22, 2025
The relationship between the Jupyter Executive Council, Software Steering Council, and Foundation - Mar 02, 2025
Ways the Jupyter Foundation could support open source projects - Feb 26, 2025
Running for the Jupyter Executive Council - Jan 14, 2025

2i2c’s commitment to supporting open source communities #

In early 2025, Chris was elected to the Jupyter Executive Council. We’re tracking these efforts because providing leadership and community support to open source projects is a key Foundational contribution we wish to make for open source projects. 2i2c makes time for team members to contribute upstream in strategic ways like this as part of our commitment to open practices. However, this kind of work is very difficult to track! This blog post is an attempt at putting these efforts into one place for us to track and for others to discover.

Acknowledgements #

2i2c’s member communities support Foundation open source contributions like this with their membership fees.
The Navigation Fund provides strategic funding support for 2i2c which covers major open source leadership contributions like this.

Reducing base infrastructure costs on AWS with smarter instance types

Wed, 17 Sep 2025 00:00:00 +0000

We’ve been working to reduce the base costs of running our cloud infrastructure on AWS by switching to more efficient instance types for our core nodes. This is the core infrastructure we use to ensure hubs are “always available” for users, even when no one is actively using a hub. By moving from older r5.xlarge instances to newer, more efficient r8i-flex.large instances, we’ve significantly reduced these baseline costs while maintaining the same level of service. Here’s a plot of daily savings for the GeoJupyter community.

The graph above shows the impact on EC2 node costs specifically (this doesn’t include the entire cost of always-on infrastructure, but represents a significant portion). We are rolling out this change to all new clusters, and starting to work through our pre-existing AWS clusters.

Learn more #

Incident report: UC Merced user throttling during class startup

Tue, 16 Sep 2025 00:00:00 +0000

On August 29, 2025 our cloud infrastructure team experienced an incident with the UC Merced community hub when students tried to login simultaneously at the start of class. For more detailed technical information about this incident, see our full incident report.

What happened #

Students experienced issues when trying to login to the hub at the same time during the start of class.
The concurrent spawn limit was reached quickly due to the large number of users starting up simultaneously.
New nodes had to be brought up by the autoscaler, which took roughly 10 minutes from start to end.
Users who tried again after 1 minute weren’t guaranteed to get their servers started immediately since new nodes were still spinning up.
This was an “expected” scale-up event but the lack of clear messaging caused users to interpret it as instability.

What we learned #

We need better communication so users understand when infrastructure slowness is “expected” vs. “unstable”.
We need better alerting for concurrent user startup throttling - we found out about this issue from users rather than automated monitoring.
We learned that JupyterHub’s metrics don’t properly expose 429 status codes in our dashboards.
This will happen again if we don’t have proper scaling limits and node provisioning strategies for sudden user influxes.

Resolution #

We implemented several fixes:

Increased the concurrent spawn limit from 64 to 100.
Put UC Merced users on larger nodes to reduce the number of node spinups needed. this will cost more in cloud but result in fewer scale-up events.
Created action items to improve logging, alerting, and monitoring for similar incidents

Acknowledgements #

Thanks to UC Merced students and instructors for reporting the issue through our support system.

We're going to try blogging about our work more often

Wed, 10 Sep 2025 00:00:00 +0000

At 2i2c, we aim to be an exemplar organization in working openly, supporting open science, and supporting open source communities in everything that we do. We believe that open science is a process, not a product, and commit to following practices that align with open principles throughout our work.

A key principle for our team has always been working in the open. We do almost all of our work in our own public repositories or in upstream community spaces. However, still struggle to communicate what we’ve been up to. We can’t expect everybody to keep an eye on the spaces where 2i2c operates in order to learn whether we are actually living up to our goals.

So, we’re going to try an expriment that is inspired by Simon Willison’s blog. In short, here’s what we aim to do:

Use our blog any time we learn or do something that’s aligned with our value proposition.
Don’t hesitate to share in-progress work and things that are still rough - this is part of working in the open.
Occasionally, share posts that help readers navigate this stream of short impact posts. We’ll use our Mailing List for this, so click that link if you’d like to sign up.

Our hope is that this will give us a steady stream of posts that show what we’ve been up to, as well as a way to navigate those posts via our mailing lists for the folks that don’t want to spend all day combing through our blog. :-)

Acknowledgments #

Support for organizational and strategic work like this is provided by a grant from The Navigation Fund.

On being a good open source citizen: supporting a healthy ecosystem through directed and foundational contributions

Wed, 03 Sep 2025 00:00:00 +0000

Any organization building on open source faces a fundamental tension: how do you serve the needs of your organizational stakeholders while also acting as a responsible steward of the upstream projects you depend on? This is harder than it looks - simply “making PRs” leaves a number of open source needs unaddressed, and can burn out both your team members and the open source maintainers. We think about this a lot at 2i2c, and want to share our framework to navigate this challenge intentionally.

Here are a few questions we’ve been grappling with:

How do we tie general upstream maintenance to value delivered to our user communities?
How can we scope upstream support so that it doesn’t detract from our service needs and product strategy?
How can we encourage team members to work on the most impactful aspects of upstream support?
How can we intentionally and equitably support open source communities as a team, rather than a collection of individuals?

Along the way, we realized there are two very different kinds of upstream contributions:

Directed Contributions: A contribution driven by the needs of our member communities and product roadmap. We call these “Directed” contributions because they address a targeted need driven by one stakeholder (us!).
Foundational contributions: A contribution driven by the needs of the upstream community. We call these “Foundational contributions” because they’re meant to provide the healthy foundation on which a community can operate and grow.

Historically we have conflated these types of contributions, but we think it’s key that we treat them differently.

Note: For a more practical guide that describes the systems we’ve set up to accomplish Foundational upstream contributions, see From scattered effort to strategic impact: How we’re systematizing our Foundational open source contributions.

Everybody has an open source hat and a stakeholder hat #

Open source teams¹ are usually two kinds of teams that overlap heavily:

A collection of stakeholders working together on the open source project, each with their own goals and interests.
An open source team with a shared goal and strategy for the open source project.

In this case, stakeholders can be individuals or companies. They use and contribute to the open source project because it advances their own interests. For example, an enthusiast contributing to a project because it brings them joy, or a company contributing to a project because they build a product that depends on the open source technology.

However, for open source projects to be successful they also need their own unique identity, goals, strategy for impact, and system of work. This allows a diverse collection of stakeholders to work together effectively and create impactful technology. This team is made up of the same stakeholders described above, but with a responsibility to lead and support the open source team, rather than just serve their individual interests as stakeholders.

Thus, any open source stakeholder has two hats: they are both representatives of a stakeholder and members of an open source team. While it’s possible to align the interests of these two groups, we think it’s still important to distinguish between them.

Directed Contributions benefit the stakeholder you represent #

A Directed Contribution is primarily driven by the needs of a stakeholder in an open source project. To use 2i2c as an example, let’s take a quote from 2i2c’s value proposition:

2i2c serves a global network of community hubs for interactive learning and discovery

Community here does not refer to open source upstream software provider communities (like JupyterHub or Kubernetes), but instead to downstream user communities (like CryoCloud, Openscapes, or NASA VEDA).

When 2i2c makes a Directed Contribution, it means we are trying to deliver value to one or more of our member communities by making an upstream contribution.

Satisfying community needs often involves directly working on the software they use. Driven by our right to replicate principles, this means we mostly work on software that is not proprietary to 2i2c nor solely owned by us permanently - but by contributing to an upstream software community. These are all Directed Contributions.

Some illustrative examples:

Allow login to be gated on OAuth2 granted scopes was a feature we added to support one of our communities’ auth flow ( EarthScope)
Changing how .pyc files are kept in images was work we did as a result of a support ticket investigating spawn timeout issues in the LEAP hub.
Adding landing pages functionality to Jupyter Book and MyST was work we did to support member communities like CryoCloud and Project Pythia.

The fact that these are open source contributions is incidental. We are primarily doing this work to deliver value to our community network.

We plan Directed Contributions according to our roadmap and member feedback #

Directed Contributions naturally align with 2i2c’s overall goals and strategy, so we use our product processes for planning and delivering on them. However, we also want to provide transparency to upstream communities so that they understand who is driving the contributions that we’re making.

With that in mind, here are a few ways that Directed Contributions relate to our practices:

Directed Contributions should be defined by our product roadmap and prioritization processes.
We allocate engineering time for these upstream contributions as part of our product lifecycle, including the extra coordination and communication work needed to work at the pace of the upstream community.
We cross-link 2i2c product initiatives to upstream issues and pull-requests wherever we can to provide transparency about why we’re making a contribution.
We communicate this work via our blog so that 2i2c’s member communities know about the contributions we’ve made on their behalf.

Foundational Contributions support a healthy open source community #

However, contributions can’t always be driven by a stakeholder’s needs or the open source team will not have an identity or support structure of its own. Here’s another excerpt from our value proposition:

We need infrastructure services that are driven by community needs and values, that follow the same open source science practices we wish to see in others, and that believe in the power of shared community resources and knowledge.

Being a “healthy upstream citizen” is core to 2i2c’s mission, and is also a way to help communities we rely on remain healthy. Some of our contributions should be Foundational rather than Directed. This means doing things that keep the overall ecosystem healthy even if it does not directly address a specific member community need. The presence of a healthy open source ecosystem is a value to our member communities in-and-of itself.

Defining “Foundational” needs is difficult, because open source teams tend to have less structure and formally-stated goals and needs than most organizations. In 2i2c’s case, we focus our Foundational Contributions around maintaining the health of the open source ecosystem.

It includes things like:

Grow and guide new contributors to grow team capacity
Help making releases
Provide code review
Fix broken CI
Write documentation and tutorials
Manage and run meetings
Align open source teams on goals and strategy

However, the real point is that these actions need to be driven by the upstream project’s goals and needs, not by 2i2c’s needs.

Here are a few common examples of contributions that are not considered Foundational for our team:

Opening a PR to add a major feature to an upstream project.
Creating a brand new project in an open source organization in order to scratch your own itch.
Engaging in reactive open-source work that isn’t driven by a clear strategy or goal (e.g., randomly responding to the last few GitHub issue comments you happened to notice)

We plan Foundational Contributions alongside our engineering roadmap #

Foundational Contributions are important to 2i2c both for strategic and tactical reasons. However, when left as unstructured time (as we have historically), it runs into all the problems of unstructured work - it happens in non-strategic ways, it isn’t evenly balanced across team members, it is more or less accessible depending on your personal comfort level and skills, etc.

With that in mind, here are a few ways that Foundational Contributions relate to our practices:

We need to own Foundational Contributions as a team, rather than asking individuals to identify and do this work on their own.
We need to define team goals and strategy to define the impact we want to have, and what kind of work leads to that impact.
We need a team system for identifying and prioritizing the most impactful Foundational Contributions to perform.
This system must spread the responsibility of Foundational Contributions across our whole product team.
It means we need to give people support and training to do this effectively. For example, helping team members grow into roles that involve upstream work, rotating certain types of contributions across team members, etc.

To ensure this work is intentional and equitable across our team, we encourage Foundational contributions to happen within this framework. Contributions that falls outside of it is treated as a valued, but separate, personal contribution.

What’s next #

By distinguishing between Directed and Foundational contributions, we can align and balance our immediate product needs with our long-term commitment to community health. We believe this framework allows organizations like ours to be better partners. We’d love feedback about this process, how we can improve it, and what others have learned along the way.

By “open source” we are focusing on multi-stakeholder open source projects with participatory and inclusive leadership and contributions. This wouldn’t apply to an organization- or person-specific open source project. ↩︎

Sharing JupyterHub's vision for more flexible application deployment at the doepy talk series.

Wed, 03 Sep 2025 00:00:00 +0000

Our Technical Lead Yuvi Panda recently gave a talk at the doepy meetup about JupyterHub’s interest in moving beyond the “single-user notebook application” and towards a more flexible approach to enabling administrators to deploy many different types of applications and environments.

Check out a video of the talk here:

This is an important step for the JupyterHub project in order to support the many different kinds of workflows that data scientists need to use in their work. We hope that this generates more interest in the JupyterHub project and gives us useful feedback to guide the team’s understanding of this direction.

Learn more #

Acknowledgements #

The doepy team for inviting Yuvi to give this talk.
The JupyterHub team for working with us on this strategy.
2i2c’s network of member communities whose fees support our Foundational open source engagement.

Giving CCAD more control over data science infrastructure via a Catalyst Project hardware exchange

Tue, 02 Sep 2025 00:00:00 +0000

2i2c has successfully completed a hardware exchange with Universidad Nacional de Córdoba’s Centro de Computación de Alto Desempeño (CCAD) through funding from the Catalyst Project. CCAD used funding to purchase new on-prem computing infrastructure, significantly expanding their computing capabilities.

This exchange reduces CCAD’s reliance on ongoing cloud funding while giving them direct control over their infrastructure. The new hardware will support a scalable JupyterHub deployment and provide valuable training opportunities for researchers who may work with local computing resources.

Learn more #

Acknowledgements #

Chan Zuckerberg Initiative for their Catalyst Project award
CCAD for their collaboration on this hardware exchange

Overhauling repo2docker's documentation

Fri, 01 Aug 2025 00:00:00 +0000

Documentation is incredibly important for open source projects to communicate their value and show users how to make the most of their tools. However, it’s one of those things that often gets de-prioritized with all of the other work that needs to happen in a project.

We are heavy users of the repo2docker project in 2i2c’s service. It allows you to dynamically build an environment image that can by hosted in a cloud service like JupyterHub. It’s the underlying tool used by BinderHub, and is the focus of recent work on enabling dynamic image building in a JupyterHub (more on that to come).

As part of this work, we decided to do a small overhaul of repo2docker’s documentation, with the goal of making it easier to discover, navigate, and learn from. Here’s how the landing page looks now!

The new repo2docker landing page now looks more like an actual landing page!

We hope this makes repo2docker a more useful tool for everybody, and also gives us more confidence pointing our communities to the repo2docker documentation in their community workflows.

Acknowledgements #

Thanks to the NASA VEDA project for providing funding and collaboration for this work.
Thanks to the JupyterHub community for collaboration and review of this work.

Our Product and Service goals for Q3 2025

Tue, 22 Jul 2025 00:00:00 +0000

As we enter Q3 2025, our focus remains on enabling better cost controls for our communities and increasing flexibility for end-users. In line with our commitment to transparency, we’re sharing our platform and service objectives for the quarter and inviting feedback to ensure our direction reflects what matters most to the communities we serve. See our product goals from the previous quarter here.

The themes below offer a high-level snapshot of where we aim to evolve our offerings in the coming months.

⭐ Connect with us

Give us feedback about our direction and how it can improve.

Fund parts of this work if you’re interested in making something happen.

Demonstrable reliability of our infrastructure #

Hub management has many moving parts, and things can go wrong. We want tighter control over the reliability of our infrastructure and better visibility into the status of our community hubs for administrators and members. We will take steps to improve alerting, uptime, and overall platform reliability, as well as review our internal incident response practices. Our goal is to improve the reliability and responsivity of our interactive computing hubs for both administrators and users throughout their community hub lifecycle.

User-level costs monitoring and group-level usage monitoring #

We’ll build on our recent Grafana dashboard usage monitoring to add usage monitoring for user groups and begin work on user-level costs monitoring. These are steps toward group-level cost tracking, which will enable better management of team and departmental expenses, especially in large institutions.

Improving our Incident Response capability #

As a special-case of doubling down on infrastructure reliability, we’re making a concerted effort to improve our incident response processes. This will allow us to respond more reliably and transparently to issues as they arise, and to give our communities confidence about the steps we’re taking to resolve them. Our goal is to improve response time and quality, and connect this with infrastructure reliability improvements.

Piloting a feature co-funding model #

This year, 2i2c has experimented with a collaborative community funding model for platform development. This is a way to share funding across communities, and to invite community champions to co-fund projects on the 2i2c roadmap. Our goal is to accelerate upstream development with funded time while minimizing costs for each community. Over the next quarter, we’ll share more details on how the program works, how communities can participate, and what we’re learning along the way.

Early candidates for community funding:

Compute quotas: Building on our user and group management foundation, we aim to let admins assign compute quotas to users or groups, increasing cost control and easing departmental budgeting.
Canvas authentication: Integrating with Canvas will enable management of users and groups within Canvas, while using the same data for usage and cost tracking.
nbgitpuller UX improvements: Enhance nbgitpuller for sharing interactive projects via a simple link, focusing on error handling, conflict resolution, and per-user authentication for content retrieval.

As we develop this initiative, we’ll need to learn how to credit community partners who co-sponsor work and align our roadmap with the interests of the upstream communities we support.

If you have suggestions for improving this process, or if any features interest your community, reach out to us to discuss joining other 2i2c communities in funding and accelerating their development.

Another update coming in Q4 #

Each quarter, we’ll share an update like this to outline our product priorities and track progress. When planning for Q4, we’ll review what we’ve accomplished and provide a community update. Stay tuned!

Meanwhile, let us know what you think about our direction. Your feedback helps us provide the best value to our communities. Thank you!

Acknowledgements #

Our strategic and organization-level work is supported by a grant from The Navigation Fund and fees from our member organizations.

Product and team highlights from Q2 2025

Mon, 21 Jul 2025 00:00:00 +0000

This post highlights what stood out to us from last quarter and reflects on the targets we set at the start of the quarter.

This quarter, our team learned the importance of shipping iteratively and inviting feedback frequently. In some cases, we learned this the hard way - having spent multiple cycles developing without feedback from community representatives. In other cases, we made rapid progress by working in collaboration with community members in our network. next quarter, we are leaning into this approach as we work towards building a more standardized and sustainable service for our community network.

We’ve experienced some disruption and more uncertainty due to the current scientific funding climate, and we’re working hard to iterate on this model with feedback from our communities to find a path towards sustainability. We’re confident that we’ll get there, and improving the value our network of community hubs is a key way to do so.

With that in mind, here’s what stood out from the quarter:

⭐ Find our JupyterCon 2025 submissions here to see some other things we’re excited about sharing.

Group-level resource monitoring #

Building on our previous work delivering usage monitoring using Prometheus and Grafana, we’ve released jupyterhub-groups-exporter, allowing hub administrators to leverage the latest group management features in JupyterHub to monitor group-level resource usage effectively, making it easier to identify usage patterns across teams and departments.

⭐ Members of 2i2c’s community network can learn how to use this in our user guide to usage monitoring. See this blog post announcing jupyterhub-groups-exporter.

Last year we introduced customizable servers via profile lists. We’re building on that - servers can now be configured to allow users to dynamically specify, build, and share their own custom environment images without the need for a hub administrator. This will allow community champions with diverse user bases to give their users greater flexibility to support a wide variety of custom computational workflows, accelerating knowledge discovery and sharing. Look out for a blog post on this development in the coming weeks and months.

⭐ Members of 2i2c’s community network can learn how to use this in our dynamic image building quick start guide.

Co-located narrative content with out-of-the-box Jupyter Book support #

Central to our communities’ work is sharing new findings, best practices, and community resources. To facilitate that, we’ve added support for Jupyter Book 2 for all of our member communities. Our communities can rapidly build interactive starter documentation and provide users with a rich, interactive, and informative onboarding experience. With a suite of customizable landing-page layouts, colour themes, and component galleries ready to match a community’s branding, it’s now easier than ever to couple a hub with its own co-located narrative content.

⭐ Members of 2i2c’s community network can learn how to use this in our user guide to documentation and sharing. See this blog post for an announcement.

A better onboarding experience for our communities #

We have been working on a streamlined onboarding experience for communities, smoothing out the process of gathering requirements, customizing a hub for the community’s specific needs, and delivering new hubs more rapidly. We will be rolling out this process in the next few weeks for new communities onboarding the 2i2c network, and aim to continue learning and refining this process to deliver a faster, smoother onboarding experience for everyone.

⭐ Members of 2i2c’s community network will see changes to our process over the coming months that increase the speed and ease of hub delivery.

Efforts to improve and formalize the services we deliver to our communities #

As 2i2c has grown over the past few years, it organically developed internal processes for handling common tasks such as the management, rollout and maintenance of hubs, as well as expect consulting to help our communities get the most value out of their hubs. Earlier in the year, we realised it was time to review and refine these processes to better serve our growing community network. As a result of this exercise, we now have tighter service definitions and best practices which clarify what service levels our communities can expect, and how we can internally meet those expectations. We will be publishing our service definitions in the coming months as they are finalized, to ensure full transparency with our communities.

⭐ You can learn more about our efforts to standardize and scale our services by following the 2i2c blog, where we’ll share our work as it stabilizes.

Another update coming in Q3 #

We’ll be announcing the focus for our next quarter in a follow-up post, so stay tuned for our next roadmap update, and don’t forget to let us know what you think of our direction - we welcome your feedback!

Acknowledgements #

Thanks to The Navigation Fund for core support to 2i2c which funds this strategic and organizational work.

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.

Open slides: Jupyter Book 2 and MyST at the UC Berkeley Data Science Education Summit

Tue, 01 Jul 2025 00:00:00 +0000

Chris gave a talk about Jupyter Book 2 and MyST at the UC Berkeley Data Science Education Program’s annual meeting. It covered the next direction for the Jupyter Book project, and its recent adoption of the MyST Document Engine for Jupyter Book 2.

You can view the full slide deck here.

Learn more #

Acknowledgements #

Thanks to Project Pythia for funding some of our work on the Jupyter Book and MyST ecosystem
Thanks to CloudBank for collaborating with us on adapting and deploying Jupyter Book for education and organizing this summit
Thanks to the Jupyter Book project for collaborating with us on these strategic efforts over the last years

Announcing `jupyterhub-groups-exporter`: monitor usage based on JupyterHub group membership with Prometheus and Grafana

Wed, 11 Jun 2025 00:00:00 +0000

Managing user groups in JupyterHub can be a challenging task, especially in environments with dynamic user bases and complex group structures. This post describes how we can leverage the latest group management features in JupyterHub, along with Prometheus and Grafana, to monitor group-level resource usage effectively.

⭐ Members of 2i2c’s community network can use this feature in their hubs by following our cost attribution documentation.

Motivation #

Hub admins have a strong impetus to monitor usage and costs by user groups because it allows them to advocate for better funding and cost recovery models based on data-driven insights. Group-level resource monitoring can help them to answer questions like:

How many people participated in our workshop group?
How much GPU compute is our power user group using?
Is our resource usage cost-effective for X group persona or Y group persona?

Current methods and workarounds include:

ring-fencing resources for specific user groups personas, e.g. creating a separate hub for a workshop group, or creating a separate Dask cluster for a power user group, which increases the admin burden of managing multiple hub instances
writing custom scripts to aggregate per user metrics, that are already available, into groups – which can be time-consuming and error-prone

JupyterHub and user groups #

Recent key developments upstream in JupyterHub for groups management, such as Authenticator managed group membership, makes this piece of work a prime and timely opportunity to be tackled. For more technical details of these upstream contributions, see GitHub PRs jupyterhub/oauthenticator#735 and jupyterhub/oauthenticator#498.

Users can access JupyterHub using a variety of authentication methods. Authentication providers like GitHub have built-in user management features that allow admins to create and manage user groups. These groups can then be configured in JupyterHub to authorize access to the hub, as well as control access to certain hardware profiles.

Following the key upstream contributions above, we can leverage Authenticator-managed group membership to automatically pass user group memberships from the authentication layer to JupyterHub itself. This allows us to capitalize on JupyterHub’s REST API to retrieve user group memberships from other services, such as exporting them as Prometheus metrics.

Exporting user group memberships to Prometheus #

The jupyterhub-groups-exporter project provides a service that integrates with JupyterHub to export user group memberships as Prometheus metrics. This component is readily deployable as part of any JupyterHub instance, such as a standalone deployment or a Zero to JupyterHub deployment on Kubernetes.

The exporter provides a Gauge metric called jupyterhub_user_group_info, which contain the following labels:

namespace – the Kubernetes namespace where the JupyterHub is deployed
usergroup – the name of the user group
username – the unescaped username of the user
username_escape – the escaped username

Escaped usernames are useful because Kubernetes pods have characterset limits for valid pod label names (this limit does not apply to pod annotations). Storing both types of usernames allows us to join escaped versions with their more human-readable unescaped usernames.

Exposing this metric as an endpoint for Prometheus to scrape allows us to query and join groups data with a range of usage metrics to gain powerful group-level insights. Here is an example PromQL query that retrieves the memory usage by user group:

sum(
 container_memory_working_set_bytes{name!="", pod=~"jupyter-.*", namespace=~"$hub_name"}
 * on (namespace, pod) group_left(annotation_hub_jupyter_org_username, usergroup)
 group(
 kube_pod_annotations{namespace=~"$hub_name", annotation_hub_jupyter_org_username=~".*", pod=~"jupyter-.*"}
 ) by (pod, namespace, annotation_hub_jupyter_org_username)
 * on (namespace, annotation_hub_jupyter_org_username) group_left(usergroup)
 group(
 label_replace(jupyterhub_user_group_info{namespace=~"$hub_name", username=~".*", usergroup=~"$user_group"},
 "annotation_hub_jupyter_org_username", "$1", "username", "(.+)")
 ) by (annotation_hub_jupyter_org_username, usergroup, namespace)
) by (usergroup, namespace)

Visualizing user group resource usage with Grafana #

The PromQL query above is rather long and complex to construct! However, you can benefit from an upstream contribution to the jupyterhub/grafana-dashboards project where we have encapsulated the PromQL queries as Jsonnet code and represented them as Grafana Dashboard visualizations (also known as Grafonnet). If you have a Kubernetes cluster running JupyterHub, try deploying these Grafana Dashboards and let us know what you think!

Our particular PromQL query above is visualized in the Grafana Dashboard User Groups Diagnostics under the Memory Usage panel (see also the corresponding screenshot at the top of this post). This is equivalent to its counterpart User Diagnostics dashboard, but with resource usage visualized on a per-group level rather than a per-user level 🎉

Future work #

We have laid the foundation for joining user group data to usage metrics with Prometheus by extracting memberships from JupyterHub’s database. This unlocks potent ways in which observability systems can be extended to group-level reporting and monitoring.

Future directions for this work include:

visualising cloud cost by user group in Grafana
developing more group-level reporting and monitoring dashboards
introducing group-level resource quotas.

What do you think? How would you like to see JupyterHub’s group management features evolve? Have you tried deploying this yourself? We welcome your feedback and feel free to open GitHub issues or make contributions to the repositories mentioned in this post.

Acknowledgements #

Thanks to the JupyterHub project for their collaboration and review of this work.

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.

Jupyter Book at the Scientific Python 2025 Developer Summit

Fri, 23 May 2025 00:00:00 +0000

Chris and Angus recently attended the Scientific Python 2025 Developer Summit on behalf of Jupyter Book, here’s a brief blog post about their experience written with the Jupyter Book team.

Launching Jupyter Book for 2i2c Communities

Thu, 08 May 2025 00:00:00 +0000

We’re excited to announce out-of-the-box support for Jupyter Book 2 for our community members. This allows communities to create and share knowledge bases together for their community workflows. This post describes the motivation behind this new functionality, and how you can learn more about the project.

⭐ Members of 2i2c’s community network can use this feature in their hubs by following our documentation and sharing guide.

A core component of our mission to make research and education more impactful, accessible, and delightful is leveraging our unique global network of communities to make meaningful improvements to the open-source tools that power their work. Learning from one community can then provide value to our entire network, e.g., our work with PACE on speeding up their CNN model training.

Central to our communities’ work is the importance of sharing new findings, best practices, and community resources. Across our network, we have seen communities creating their own “books” that provide a home for this kind of content. Many of these books feature the concept of a “landing page” that welcomes new members, establishes an identity, and provides jumping-off points (or “calls to action”) to more detailed resources.

Until now, each community has been required to undertake this work independently. 2i2c believes that by building upon existing open-source tools like Jupyter Book 2, we can help communities focus on the content of their home, rather than spending time worrying about its appearance. To that end, we have been working on an initiative to allow communities to rapidly build interactive starter documentation and provide users with a rich, interactive, and informative onboarding experience. Through this initiative, we have:

Improved the user experience of launching into interactive compute environments from a Jupyter Book.
Built components into the Jupyter Book “book theme” for low-density landing page content like call-to-action blocks.
Extended our service to co-locate community documentation alongside community hubs (i.e., docs.hub.2i2c.cloud).

(A screenshot of the 2i2c Showcase Hub landing page, featuring a simple banner image and call-to-action.)

To take advantage of this feature, communities can use the 2i2c-org/community-docs-template to deploy a Jupyter Book site to GitHub Pages. This template demonstrates simple usage of Jupyter Book 2 for computational content and landing page creation, and establishes the necessary CD workflows for web publication. Meanwhile, 2i2c can update our domain name management to point the docs.hub.2i2c.cloud nested subdomain to the newly deployed documentation.

For more information, see our community documentation for deploying Jupyter Books.

Developing these new capabilities taught us a lot about what makes building “good” community documentation so difficult. A wide range of bespoke website-building tools and integration quirks previously made it challenging for communities to both keep documentation current with internal changes and keep up with necessary software updates. We also learned that by trading bespoke complexity for simplicity and readability, we could build a solution that scales to multiple communities, with a consequently reduced maintenance burden.

With these improvements, we have initiated a conversation about what a more unified “look and feel” for our network might entail, and how it might benefit our communities. Much more can be done to build on this first step, and we are eager to gather feedback on how to improve these features for users.

To learn more about this work, consider exploring a minimal example on our Showcase Hub, and check out our service guide. Let us know what you think!

Offering Jetstream2-powered hub support at 2i2c

Mon, 28 Apr 2025 00:00:00 +0000

When we first committed to offer Jetstream2 support at 2i2c, Jetstream2, Magnum, OpenStack, ClusterAPI were all new concepts that we hadn’t used at 2i2c before. And although the initial exercise of reading about each of them independently was confusing, learning how they actually glued together was the key. This post is about Jetstream2, 2i2c persistent hub offerings, and the learning that took place in the process.

⭐ Members of 2i2c’s community network can determine their eligibility and learn about JetStream2 in our supported cloud providers documentation. If needed, reach out to 2i2c for support.

Context #

At 2i2c, we want to be able to deploy k8s clusters on different cloud providers. In a very simplistic way, for this we use:

Infrastructure as code to describe, deploy and manage the actual physical infrastructure from the cloud providers
Cloud specific CLI to authenticate to this infrastructure
Helm to deploy and manage k8s resources onto this infrastructure
And finally kubectl to interact with all of these k8s resources

(Main tools used at 2i2c to deploy and manage k8s clusters on different cloud providers)

On cloud providers like GCP, AWS, Azure, the Kubernetes support feels like an atomic feature of the cloud provider and works out of the box. But on Jetstream2, k8s support is not such a solid feature anymore.

Jetstream2 Kubernetes support stack #

Jetstream2 is a collection of supercomputers that are part of the ACCESS cyberinfrastructure. This ACCESS infrastructure groups together super computers like Jetstream2 (but not limited to it), into a mesh that creates the impression of a single, virtual system that scientists can openly access and interactively use.

It offers Infrastructure as a Service (IaaS), that allows users to deploy VMs and manage environments dynamically. And the piece that enables this Infrastructure as a Service feature is OpenStack.

OpenStack and Magnum #

OpenStack is an open source platform made of multiple projects that help build and manage both private and public cloud infrastructure.

For our use-case, one of the most relevant OpenStack sub-project is Magnum. Magnum offers container orchestration engines for deploying and managing containers, like Kubernetes, but not limited to it.

Initially, Kubernetes support was provided through a project called HEAT. However that has proven harder to manage and maintain, and it was extremely hard to upgrade a cluster. So, they’ve migrated towards a new driver called Cluster API magnum driver, which offers a more native k8s integration.

Cluster API and CAPI helm driver #

CAPI itself is k8s project that allows declaring k8s clusters in an easy way.

The helm driver on the other hand is what acts like a bridge between OpenStack’s Magnum and Kubernetes’ Cluster API (CAPI). Its main goal is to to manage the lifecycle (create, scale, upgrade, destroy) of Kubernetes-conformant clusters using a declarative API.

In order to do this, Cluster API provides an API for being able to manage the various components of a Kubernetes cluster. This conceptually looks like a Kubernetes cluster managing other Kubernetes clusters; the former, named the ‘CAPI management cluster’, is the one providing the API for managing the latter workload clusters.

Decomposing the previous atomic feature #

(Comparison between Jetstream2 and other cloud providers when it comes to k8s support)

Magnum is part of the OpenStack tent and it’s the first layer on top of Jetstream2 towards achieving k8s support.

The CAPI helm driver is what’s offering CAPI support. This is the last piece that’s needed to link a k8s cluster down to the hardware where it’s deployed, on Jetstream2.

Challenges #

The Jetstream2-OpenStack stack is not a simple one. It’s a complex stack of technologies and each of the connection points can be challenging to debug and fix when something doesn’t work. Especially when you are one of the first ones that pilots this new magnum driver setup.

So, it was expected that we faced some issues along the way. However, we were able to go around them and add Jetstream2 to our service menu. Below is a list of some of the issues that we faced:

We have to create terraform resource in sequence which takes longer because of a race condition that makes concurrent nodegroups creation requests to fail

bugs.launchpad.net/magnum/+bug/2097946

The role and labels of the nodegroups don’t get propagated to the actual nodes, so we cannot put our own labels on nodes at once

azimuth-cloud/capi-helm-charts#84

The node count and min node count cannot be set to 0 and each nodegroup has to have at least 1 node

bugs.launchpad.net/magnum/+bug/2098002

A default-worker is created apart from the default-control plane nodegroup and we cannot delete it due to the same issue as in 2.
Latest CAPI helm chart version causes autoscaling to stop working in a persistent hub setup, so we had to downgrade it to a previous version

2i2c-org/infrastructure#5601

Conclusion #

The biggest plus, is the people. We got support from Julian Pistorius, which has helped us a lot to both fix and validate some of the behaviours we were experiencing. Also, going through the Jetstream2 support process was also a pleasant experience because they were super prompt in answering and they were very nice.

Jetstream2 has a big plus over the other cloud providers with its openness thought the ACCESS program. This is something very handy to researchers and less costly than other cloud providers. 2i2c being able to offer hubs though this ACCESS program makes things more accessible to more researchers and more cost efficient.

Higher complexity comes also with more control over the infrastructure which has its advantages.

Leaving the challenges apart, the experience was a nice one and the outcome was positive -> 2i2c is now able to deploy both mybinder.org-like hubs as well as persistent storage hubs on Jetstream2 hardware, from the same cloud-agnostic infrastructure.

Acknowledgements #

Thanks to Project Pythia for funding and collaborating with us on this work.

2025-Q1 reflection: Building a foundation for our new platform and membership model

Wed, 16 Apr 2025 00:00:00 +0000

This is a summary of major progress we made in Q1 of 2025. Its goal is to summarize our major accomplishments and important context before we prioritize for Q2. We hope this gives our community stakeholders a more strategic-level insight into our progress and organizational plans. See our Product Highlights for 2025Q1 for a product-focused review. Please give us feedback for how we can provide more useful information.

Heading into Q1 2025, we had just completed an organizational re-structuring into new functional areas. These were Products and Services, Business Development, and Delivery and Team Enablement. Our support from The Navigation Fund began in January 2025, and we re-organized around the goals defined in that report. Q1 2025 was the first quarterly cycle under this new system.

Our primary Q1 2025 goal was to build a solid organizational foundation that will enable us to iterate on our product and business model in Q2. We successfully completed our reorganization into dedicated Business Development and Product teams, and implemented a new quarterly target-setting process across the organization. There are still some key remaining areas to make progress, and we need to ensure that key KPIs and team responsibilities are solidified quickly in Q2.

Below we’re sharing a brief update about the major achievements across each area of 2i2c, and first thoughts about outcomes to target in Q2 2025.

Delivery and Enablement #

Goal: Develop the operating structure and team skills to efficiently scale our product and service delivery.

Quarterly Objectives

D01: Re-organize into product-centric team structure. Define new roles, and accountability practices.
D02: Define at least one KPI across each of 2i2c’s areas and complete 2-3 iterations of measurement.

How we did #

We did a good job of taking our first steps at being more structured and intentional about our team and our goals. Our biggest accomplishment was to significantly improve the Product and Services (P&S) team’s ability to plan and deliver on work. We are now measuring velocity as a P&S team, and this gives us a much better understanding of our capacity and a means of optimizing it.

We were slower than expected in defining our new team structures - particularly within the Business Development (BD) team, but I’m confident that we are now on the right track. The biggest remaining challenge is to refine the relationship between BD and P&S so that we have clear responsibility hand-offs.

We have made progress defining KPIs, but have had uneven success in implementing them across the teams. We defined the BD KPIs later than expected, and as a result we must still operationalize our measurement of those KPIs.

Finally, we were inconsistent in the way that we completed and documented the work above, and did not reliably encode outcomes as a “source of truth” in our team compass. This resulted in some confusion about the status, context, and outcomes of some of the team initiatives.

Product and Services #

Goal: Create a systematic approach to defining our product value and prioritizing development work.

Quarterly Objectives

P01: The Product Menu of current capabilities already exists. The focus now should be on finalizing the Product and Services MVP, which is linked to goal S01
P02: Integrate Services into the Product roadmap, prioritizing those needed to enable S01
P03: We have designed a qualitative survey to benchmark and record customer satisfaction for any newly released product feature. This survey is already in the process of being sent out to customers of the recent Grafana work, and will be sent out to representative customers of subsequent feature releases.

How we did #

We’ve finalized our product roadmap and incorporated service design priorities into this system as well. It now guides both technical and service development which are the two key ways that we deliver value to our communities. This is a key win for the team, because it means we can more systematically decide what to build next in order to deliver value to our communities.

We also collaborated with the BD team to define our menu of options for communities and ensure they are clearly defined and scalable for our team. This involved a lot of extra back-and-forth that wasn’t planned, but was critical to ensure we had alignment between our business model and our team’s ability to deliver.

We ran an experiment at conducting community surveys to establish a baseline customer satisfaction KPI and learn if we are building the right things, but didn’t have the response rates that we needed to be useful. We need to find a way of efficiently creating actionable answers to “are we building the right thing?”.

We also agreed on a general principle of measuring community engagement as a primary KPI, but have not yet operationalized it. This is a key metric to understand whether we’re delivering the value we intend, and whether a community is likely to renew their contract.

Finally, in some cases we have continued to interact with communities in an unscalable way. This is both true for the ways in which we’ve given communities guidance and training, as well as the ways that the P&S team has supported BD in its sales and marketing efforts. It is critical that we build scalable systems for delivering services to all of our member communities to ensure that we deliver value to our entire network of member organizations and not just those we have the strongest connections with. It will also create more scalable channels of communication and relationship-building with communities so that we can support and learn from our entire network.

Business Development #

Goal: Create a structured service menu and improve sales tracking.

Quarterly targets

S01: Define a tiered pricing and service model
S02: Define a scalable sales system
S03: Create and operationalize revenue targets and projections

How we did #

Our BD team built a three-tier membership model that combines monthly fees with active user pricing. This gives us a foundation to iterate on our pricing and business model. Initial anecdotal feedback from renewing communities has been positive, though we have not yet systematized a process for collecting and incorporating feedback from communities into our sales assets.

We’ve completed the first version of our sales CRM to track all customer conversations and tie them to ongoing opportunities. The CRM is now being used reliably, and has already generated helpful feedback for improvement. However we did not make our intended progress in creating systematized and scalable sales assets. It will be critical to build these assets quickly so that we can engage in efficient sales conversations and iterate quickly.

We were slower than expected in defining the KPIs that drive BD. We’ve successfully defined the KPIs that should drive BD, but have not operationalized and iterated on business development targets. It will be critical to measure these BD KPIs and define targets in Q2 in order to set a benchmark of success for BD.

Finally, we were slower than expected in defining the team structure of BD, due to a diffusion of responsibility stemming from our shared leadership model. We’ve clarified that ambiguity and now have a defined structure of roles and responsibilities within BD.

Concluding thoughts #

Overall, I consider this quarter a success, given that we are operating with new systems for planning and executing work, as well as a new team structure. We didn’t accomplish everything we set out to do in Q1 2025, but I think that’s OK for our first quarterly cycle. In Q2 I expect us to be better at scoping the work we aim to accomplish, as well as holding ourselves accountable for getting it done.

In Q2, we need to prioritize the refinement of our Business Development / Membership model and the system we use for growing and sustaining it. Our P&S team is now much more reliable at planning and delivering work, and our next bottleneck is having a business process that can reliably generate work and revenue that sustains the organization. This will be a key focus in our Q2 planning.

Acknowledgements #

Thanks to The Navigation Fund for core support to 2i2c which funds this strategic and organizational work.

Our Product and Service goals for Q2 2025

Wed, 16 Apr 2025 00:00:00 +0000

As we head into Q2 of 2025, we continue to focus our work delivering on a small set of core themes that reflect our communities’ most pressing needs. As a part of this process, we want to continue sharing our platform and service goals in an effort to remain transparent, as well as to provide our communities with an opportunity to give us feedback on our direction, and on what’s important for them. See last quarter’s product goals here.

The following themes are not guarantees, but should provide a high level view on how we plan to improve our product and services offerings in the next quarter. If your organization has funding available to support any of the enhancements below, reach out to us and we can discuss how you can shape our priorities and outcomes.

Give administrators more control #

The implementation of per-user storage quotas in Q1 was the start of a set of product initiatives aimed at giving hub administrators more control and peace of mind over unexpected cost overruns.

We aim to continue giving administrators more control by implementing the ability to associate users with groups for usage monitoring, and as a foundation for future improvements which will deliver group-level management of storage quotas, and later Compute and Dask quotas.

One of the wonderful things about shared open source JupyterHub infrastructure is that it allows community members to share their projects with each other in ways that ensure the work can be fully experienced by the recipient, complete with fully executable content.

In Q2, we aim to improve the ability for hub users to build custom environments in their hubs, and later to easily share those custom environments with others, ensuring their entire toolchain is replicated in full.

Out-of-the-box Jupyter Book support #

We have been working on scoping and building a default JupyterBook implementation using the new MyST document engine, aiming to deliver a default set of tools for authoring and sharing documentation, customizable landing pages and interactive training materials out of the box with new hub deployments.

In Q1 we delivered improvements to the JupyterBook launching interface to allow for automatic hub type detection, as well as landing page components, theming capabilities, galleries and more. We aim to complete this work in Q2.

A better onboarding experience for our communities #

As more communities in the research and education space join the 2i2c community network, it’s important for us to be ready to deliver the best value we can for them at scale. To that end, we’re streamlining the processes we use to onboard our communities, improving the touchpoints through which we engage with them when they join our community network, and ensuring we create opportunities to better understand their needs in order to set them up for success with their hubs right from the start.

Improve and formalize the services we deliver to our communities #

Together with an improved onboarding experience, we aim to improve how we deliver other key services to our communities, including expert consulting, hub management, and technical support, with the aim to offer more scalable, high-value services to address the needs of our communities in a sustainable way.

Some of the goals of this service revamp will include improving triaging of support tickets, shortening our issue response time, and providing our community champions with dedicated expertise on subjects including open source science and tools, community participation in open science, fundraising and grantsmanship co-creation, engineering consultancy and more.

Another update coming in Q3 #

We’ll use this blog post as an informal roadmap of our product goals for the quarter, striving to advance as many of the outlined areas as possible. During our Q3 planning, we’ll reflect on the achievements made in line with this initiative and share a progress update with our community. Keep an eye out for more details!

Acknowledgements #

Our strategic and organization-level work is supported by a grant from The Navigation Fund and fees from our member organizations.

Our product highlights from Q2 2025

Wed, 16 Apr 2025 00:00:00 +0000

These describe the major service improvements that we rolled out in Q1 2025. See this blog post describing our product enhancement goals in Q1 2025 for the targets we intended to hit this quarter. Below is a brief description of what we accomplished.

User storage quotas #

A key part of 2i2c’s service is making the cloud safe to try. One of the biggest concerns from our communities is that their cloud costs will be unexpectedly high. This quarter we decided to make cloud storage a bit safer. Storage can get expensive, especially when a user accidentally downloads a particularly large file - they may not even realize that doing so incurs an extra cost. For this reason, we added the ability to limit user storage on JupyterHubs:

Enforcing per-user storage quotas with jupyterhub-home-nfs

We initially deployed this feature on our AWS hubs, and followed up by deploying it on GCP hubs as well. Any community with a hub on AWS and GCP now has the ability to limit the storage that their users receive, greatly increasing our communities’ control over their costs.

Enforcing per-user storage quotas now available on GCP

Thanks to DevSeed for collaboration on this work, in addition to the NASA VEDA project for funding this effort.

Automated backups for GCP hubs #

Another concern communities have is “what happens if something breaks and I lose data?” Cloud providers offer a number of ways to recover from disasters like this, and we did some work enabling this for GCP so that communities have disaster recovery options available to them.

Announcing backups for GCP-hosted hubs!

Deploying JupyterHub on public infrastructure #

Deploying Kubernetes and JupyterHub on publicly-managed infrastructure could be an excellent way to reduce the perceived risk of depending on large tech companies for their key workflows, and potentially reduce costs by using federal infrastructure that can be paid with special grant funding. We built team expertise in deploying and running JupyterHub and BinderHub on JetStream2, and have promising results that we hope to build upon in Q2.

Open infrastructure for collaborative geoscience with Project Pythia: Learning how to deploy a BinderHub on Jetstream2

Thanks to Jetstream2 for an ACCESS allocation, to Julian Pistorius for technical support, to Project Pythia (NSF award 2324302) for funding this work, and to Andrea Zonca for preliminary work on Kubernetes deployments on Jetstream 2.

Upgrading to the latest JupyterHub version #

We upgraded all of 2i2c’s community hubs to use JupyterHub 5.0. This brings in a bunch of security improvements, bugfixes, and enhancements. You can find links to the highlights and changelog in our blog post below.

2i2c hubs now run JupyterHub 5.0

Reproducible environments for community members #

Finally, we did a bit of product brainstorming around enabling communities to bring their environments with them when they publish. We are interested in making it easy to re-use a community’s hub infrastructure to provide the reproducible environments needed for publishing or communicating their work externally. Here’s a brief brainstorm for what this could look like:

Towards frictionless, portable, and sustainable reproducibility with Binder

Improving the UX and flexibility of community documentation with MyST #

To provide our communities with quality documentation that sits alongside their Hubs, we have been working on improving MyST to allow for a more flexible and usable document authoring experience, with improvements to landing page layouts, theming, galleries, button layouts, and project launching. We’re aiming to deliver a complete MVP covering our communities’ most requested features by the end of Q2.

Acknowledgements #

Our strategic and organization-level work is supported by a grant from The Navigation Fund and fees from our member organizations.

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.

Simplifying and speeding up Binder builds with BuildKit

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

Chris and Yuvi recently wrote a blog post on the Jupyter blog about a recent experiment to significantly reduce the cost of running a node on the mybinder.org federation.

Acknowledgements #

Project Pythia provides support for some of our work with the Binder project.
JupyterHub for working with us to get this new node deployed for mybinder.org.

Enforcing per-user storage quotas now available on GCP

Tue, 25 Feb 2025 14:18:04 +0000

Building upon our previous work developing per-user storage quotas for our AWS infrastructure, we are pleased to announce that this feature is now available for GCP-hosted hubs!

To provide this feature on this vendor, we have updated our infrastructure provisioning system to create persistent disks, and enable automatic backups of the disk for disaster recovery purposes. However, the systems we had already developed for AWS, such as jupyterhub-home-nfs and our alerting system through Prometheus Alertmanager, are vendor agnostic and work right out of the box with the new architecture!

If you would like to try this feature on your 2i2c-managed JupyterHub, please get in touch.

Acknowledgements #

This project was developed and deployed in collaboration with Tarashish Mishra from Development Seed, funded through the NASA VEDA project.

Open infrastructure for collaborative geoscience with Project Pythia: Learning how to deploy a BinderHub on Jetstream2

Wed, 12 Feb 2025 00:00:00 +0000

Project Pythia and the “Jupyter notebook obsolescence” problem #

Project Pythia provides educational resources for essential software tools that enable open, reproducible and scalable geoscience, such as the Pangeo stack of packages (Xarray, Dask, Jupyter). Their Cookbooks are crowdsourced, community-curated, and open-source collections of Jupyter notebooks that demonstrate how to use these tools for cloud-native, geoscientific workflows (see our Project Pythia Cookoff blog post). However, “Jupyter notebook obsolescence” is a common problem: tutorials that were created a few years ago may no longer work due to changes in the software ecosystem and hampers the reproducibility of scientific results. A reproducible execution environment and the infrastructure to support it are essential for the long-term sustainability of these educational resources.

Leveraging NSF-funded cyberinfrastructure for BinderHub #

A BinderHub allows users to dynamically create custom computing environments from Binder-ready repositories containing computational notebooks and configuration files that describe the software environment required to run them. A public Binder service exists at mybinder.org (see our blog post about joining the mybinder federation 🎉) and is a successful example of how open cloud infrastructure can accommodate reproducible execution environments.

The resources available on such a public service are limited therefore 2i2c, together with Project Pythia, have been exploring how to deploy a BinderHub backed by larger resources from the NSF-funded cloud computing platform Jetstream2. This allows for larger simultaneous user loads, such as at workshops, as well as access to more powerful distributed and parallelized workflows required to process large geoscientific datasets, under a persistent resource allocation.

Learning how to deploy on OpenStack #

Jetstream2 uses OpenStack in order to manage pools of compute, storage and networking resources, and for our purposes we specifically make use of OpenStack Magnum Cluster API driver to manage Kubernetes for our deployment.

Cluster API needs a CAPI management cluster in order to manage other Kubernetes clusters, called workload clusters. On Jetstream2, this management cluster is gracefully created and operated by the Jetstream2 team, which means that the only task to worry about is creating and configuring the workload cluster.

For the workload cluster we used the Openstack Terraform provider to define the cluster template, the cluster itself and the node groups in a reproducible way.

After the cluster infrastructure was successfully created on Jetstream2, thanks to the 2i2c hub infrastructure being cloud agnostic as well, deploying BinderHub to Jetstream2, was a seamless experience and it was no different than on other cloud providers that we already supported.

We also learnt about some limitations of the Openstack Magnum driver project, which were expected given it being a relatively recent project, slowly being adopted, but they were all reported upstream and hopefully will soon be fixed.

Acknowledgements #

Jetstream2: Explore ACCESS allocation and Julian Pistorius for technical support
Thanks to Project Pythia for funding and collaborating with us on this work.
Andrea Zonca for preliminary work on Kubernetes deployments on Jetstream 2

Towards frictionless, portable, and sustainable reproducibility with Binder

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

Last December I had an opportunity to discuss the current and future state of the open publishing ecosystem at a workshop hosted by HHMI¹. While 2i2c doesn’t primarily focus on “publishing” workflows, we do support communities on a journey that often leads to publishing, and we make choices about technology in our community hub platform that can support different kinds of publishing outcomes.

After listening to folks across the open science and publishing ecosystem, I noticed a common challenge:

Publishers care about reproducibility of computational narratives and the interactivity that computation can provide.
But they lack the capacity to manage computational infrastructure in a way that is flexible enough for all of their authors.

This post is a reflection on how ecosystems like Jupyter and managed community hubs could solve some of these challenges.

A community experiment to provide reproducible environments for published pre-prints #

Many of 2i2c’s communities already care about reproducibility and sharing their computational narratives. That’s one reason that we’ve been improving reproducible environment sharing with Binder, integrating Jupyter Book into our community cloud platform, and supporting the mybinder.org federation.

However, communities often want to publish rather than just share. Publishing is more structured, invites particular kinds of feedback, and requires more Quality Assurance. There’s a huge ecosystem of publishers and services that support formal publishing, and they ensure things like discoverability, long-term archivability, versioning, peer review, DOI referencing, etc.

We recently piloted running a BinderHub for Biorxiv publications with the Loren Frank lab and HHMI, and found this to be a nice proof-of-concept. While the “published article” lives on Biorxiv, the computational infrastructure and environment is provided by a BinderHub (in this case managed by 2i2c, but anybody could manage a hub in this way).

The Biorxiv Binder pilot workflow. An author used a 2i2c-managed BinderHub to generate a reproducible environment for their paper. They included a link to this environment in the abstract. Readers could click this link, and be taken to a fully interactive environment to explore the ideas in the paper and reproduce its computation.

This was a nice proof-of-concept, though I think that broader adoption of this type of workflow would require a deeper connection between publisher workflows and open source communities.

Could we enable communities to “bring their computational environments with them” when publishing? #

Currently, a community’s computational environment and data are not accessible to publishers. Could we relax this by allowing JupyterHub and Binder to be re-used by external services like publishers? This could allow a community’s hub to act like an external service for reproducibility that could be used by one of the many publishing platforms out there. It would require making improvements around a few different areas of Jupyter:

JupyterHub and BinderHub would need improved workflows around external authentication so that services could easily request kernels from a hub.
Jupyter Book and MyST would need the ability to power computation on a page from a variety of computational back-ends, potentially defined by a user (e.g., via Thebe and some UI design in Jupyter Book).
Jupyter Lab and other user interfaces may need improved ways for defining and sharing their environments and their content to use tools like Jupyter Book and Binder.

We’d also need integration work for the various publishers to leverage this technology for their infrastructure. This is a significant lift - a lot of publishers use very old and bespoke technology in their systems. However, there’s also hope that a subset of the publishing ecosystem is ready to try things like this.

There are many publishing organizations innovating with open source #

I learned that there’s a lot of interest in innovating around publishing workflows, as well as building on top of open source communities and standards. We don’t need the whole industry to move at once (it won’t), but we do need a critical mass of organizations who are interested in innovating. This might be possible with more publishing-focused products that integrate heavily with open source.

For example, Curvenote is a publishing and communication platform that builds heavily on top of the Jupyter and MyST ecosystems. They co-lead many of the open source projects they use in their platform. Curvenote builds largely around the MyST Markdown document engine, which means they could more easily integrate improvements around Portable Computation in the Jupyter ecosystem.

I hope that the broader publishing ecosystem moves in this direction. Because Jupyter is largely based around open standards and protocols, it should be possible for publishers to leverage the BinderHub API and the Reproducible Execution Environment Specification to integrate computation that powers their reproducible articles. This would allow a community’s members to connect their hub’s reproducible environment with each published article. Something like the figure below.

Publishers could re-use the computational environments from a community’s hub, resulting in a de-duplication of infrastructure and effort, and bridging the gap between where a community does its work, and where it submits new ideas for publication. (note these are hypothetical for now, but we think publishing platforms like these are a good starting point!)

Integrating with publishing in this way would allow communities to leverage their pre-existing infrastructure as part of their scholarly workflows. If a community had their own capacity to manage Binder infrastructure they could do so, or they could use a service provider like 2i2c to manage it for them. This would distribute the responsibility of infrastructure management to those who are in the best position to do so - the communities that do the work.

How could we sustain the cost of running computation for published articles? #

This raises an important question: how would you sustain services like these? Communities are already nervous about the cost of computation for their workflows. Public services like mybinder.org are free and accessible, but not scalable, nor suitable for complex or mission-critical workflows². Would community stakeholders pay for privileged access to BinderHubs that could reproduce and share their computational narratives? Would publishers be willing to pay a percentage of the cloud and management costs associated with reproduction? Could we use this to sustain a larger public service like mybinder.org?

We don’t have any answers yet but we’re keen to try. Our colleague Jim Colliander recently explored some of these ideas in a talk recorded for AGU 2024.

A talk from 2i2c team member Jim Colliander discussing the right to reproduce computational ideas, the importance of enabling frictionless reproducibility, and how we might sustain such a service.

One thing seems clear - there is an imperative to make reproducibility and interaction frictionless. This is both to ensure the scientific integrity of the work being done, and also to make computational ideas more accessible to the world. Technologies and service partnerships like these can help ensure the broader community’s right to reproduce the work of others.

Exploring Frictionless Portable Computing at 2i2c #

2i2c often plays a role in bridging user communities and open source communities through cycles of development and collaboration, perhaps we could do the same for the publishing community. We’d like to explore some tooling improvements that lay a foundation for these workflows, and will report back on our experiments in the coming months.

If you are interested in collaborating, please reach out. We’d love to hear from organizations from the scholarly publishing community to understand where these ideas have holes or need significant new development. I’d also love feedback on sustainability models to ensure these services can be relied on as part of the publishing ecosystem. In the meantime, hopefully these ideas serve as an inspiration for what is possible, and where we might be heading with 2i2c’s service and the broader publishing ecosystem.

Acknowledgements #

HHMI for organizing and hosting this workshop.
the Jupyter Book community for their collaboration and feedback on these ideas.

There’s a follow-up meeting for those who are interested. ↩︎
The costs associated with running mybinder.org have historically been shouldered by donations from organizations such as OVH, Google, GESIS, Curvenote, and now 2i2c. These donations are not guaranteed, and do not scale directly with the number of users. ↩︎

Announcing backups for GCP-hosted hubs!

Fri, 07 Feb 2025 13:08:22 +0000

2i2c are pleased to announce the development and deployment of automated backups of home directories on GCP-hosted hubs!

We have developed the gcp-filestore-backups project that regularly creates backups of JupyterHub home directories for disaster recovery purposes. The project is a Python wrapper around the gcloud tool to regularly request backups be made of the Filestore hosting JupyterHub’s user home directories, by default on a daily basis. The script also manages retention of these backups by checking how recently the last backup was made, and the age of existing backups, by default deleting any backup older than 5 days.

Having these backups enabled means that, in the unlikely and unfortunate case of data loss or corruption, we can reinstate the home directories of the hub to a relatively recent state that is at a maximum of 1 day prior to the incident.

We have deployed gcp-filestore-backups to all our GCP hubs presently running, with a retention period of 2 days. If you would like to discuss this further with us, please get in touch!

As ever, this project has been developed openly in line with our Right to Replicate so you can deploy it against your own infrastructure!

Our product goals for Q1 2025

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

This quarterly post is coming out a little bit late - our goal was to post this in early January, but the year has been more complicated than we bargained for :-)

Over the past year, 2i2c has made team-wide efforts to improve our product planning and delivery. A key part of this is re-organizing an integrated Product and Services team that brings our strategic planning, engineering, and service delivery closer together. We’ve also built systems for planning and measuring progress within the P&S team, and a product initiatives system for planning major work.

Our goal is to organize our product work around a small set of core themes to help us focus and prioritize. As part of this, we’d like to share platform enhancement goals for roughly each quarter. These are not guarantees, but we share them to be transparent about where we think we can be the most impactful in the next few months. Here are the major areas we hope to improve 2i2c’ platform in Q1 2025.

Expand access to cloud providers and improve data safety #

One of 2i2c’s goals is to showcase the ability of open infrastructure to be deployed on a variety of infrastructure proiders. This includes user-facing features, as well as guardrails and safety measures.

In Q1 2025 we are working to bring closer feature parity between hub deployments on AWS and GCP, while enabling disaster recovery with automated home directory backups.

Explore deploying on public infrastructure providers #

Many communities in research and education are interested in leveraging publicly-owned infrastructure providers like JetStream 2 and the National Research Platform. While 2i2c has historically focused on commercial cloud due to their highly-reliable Kubernetes platforms, we think it is important to explore publicly-owned infrastructure providers as well.

In Q1 2025 we’ll begin this expansion by deploying JupyterHubs and BinderHubs on JetStream 2, which will give communities access to publicly-funded computing resources. We will use this experience to decide whether it’s sustainable for us to deploy on this and other publicly-owned infrastructure providers.

Enable enhanced community knowledge bases with Jupyter Book 2 #

A key theme we aim to enable is sharing within and between community hubs. This is a critical part of the data science workflow because it allows people to collaborate on the same ideas, and build on top of one another’s ideas. An early target for this is to facilitate lightweight sharing of computational content so that community members can learn from one another more effectively.

In Q1 2025 we want to help get Jupyter Book 2’s beta released, and provide an out-of-the-box configuration for our communities to use it with their hubs. This includes adding landing pages and better integration with JupyterHub via launch buttons to create a more seamless experience between documentation and interactive computing.

Another key aspect of sharing is sharing the computational environment as well. This would allow communities to not only sheir their content, but also live infrastructure that allows others to reproduce and interact with their work. We think that investing more time into imiproving and deploying BinderHubs (the technology behind mybinder.org) will help us learn more about how to make this a reality.

In Q1 2025 we plan to grow our capacity to deploy BinderHubs across multiple cloud providers. This will allow hub users to build their own Binder environments on the fly and make it possible to share these environments with others, enabling better reproducibility and collaboration within communities.

Give communities more visibility and control over their hub setup and costs #

Perhaps the biggest perceived risk to using cloud infrastructure is the possibility of runaway costs. Community leaders are often nervous that something unexpected will happen and they’ll have to foot a giant bill at the end of the month. We think that reducing this risk is a key way to make cloud infrastructure safer and more useful for research and education communities.

In Q1 2025 we are aim to add more visibility into hub usage and more controls over resources via quotas. This will allow more fine control over resource budgets such as CPU, memory, and storage. We’ll also work on assigning users to groups, allowing communities greater control over resource allocation across large user bases.

A key goal of our Navigation Fund grant is to streamline ourselves into a few repeatable, scalable service offerings at different price points. This will allow us to more easily support new communities and provide a more consistent experience for users.

In Q1 2025 we’d like to define a starting point that we can begin to iterate on. We’ll define a new set of pricing based around a tiered service model, and decide on an initial set of features and services to include with each. Our goal will be to have something defined quickly so that we can iterate a few times with community feedback before the quarter is over.

Standardize our community support services #

Finally, we’ve audited our ongoing support practices and realized that we aren’t always delivering them in an efficient way. We often share the same information one-on-one conversations, and aren’t effectively leveraging our community network to support and learn from one another. We’d like to standardize and boost the scalability of our support services.

In Q1 2025 we want to explore how we can more scalably and efficiently provide hands-on guidance, expert co-creation, and support to communities. Our goal is to define a starting point for these services so that we can offer this support in a sustainable way and begin to learn from our experiences. We also want to build a mechanism for scoping (and pricing) additional capacity that is needed beyond standard community services.

Another update coming in Q2 #

Our aim is to use this blog post as a guide for the quarter, and to make progress in as many areas above as we can. As part of our Q2 planning process, we’ll provide a retrospective on the accomplishments we’ve made towards this effort, and will provide an update for our community on our progress. Stay tuned for more!

Acknowledgements #

Our strategic and organization-level work is supported by a grant from The Navigation Fund and fees from our member organizations.

2i2c joins the mybinder.org federation with a cheaper and faster way to deploy Binderhub

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

If you’re interested in supporting mybinder.org with cloud resources, financial resources, or human resources, please see the

Support Binder page for how you can help.

tl;dr: The 2i2c team is joining the mybinder.org federation with a single-node BinderHub instance at 2i2c.mybinder.org. It should be much cheaper to run than auto-scaling Kubernetes clusters, and might be a good way to support mybinder.org more sustainably. For questions or comments, join this Jupyter Zulip thread.

mybinder.org is a massive public service for creating and sharing reproducible computational environments. It is managed by the JupyterHub team and members of the mybinder.org federation. One challenge in running mybinder.org is identifying cloud credits or financial resources to support the cloud infrastructure that runs the service. Two years ago, Google stopped supporting mybinder.org federation with cloud credits, and last month the federation lost more capacity, leaving only GESIS and OVH as remaining federation members¹. This makes mybinder.org less reliable, slower, and generally less useful to the world.

The landscape of cloud infrastructure technology and services has changed considerably, and we think that there’s a way to deploy BinderHub instances with lower costs and less complexity. We’ve accomplished this by deploying a single-node Kubernetes cluster on a VM provider that is much cheaper, now running at 2i2c.mybinder.org. This both relieves Binder’s short-term capacity shortage and may provide an easier pathway for others to support the project in the future.

Below, we’ll describe what has changed to enable this, what we’re deploying, and what the impact should be.

Cloud infrastructure has become cheaper and more commodified #

A key theory of mybinder.org (and 2i2c) is that commercial cloud infrastructure will be commidified over time – what begins as cutting-edge functionality will become commonplace and offered across all cloud providers. As a result, costs will go down over time. Abstractions like Kubernetes will allow you to easily migrate workflows and infrastructure between cloud providers. As a result, you’ll be able to easily follow those costs where there are better options. That’s essentially what is happening here.

There are two key changes that make it much easier to deploy a BinderHub instance at a fraction of the cost:

First, Kubernetes has matured and become easier to deploy. When mybinder.org started, it was using the cutting-edge of Kubernetes functionality. This meant that we needed to use cloud providers that provided a managed Kubernetes service to deal with this complexity. A managed Kubernetes offering tends to be expensive, offered by only a few cloud providers, and thus raises costs across-the-board for the provider that offers it.

However, this was almost a decade ago, and Kubernetes has become both more functional and more stable. There are now many more ways of running Kubernetes, especially for simpler workflows that don’t require autoscaling. In the last several months, we’ve been experimenting with single-node Kubernetes workflows via K3s². K3s is a lightweight Kubernetes distribution that is much easier to deploy and manage. It’s designed for things like edge computing and low-resource environments, and it can be deployed with a single script!

By running a Kubernetes cluster on a single node, we don’t need a “managed Kubernetes service”, which means we can choose from a much larger pool of infrastructure / cloud providers. If all we need is a running VM, this is something the tech industry has been doing for decades.

Second, Managed Object Storage services have more open source options, and are more commodified and cheaper. In addition to Kubernetes, the other thing that BinderHub needs is a way to store and retrieve images for the environments that it builds. This also used to be a fairly complex problem, and thus required managed solutions from cloud providers that charged a premium for their service. However, a number of open source object storage solutions have emerged and made it much easier for providers to support this workflow.³. Because these are open source, infrastructure providers can provide managed object storage at a fraction of the cost.

Because of these two things, we’ve learned that we can run a BinderHub instance on a single VM from a much larger pool of infrastructure providers. This means we should be able to run BinderHub instances at a fraction of the cost.⁴

Deploying BinderHub on a single-node VM is cheaper and simpler #

Last week, we deployed 2i2c.mybinder.org, a single-node Kubernetes instance on Hetzner cloud using K3s. This will run on a single node VM, with a Kubernetes instance that is entirely managed by us, and with managed object storage from Hetzner. Compared to other cloud providers, it is around 5x cheaper per month.

Comparison of rough monthly costs across different cloud providers for similar VM instances. These are rough estimates based on cloud provider pricing pages for an on-demand VM with around 190GB RAM. Pricing pages: Hetzner Cloud ~$300, Microsoft Azure ~$1,300, Google Cloud Platform ~$1,500, Amazon Web Services ~$1,600.

Running a single-node Kubernetes instance will be a cheap and effective way to handle a lot of mybinder.org’s capacity needs. Because it’s a single node cluster, there is no auto-scaling (one reason it is so cheap), which reduces a lot of the complexity we’ll have to manage. These are acceptable tradeoffs for a service like mybinder.org, which runs entirely ephemeral sessions with very limited resources and no promises about uptime, persistence, etc.

You might be wondering: “I thought Kubernetes was supposed to save money.” Normally, running Kubernetes for scalable workflows does save costs because you can scale infrastructure to match your capacity needs. Without scaling, you’d need to provide a VM that can always handle your maximum capacity needs (and pay for the costs the entire time). With Kubernetes, you can request and remove nodes to grow your capacity as-needed (and save money doing so). It looks something like this:

The cost difference between a single large VM vs scalable nodes. Given variable usage over time, kubernetes allows you to scale your cost up and down with need, which is more efficient than paying for a single VM that can withstand your maximum capacity.

However, there is a built-in cost you pay when you use a service that provides managed Kubernetes. Managed Kubernetes services are complex and expensive, and this is reflected across-the-board in the provider’s costs. What if we could achieve the same outcome with a much simpler cloud offering like a single VM?

We did a bit of research and discovered that the Kubernetes and object storage landscape has indeed evolved significantly since the early days of mybinder.org. For example, Hetzner is a cloud provider that has been around for a long time. It has single-node VMs that are about 4x cheaper than their counterparts in Google Cloud or AWS, and provides managed object storage that uses MinIO in a cost-effective way. Using K3s, we can run a lightweight, single-node Kubernetes runtime on this node, and deploy a BinderHub with the same infrastructure as any other BinderHub federation member.

By our estimate, we could fit around 400 simultaneous sessions on mybinder.org (because each session uses very few cloud resources). This is already the majority of mybinder.org’s capacity needs, and at a much lower cost than using a scalable Kubernetes cluster. The cost picture looks something like this:

If your single VM is much cheaper, it might still be the cheapest option. In the case of a Hetzner VM, it has roughly the same capacity as another cloud provider’s VM, but at 1/4 of the cost.

2i2c.mybinder.org now serves 70% of the mybinder.org federation #

About a week ago, we launched 2i2c.mybinder.org running via the methodology we described above. We intended to run this as a longer experiment, but believe that it has already proven useful enough to consider “ready for production”. We recently increased 2i2c.mybinder.org’s load to 70% and will continue to monitor its performance over time. Here’s a plot of where each mybinder.org session has been run over the past ten days - you can see the moment where we turn on 2i2c.mybinder.org to the left:

Sessions launched on mybinder.org’s federation over the past ten days. The yellow area represents sessions run on 2i2c.mybinder.org. They now make up the majority of launches on mybinder.org. Prior to this, gesis.mybinder.org was the only remaining federation member.

For now, 2i2c is sponsoring a max of €350 a month (with some currency conversion noise) to run this service. We’ll provide in-kind labor to run this node, and treat it as an organizational investment in supporting open science, as well as learning new Kubernetes and cloud infrastructure workflows. We’re going to use funds recovered from communities in our community hub network, along with in-kind labor to build out this experiment.

In six months, we’ll evaluate how much effort it was to run this node for mybinder.org, whether it meaningfully helped with mybinder.org’s capacity, and whether it was sustainable for us from a time and labor perspective.

Others can join the mybinder.org federation using this approach as well #

We think that developing this single-node BinderHub workflow will make it much easier for others to join the mybinder.org federation, because it lowers the infrastructure and skills complexity needed to join. Here is a brief guide we’ve written for deploying a BinderHub with K3s. We are helping a few interested organizations deploy their own BinderHubs in this way in order to validate the idea, and are hopeful that this makes it much easier to grow mybinder.org’s capacity via new federation members.⁵

We’re excited to experiment with new ways to support mybinder.org. We think this is an excellent example of how open standards and technology lead to cloud workflows with lower costs and more flexibility. We also think it’s a good example of how it is valuable to have organizations aligned with open science (like 2i2c!) acting in this space. If you have any questions or comments, please join this Jupyter Zulip thread

Anybody want to fund this? #

If you’re interested in making open science infrastructure like Binder more scalable and sustainable, we’d love to find more resources to both sustain this node and cover more development time to run this experiment. Feel free to reach out here.

If you have access to VMs and object storage, and are interested in running a mybinder.org federation member using the methods described here, check out our brief guide for deploying a BinderHub with K3s.

If you’re generally interested in supporting mybinder.org with cloud resources, financial resources, or human resources, please see the Support Binder page for how you can help.

If you’re interested in supporting mybinder.org with cloud resources, financial resources, or human resources, please see the

Support Binder page for how you can help.

Acknowledgements #

Thanks to the JupyterHub community for helping us set up this new node.
Thanks to our member communities whose fees currently support this work.

Many thanks to GESIS and OVH for their continued support of mybinder.org, your contributions to keeping this service running are critical! ↩︎
thanks to Carl Boettiger for collaborating on this with us! ↩︎
One example is MinIO, which is used by Hetzner to provide managed object storage for their single-node VMs. ↩︎
For example, Hetzner provides a single-VM option with managed object storage that is roughly 25% of the cost of other cloud providers that also offer autoscaling Kubernetes services. There are many other infrastructure providers who could be used in this way. ↩︎
We’re also experimenting with a few other ways to reduce the complexity and costs of running a BinderHub even further, but will have more on that later as we learn more :-). ↩︎

Enforcing per-user storage quotas with `jupyterhub-home-nfs`

Tue, 28 Jan 2025 09:57:28 +0000

When sharing a storage disk between users, as is usually the case in a JupyterHub deployment, it is important to put in guardrails so that one user cannot eat up the whole storage capacity from the rest of the users. To this end, 2i2c in close collaboration with Development Seed have developed the jupyterhub-home-nfs project which is a Helm chart that permits enforcing per-user quotas on the storage space.

Note that this feature is currently available to AWS hosted hubs only and will be rolled out to other cloud providers in the future.

Under the hood, the Helm chart runs NFS Ganesha as an in-cluster NFS server, backed by XFS as the underlying filesystem. Storage quota is enforced through XFS’s native quota management utility xfs_quota.

Since this feature moves our infrastructure away from managed filesystems (such as AWS’s Elastic File System) that cannot support per-user storage quotas, we have also developed monitoring and alerting mechanisms that will let us know when the disks are getting full, and automated back-ups for disaster recovery.

If you would like to try this on your 2i2c-managed hub, please get in touch.

This project can also be used with any Kubernetes-based JupyterHub, as per our Right to Replicate policy, so please try it out on your own deployment and let us know what you think!

Acknowledgements #

This project was developed and deployed in collaboration with Tarashish Mishra from Development Seed, funded through the NASA VEDA project.

Designing for an ecosystem: a case study in cross-project open source contribution

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

A key challenge in the open source space is that projects are often independent and autonomous, with relatively few formal ways to collaborate and coordinate efforts. While this usually isn’t a big deal, it means that there is a missed opportunity to grow the impact of an ecosystem because it requires coordinated development among multiple stakeholders within it.

This is one of the reasons we created 2i2c’s open community hub platform. By deploying a single platform that utilizes entirely open infrastructure that we contribute back to, we have visibility over a variety of projects along with the need to combine them together for a specific end-user outcome. One-such development scenario recently came up involving Jupyter Book 2 and JupyterHub.

Allowing readers to “bring their own Binders” #

We’ve recently been working to integrate Jupyter Book 2 workflows with our community hubs for a more seamless experience (for example, having book pages link back to interactive cloud sessions that allow users to interact with the content). We imagine a network of Jupyter Books that all build upon the same core infrastructures (JupyterHub, Binder, etc) for cloud-based computing. Our hope is to allow a user to bring their own Binder with them so that they can interact with another book’s content with their own cloud infrastructure. For example:

A student with access to binder.myuniversity.edu could read a Jupyter Book created by a professor at otheruniversity.edu.
The Jupyter Book is defined with a Binder specification that has a recipe for re-building the environment needed to run te book’s content.
From the professor’s book, the student can choose to launch an interactive Binder sessions on their university’s Binder, allowing them to interact with the book’s content on their own infrastructure.

We want a workflow like this to be as seamless and un-complicated as possible. We also want it to follow the same fundamental workflow as the nbgitpuller-based launch buttons. Along the way, we realized that we needed to coordinate development across Jupyter Book 2, JupyterHub, and BinderHub.

The three projects (Jupyter Book, BinderHub, and JupyterHub) that needed to work together to enable ‘bring your own binderhub’ workflows.

Getting Jupyter Book to discover Jupyter Hub #

As we began developing this workflow, we realized that there was a blocker in the JupyterHub and BinderHub ecosystem that needed to be fixed. We needed a way to ask a JupyterHub whether it had an unauthenticated end-point for service discovery. Basically, a way to ask a hub “what kind of hub are you, and how can we launch an interactive session on you?” Doing this is simple-enough - JupyterHub already has a way of reporting its version and application type, which allows us to infer how to launch interactive sessions. But, we hit a snag in an HTML context.

By default, JupyterHub disallows certain kinds of Cross-Origin Resource Sharing (CORS) requests, in order to restrict other applications from abusing a JupyterHub’s API. If you hit parts of a JupyterHub API from the command line, things work fine. But if you do the same thing via JavaScript from a website, the request is disallowed. This was a problem if we want Jupyter Book (a web application) to be able to make requests of JupyterHub’s API.

So, we realized that we needed to make an upstream contribution in JupyterHub in order to enable an interaction between JupyterHub and Jupyter Book. In this case, it was a relatively simple fix: allowing CORS requests for the specific API endpoint we needed (which is a very lightweight endpoint that is not vulnerable to security risks, and is broadly useful to make accessible)¹. That resulted in two PRs:

jupyterhub/jupyterhub#4966 allows CORS requests for the API that was needed for service discovery in JupyterHub.
jupyterhub/binderhub#1906 enables this workflow on a BinderHub so that its services can be discovered.
jupyter-book/myst-theme#503 adds new launch button functionality to Jupyter Book 2 that allows readers to bring their own Binder / JupyterHub links for launching. (this is what necessitated the above two PRs)

As a result of this upstream contribution loop, JupyterHub can now accept API requests at its “service discovery” endpoint, which means that Jupyter Book (and any other web application) can more easily learn about a hub’s capabilities and version.

We wanted to share this short vignette because it’s a good reflection of the kind of value that 2i2c tries to provide, given its role in helping to build and enhance networks of infrastructure, domain communities, and open source communities. In this case, we enabled a cross-project workflow that required knowledge of each project, and a vision for how they could be used together in a way that exceeded the sum of their parts.

We think there’s a lot more potential in these kinds of workflows, and are eager to continue our work to identify and enhance community-centric infrastructure for interactive computing.

Acknowledgements #

Thanks to the JupyterHub and Jupyter Book communities for collaboration and review on this work.

This actually required an interesting bit of team discussion that was much easier with a few 2i2c staff on the JupyterHub team. The original request from Angus was interpreted as opening up the entire hub API to external requests (which is a bad idea!) but we were able to quickly discuss this with the JupyterHub team to clarify that this was only about a very specific API endpoint. This is the kind of communication loop that often goes haywire when you have people contributing to a project without historical relationships to the project’s maintainers. ↩︎

2i2c hubs now run JupyterHub 5.0

Fri, 17 Jan 2025 00:00:00 +0000

We are excited to announce that all 2i2c hubs now run JupyterHub 5.0!

This is an upgrade that brings some exciting new features and improvements. Some of the highlights include:

The possibility to enable user-initiated server sharing
Authenticator-managed roles

Also, JupyterHub 5 will enable us to offer per-group shared directories in the future! Tracking Issue.

Checkout the JupyterHub 5.0 migration docs or the changelog for more details.

Announcing our formal commitment to open technology

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

In this post, we’re sharing our Commitment to Open Technology. It is focused on software licenses for reasons we’ll describe below. We hope that it clarifies what kind of licenses we’ll use, and assures our communities that we will not change our stance towards open source technology in the future. This ensures 2i2c’s long-term commitment to community-owned and open infrastructure.

Being a platform and service provider gives us a lot of power, and also introduces a potential source of lock-in for our member communities. While 2i2c’s organizational mission and culture are strongly aligned with open infrastructure, we believe it’s important to encode commitments like these in a formal way to provide both transparency and accountability to our member communities.

Our commitment to open technology #

Below we copy the original language of this policy from our Commitment to Open Technology:

Definitions of MUST, MUST NOT, SHOULD, MAY, etc are defined in RFC 2119

All engineering artifacts (code, documentation, etc) produced by 2i2c’s engineering team MUST be licensed under an open source license approved by a non-profit organization that is not 2i2c.
Open Source Projects originating at 2i2c, or stewarded by 2i2c, MUST NOT require a Contributor Licensing Agreement that includes Copyright Assignment to 2i2c.
The list of external organizations that define licenses we accept are
1. the Open Source Initiative
2. the Organization for Ethical Source.
Modifying (1), (2), or (3) MUST be done through a 2/3 majority vote of 2i2c staff.

What does this commitment mean? #

In plain language, here’s what this commitment means:

We’ll only use open source licenses that have been approved by standard non-profits that are broadly recognized by the tech industry.
For anything we build, we won’t require contributors to give up the rights to their contributions via CLAs, so that it is much harder for 2i2c to change our licenses in the future.
Changing this policy will require organization-wide agreement, and in the future we’ll give authority over this policy to a group of people representing our member communities.

Why are licenses and CLAs important? #

Many organizations claim to be committed to open infrastructure, while retaining the ability to change this commitment in the future when it is in their interests. A classic example of this is a “bait and switch” that looks something like this:

A company releases software under an open source license and professes to build an open source community around it.
However, they retain the rights to all of the code in their projects through a Contributor License Agreement (CLA) with copyright assignment. This generally means that contributors must give up the rights to their contribution in order to make that contribution.
Once their product has gained traction and it is in their interests, the company can change the license to whatever they wish (even one that is not open source) because they retain the rights to all contributions in the codebase.
They then leverage this new position as owners of a proprietary project to extract business value or grow their position in a market.

Think this sounds unlikely? Here are just a few recent examples of companies that have switched their license after many years of releasing their technology under an open source license:

We want to ensure our communities that 2i2c is not headed down this path, in order to give them confidence in treating us as a long-term service partner.

What does this change about 2i2c’s open source commitment? #

In short: nothing. These are already the principles that 2i2c was committed to from its inception, and already implied via our Right to Replicate. However, we wanted to make these commitments more formally in order to give ourselves more accountability to sticking with them, and to provide more transparency for our community members and stakeholders.

Who is this for? #

We imagine three audiences for this policy:

2i2c present and future staff who want to ensure that their organization remains committed to our open principles. This document provides a sense of psychological safety to have bold discussions about structuring our approach to open source.
Member communities and 2i2c stakeholders who need to have an understanding of the guarantees that we provide in order to trust 2i2c as a service developer and provider. This is similar to the effect our Right to Replicate has.
Open source communities who need to understand our long-term commitment and goals around open technology in order to trust as a peer and collaborator within open source communities.

We’d love feedback #

We hope that these ideas both clarify our intent and the reason that we think it’s important. We’d love feedback about early refinements to these principles in order to make them more effective, as well as ways that we can provide more community oversight and participation in evolving these policies moving forward. If you have any thoughts to share, please send feedback via e-mail hello@2i2c.org.

Acknowledgements: The creation of this policy and the rationale behind it was led by Yuvi Panda with feedback from 2i2c’s team. This blog post was co-written with Chris Holdgraf. Strategic work like this is supported by a grant from The Navigation Fund.

NASA VEDA & 2i2c Update for Q4 2024 (Oct-Dec 2024)

Tue, 07 Jan 2025 15:18:37 -0800

A non-exhaustive list of things 2i2c and Development Seed did with the NASA VEDA project last quarter!

Automated backups and alerting with `jupyterhub-home-nfs` #

Tracking Issue

jupyterhub-home-nfs is a young project to provide flexible per-user home directory limits on JupyterHub - an important feature for controlling cloud costs. Tarashish Mishra and Sarah Gibson have been leading this project for the last few months. Since we are moving away from AWS Managed EFS here, we had to do some work to recreate some of the benefits EFS gives us out of the box. During this quarter, we:

Set up automated backups so we can recover files in cases of disaster
Set up automated alerting (via prometheus and pagerduty) to know if our backing EBS device is getting full and we need to perform a manual intervention
Deployed this to a few other communities ( CryoCloud and NMFS Openscapes) to broaden adoption.

We will continue doing work on jupyterhub-home-nfs in the upcoming quarter! If this is functionality you are interested in deploying, please reach out to us to collaborate!

Enable users to dynamically build environments with `jupyterhub-fancy-profiles` #

Tracking Issue

We covered this more extensively in another blog post, so go read that!

This work in particular is a good demonstrator of 2i2c’s value - it started off with a grant from GESIS, and now with support from NASA IMPACT we are able to bring it to a lot of communities, not just the ones that funded it.

Ongoing work here will focus on improving the UX as well as better documentation so users can actually use it!

“Open in QGIS” from VEDA UI #

Tracking Issue

We had worked in the past with many communities in enabling QGIS on the Cloud, and this quarter we got closer to enabling a contextual ‘Open in QGIS’ button in the VEDA Dashboard! Here is a quick demo:

(This shows the workflow when user is already logged into the JupyterHub and had started the server)

You can play with this in this preview, although you need to have access to the NASA VEDA hub to fully try it out at this point.

Tarashish from Development Seed is again responsible for most of the work here, available in jupyter-remote-qgis-proxy. You can use it to create ‘magic links’ that will open QGIS in a desktop environment in your browser, and add a specific layer to it! Our hope is that this allows primarily GIS folks to better use tools they already are familiar with in cloud based contexts.

Other updates #

We participated heavily in an evaluation process for the authentication and authorization solution to be used across NASA VEDA! Tracking Issue
We are very close to rolling out JupyterHub 5.0 and associated changes across all our hubs, which will enable us to eventually offer per-group shared directories! Tracking Issue

Acknowledgements #

Thanks to the NASA VEDA project for thir ongoing support for this work.
Thanks to DevSeet for their collaboration and leadership on this project.

2i2c communities at AGU 2024

Mon, 09 Dec 2024 00:00:00 +0000

We are proud to share that several of 2i2c’s community partners are presenting their work at AGU 2024! In each case, 2i2c’s infrastructure plays a part in helping communities create and share knowledge, and grow their community. As an organization rooted in community-centric practices, we are particularly excited to see 2i2c represented “indirectly” at this conference, and to see ourselves as a supporting role enabling the impact of others.

Here’s a summary and links to all of the sessions. See below for a brief overview of seach one.

ED31G-2272 Breaking down the barriers to Open Science with Project Pythia #

Link to session

Hall B-C (Poster Hall) (Convention Center)

Abstract #

Project Pythia is an open access educational initiative established with funding from the U.S. National Science Foundation. Its mission is to help students and scientists enhance their skills and adopt best practices using the tools and technologies of open science. As part of the Pangeo community, Project Pythia primarily focuses on the Pangeo stack, which includes cloud computing, Jupyter technologies, GitHub, and various software packages in the Scientific Python ecosystem, centered around Xarray. Project Pythia offers a wide range of open access content, such as datasets, software, tutorials, and annotated real-world workflows presented in the form of Jupyter Books.

Project Pythia serves as a resource for scientists, promoting and fostering open science. Although it is not a scientific research artifact itself, the development of Project Pythia adheres to many best practices advocated by open science proponents. The Pythia team actively encourages community engagement and collaborates openly with scientists and technologists to create new content. All Pythia resources are freely accessible, and the project follows the FAIR principles (Findable, Accessible, Interoperable, and Reusable) for managing research outputs, including publications, data, and other materials. We support and facilitate open evaluation and peer reviews of content to ensure verifiability and trust. Lastly, we endeavor to openly discuss ideas, designs, and methods before implementation.

This presentation will provide an overview of Project Pythia’s extensive educational resources and share our experiences in applying many open science principles to develop this flagship training resource for the geoscience community.

Authors #

John Clyne - NSF National Center for Atmospheric Research (first author)
Drew Camron - University Corporation for Atmospheric Research
Orhan Eroglu - NSF National Center for Atmospheric Research
Robert Ford - University at Albany State University of New York
Julia Kent - NSF National Center for Atmospheric Research
Ryan May - University Corporation for Atmospheric Research
James Munroe - 2i2c / Code for Science and Society
Brian E J Rose - SUNY at Albany

ED31G-2277 PACE Hackweek: An open community keeping up with PACE #

Link to session

Abstract #

The NASA Plankton, Aerosol, Cloud, ocean Ecosystem (PACE) mission, while bringing NASA’s Earth System Observatory up to speed with aquatic, atmospheric, and terrestrial science capabilities, is also providing data records of the Earth System for the next generation of scientists to grow into. The goal of the PACE Hackweek, supported by the Ocean Carbon & Biogeochemistry program and hosted at the University of Maryland Baltimore County in August 2024, was to enrich and support the practice of open science by both emerging and established researchers. Cloud-compute resources for the event were provided by CryoCloud, a NASA funded collaboration between ICESat-2 and the International Interactive Computing Collaboration (2i2c) to provide cryosphere researchers with a shared JupyterHub. We, the hackweek mentors, were buoyed by the NASA Openscapes program and adopted its mantra of striving toward “a kinder science for future us.” Participants faced two novelties: the “firehose” of data from the PACE instrument array (a hyper-spectral imaging spectrometer, a wide-swath hyper-angular polarimeter, and a narrow-swath spectro-polarimeter), and the distribution of PACE collections through the NASA Earthdata Cloud (a first for the Ocean Biology Distributed Active Archive Center). We present our approach and the challenges undertaken to hold an in-person, social coding event with 45 participants that provided a collaborative, supportive launchpad for doing open science with PACE. All lectures and tutorials produced for the event are freely available for examination and reuse. Our results additionally include highlights from the demonstration projects pursued by event participants and results from two post-event, qualitative surveys. One anonymous survey gathered participant feedback that will inform plans for growing these 45 participants into a lasting, open community. A separate, anonymous survey recorded participant demographics in order to evaluate our efforts at increasing diversity within the community of PACE data users. Key points of discussion include participant views, informed by our event, on whether and how the NASA Earthdata Cloud is a significant resource for the practice of open science with PACE, and how a shared JupyterHub can further the practice of open science by the community it serves.

Authors #

Ian Carroll - NASA Goddard Space Flight Center; University of Maryland Baltimore County (first author)
Kelsey Bisson - NASA Headquarters
Sean Foley - NASA Goddard Space Flight Center; Morgan State University
Patrick Clifton Gray - University of Maine
Elizabeth E Holmes - NOAA Fisheries
Carina Poulin - Science Systems and Applications, Inc.; NASA Goddard Space Flight Center
Tasha Snow - NASA Goddard Space Flight Center; University of Maryland College Park
Guoqing Wang - NASA Goddard Space Flight Center; Science Systems and Applications, Inc.
Jeremy Werdell - NASA Goddard Space Flight Center
Anna Windle - NASA Goddard Space Flight Center; Science Systems and Applications, Inc.
Pengwang Zhai - Department of Physics, University of Maryland Baltimore County

IN13A-2147 Including more solutions and more solvers via actionable open science #

Link to session

Monday, 9 December 2024 13:40 - 17:30
Hall B-C (Poster Hall) (Convention Center)

Abstract #

If we’re asking people to change for open science, we must be willing to change ourselves. Internalizing this as individuals and institutions is critical - “to address our climate emergency, we must rapidly, radically reshape society. We need every solution and every solver” (Johnson & Wilkinson, All We Can Save).

Radically reshaping our society and including more solvers requires Earth scientists of all disciplines, across AGU, to work together in new ways. Many of these shifts can be considered Open science. They change how we work daily, not just the open products we produce. And for that, people need to consider themselves part of a team, let go of perfection and embrace a growth mindset to continually reflect and improve skills – no matter their job title. Further, open science requires all of us to see ourselves as leaders making small changes that collectively add up to a movement.

Openscapes is an open source approach to cultivating leaders and change makers. Openscapes’ flywheel approach intervenes and builds momentum through identifying mentors within organizations and mentoring teams curious about shifting to open science (Robinson & Lowndes 2022). Collectively, the Openscapes flywheel iterations have had a significant impact over the past five years across institutions like the federal government and academia that seem impossible to change. Through stories working with professional scientists over the past 5 years including at NASA, NOAA, Black Women in Ecology, Evolution, and Marine Science, and many universities, and open source software communities like 2i2c, Posit, Pangeo, and RLadies, we will share actionable insights for flourishing in the open science commons, and are interested in learning with and growing flywheel momentum further at AGU.

Authors #

Julia S. Stewart Lowndes - Openscapes, LLC (first author)
Ileana Faye Fenwick - Hampton University
Elizabeth E Holmes - NOAA Fisheries
Luis Alberto Lopez - National Snow and Ice Data Center (NSIDC), CIRES, University of Colorado Boulder
Erin Robinson - Self Employed

IN34A-01 Beyond Open Data: Ensuring True Accessibility for All (Invited) #

Link to session

Abstract #

The Earth Observation (EO) industry has seen rapid technological advancements alongside a massive increase in the number of private and public missions, leading to exponentially growing data archives. For publicly funded entities, this data is typically required to be freely available. However, open data does not always guarantee accessibility, and significant barriers remain for even the most advanced users. The stagnation in the use and adoption of open data can be attributed to several factors, including 1) challenges in unifying and maintaining metadata standards, 2) inefficiencies associated with legacy data formats, 3) a lack of training and resources for transitioning to cloud-based infrastructure, and 4) systemic social inequalities.

This talk will explore real-life examples of these barriers and highlight success stories that have emerged from partnerships largely originating within open-source communities which foster diverse connections between private and public entities including efforts like GeoZarr, pangeo-forge, Openscapes and 2i2c. While many advancements in improving the usability and accessibility of EO data have come from private efforts (i.e. Google Earth Engine), the shutdown of the Planetary Computer is a reminder of the need for publicly funded alternatives. The sustainability of open source projects will be addressed, with questions posed around reliable funding mechanisms as a means to ensure equitable development to address barriers and ensure accessibility for all. While this talk will be presented by one individual, it is the review and reflection of the work done by dozens of people across various organizations.

Authors #

Brianna Rita Pagán - NASA Goddard Space Flight Center; ADNET Systems Inc. Greenbelt (first author)

Introducing GeoLab - An EarthScope JupyterHub for Enabling Collaborative Cloud-Native Geophysical Data Analysis and Skill Development Workshops #

Link to session

Abstract #

The EarthScope Consortium manages NSF’s GAGE and SAGE facilities and makes all of its geophysical data available in a commercial cloud system. This enables EarthScope and the communities it supports to leverage the abundant computational resources and cost-effective benefits of adopting data-proximate workflows with direct access to large, analysis-ready geophysical data sets.

In recent years, JupyterHub environments have gained popularity with data enthusiasts for their ability to provide open access to powerful compute resources. As part of a broad effort to support communities with intuitive resources to quickly adapt their workflows to the cloud, EarthScope has partnered with 2i2c to operate a scalable JupyterHub environment in AWS that will provide equitable access to cloud compute resources for researchers, educators, and the general public. GeoLab, the EarthScope hub, is aligned with related open science initiatives to establish rigorous and transparent standards for reproducible, data-intensive workflows. In addition to promoting interdisciplinary and inter-institutional collaborative work between researchers in GeoLab, EarthScope is developing and hosting workshops that can support both in-person and asynchronous learning modules that will train users how to utilize these new resources and transition their work to the cloud. We are excited to invite all geophysical data users to participate in the vigorous growth of this new platform and collaborate with adjacent open-science compute hub initiatives.

Authors #

Robert T Weekly - EarthScope Consortium (first author)
Tammy K Bravo - EarthScope Consortium
Jerry A Carter - EarthScope Consortium
Tim Dittmann - EarthScope Consortium
Alex Hamilton - EarthScope Consortium
David Mencin - EarthScope Consortium
Chad Trabant - EarthScope Consortium
Sarah Wilson - EarthScope Consortium

Link to session

Abstract #

Project Pythia is the flagship education and training initiative of the Pangeo community. Pangeo has advanced transformative platforms and paradigms for “Big Data” geoscience in the cloud; Pythia is creating on-ramps for new users with open, interactive learning resources centered on Python in the geosciences. Pythia is now building a vibrant community-owned clearinghouse of accessible, reusable, and reproducible tutorials and exemplar workflows in the cloud known as Pythia Cookbooks.

“Cookbooks” imply collections of recipes for transforming raw ingredients (publicly available data) into scientifically useful results. Based on Jupyter notebooks, Cookbooks are explicitly tied to reproducible computational environments and supported by a rich cloud-based infrastructure enabling collaborative authoring and automated health-checking – essential tools in the struggle against the widespread notebook obsolescence problem. Cookbooks are hosted on Pythia’s searchable gallery and nurtured by a growing community of open science enthusiasts from across the geosciences. The Pythia Cookbook gallery is essentially a crowd-sourced, community-curated collection of best practices for data analysis and visualization.

Here we will outline the stack of technologies and infrastructure enabling cookbook creation, collaboration, testing, publication, and interactive deployment, and how these are used in service of building an inclusive participatory community. We will discuss existing technical and social hurdles for contributors, as well as new infrastructure developments in collaboration with the Executable Books Project that are reducing these hurdles.

Authors #

Brian E J Rose - University at Albany State University of New York (first author)
Drew Camron - University Corporation for Atmospheric Research
John Clyne - NCAR
Orhan Eroglu - NSF National Center for Atmospheric Research
Robert Ford - University at Albany State University of New York
Julia Kent - NSF National Center for Atmospheric Research
Ryan May - University Corporation for Atmospheric Research
James Munroe - 2i2c / Code for Science and Society
Kevin Tyle - SUNY at Albany

U13A-2350 Supporting NASA Earthdata users in the Cloud: NASA Openscapes JupyterHub and User Onboarding & Fledging #

Link to session

Abstract #

In this talk we will highlight our NASA Openscapes community teaching approach to using the 2i2c-managed JupyterHub – how we’ve collaboratively developed it to meet user needs, and how it continues to enable researchers and users of NASA Earthdata in the new Cloud paradigm.

NASA Openscapes is an open source mentor community across NASA Earth science data centers ( DAACs) that helps users explore and use the Cloud for their science and applications. Earthdata Cloud Cookbook is a learner-focused open source tutorial collection that we update openly as we learn together.

A critical piece of the NASA Openscapes effort is our NASA Openscapes 2i2c JupyterHub, a managed cloud computing space. By working with cloud early adopters and science Champions, responding and co-developing solutions, the JupyterHub has evolved since its early days in 2021. We support cloud computing for several languages (python, R, Matlab, QGIS) and common science libraries with corn; we streamlined how to bulk-add workshop participants via GitHub Teams; we established policy and technology for a special authentication mechanism for large scale workshops; we are developing earthaccess as an community-developed python library for NASA Earthdata search and access, whether locally or in the cloud.

Based on the last 3 years of engaging with the user community and the Hub, we have evolved how we onboard (first experience in the cloud) and fledge (set up for Cloud that includes a plan, how to do it, how to pay for it; leaving the nest and perhaps building your own). Fledging is an important part of adoption and initiating users to the Cloud - where do researchers go when they decide to do their science in the Cloud? We’ve been developing practices that aim to be equitable and consider policy (cost), technical (where do people go, what admin setup is needed, what tech like base images etc are needed), and social (how do I learn, get support) aspects, and look forward to discussing further at AGU.

Authors #

Julia S. Stewart Lowndes - Openscapes, LLC (first author)
Andrew Barrett - National Snow and Ice Data Center (NSIDC)
Carl Boettiger - University of California Santa Cruz
Aaron M Friesz - Organization Not Listed
Elizabeth E Holmes - NOAA Fisheries
Alexis Hunzinger - NASA Goddard Space Flight Center
Daniel Kaufman - NASA Langley Research Center
Luis Alberto Lopez - National Snow and Ice Data Center (NSIDC), CIRES, University of Colorado Boulder
Catalina M Oaida Taglialatela - NASA Jet Propulsion Laboratory, California Institute of Technology
Yuvi Panda - University of California, Berkeley
Michele Thornton - Oak Ridge National Laboratory

V31A-08 VICTOR – A new Cyber-infrastructure for Volcanology #

Link to session

Abstract #

Numerical models are essential for forecasting volcanic hazards for both short-term responses and long-term hazard assessment. While many models of volcanic processes already exist, challenges in finding, installing, and evaluating these models, coupled with limited computational resources, hinder their widespread use. To address this, we introduce VICTOR, the Volcanology Infrastructure for Computational Tools and Resources.

VICTOR is a cutting-edge cyber-infrastructure platform offering an open-source, cloud-based environment tailored for the volcanology community. It features Jupyter notebooks that integrate existing volcano models, such as the lava flow codes MOLASSES and IMEX_lava, the tephra and ash dispersal codes Tephra2 and HYSPLIT, and the mass flow code TITAN2D. The backend of VICTOR is managed as a JupyterHub, operated by the non-profit 2i2c under the Code for Science and Society.

VICTOR not only provides access to individual modeling tools, but also hosts workflows that use them in data inversion, model benchmarking, and uncertainty quantification. For example, we developed a workflow to validate mass flow models using multiple metrics and Bayesian statistics. VICTOR provides built-in access to external databases such as OpenTopography, Copernicus, and NASA’s remote sensing products to streamline obtaining and using data in workflows.

VICTOR also serves as an educational resource. In Spring 2023 and 2024 we taught graduate level, multi-institutional courses in Computational Volcanology using VICTOR, and we are creating multilingual tutorials for the workflows. We are developing teaching modules on topics such as lava flows and remote sensing to be shared with instructors. Lastly, VICTOR collaborates with national efforts including CONVERSE and SZ4D.

In summary, VICTOR addresses the critical need for accessible, effective volcanic hazard modeling tools and resources, fostering advancements in both research and education within the volcanology community.

Plain-language Summary #

VICTOR is a new online platform designed to help scientists predict volcanic hazards more easily. Traditional models can be difficult to find, use, and combine with other tools. VICTOR solves these problems by offering a cloud-based, open-source environment with user-friendly tools.

VICTOR includes tools like Jupyter notebooks that combine various volcano models for lava flows, ash dispersal, and mass movements. It operates through JupyterHub, managed by the non-profit 2i2c. The platform not only provides access to these models but also offers workflows for tasks like data analysis and model validation. For example, it has a workflow for testing mass flow models using multiple evaluation methods.

VICTOR simplifies data access by connecting directly to databases like OpenTopography and NASA’s remote sensing products. It’s also an educational tool, used in graduate courses and offering multilingual tutorials. Additionally, VICTOR is developing teaching materials on topics like lava flows and remote sensing and collaborates with national projects like CONVERSE and SZ4D.

In essence, VICTOR makes volcanic hazard modeling more accessible and effective, benefiting both research and education in volcanology.

Authors #

Einat Lev - Columbia University of New York (first author)
Sylvain J Charbonnier - University of South Florida
Charles Connor - University of South Florida
Samuel Krasnoff - Lamont -Doherty Earth Observatory
Abani K Patra - University at Buffalo

2024 impact report: new team structure, new funding, and growth in our network

Sun, 08 Dec 2024 00:00:00 +0000

2024 has been a busy year for 2i2c, with many highs and lows, a lot of impact, and significant organizational change. As the year comes to an end, I want to reflect on the work we’ve done in 2024, and where we aim to go in 2025.

In 2024, 2i2c reached the point in an organization’s lifecycle when a team has grown enough in size and complexity that you must change the ways that you organize. The informal ways that worked as a small group don’t suffice anymore, and you have to put more effort into aligning and coordinating everyone to ensure you have the same impact.

I call this the “$1M to $2M budget jump”, because organizations seem to hit this point around when your annual budget goes from $1M to $2M. Getting to the other side of this gap with an intact runway and team is hard, and I suspect that 2i2c’s fully distributed nature means that we hit these scaling milestones earlier than many organizations. For us, this has been a major focus of effort all year, and has involved taking a top-to-bottom look at our plans and ways of working as a team. Read on for more details about major updates, challenges, and impact that our team had in 2024.

Organizational updates #

At an organizational level, this year had a lot of introspection and planning, a few new roles, a few departing team members, a funding crunch, a successful effort to dig out of it, and a new system of work organizing our team. We’ll share more about all of this later, but here are the major implications for our team:

We’ve raised another $2.2M in funding to support our efforts in scaling and sustaining our network of community hubs. This gives us roughly another 2 years of projected runway (with some assumptions about revenue from contracts and grants). Below are two posts that describe two major awards we were awarded in Q3 and Q4 of this year:

We’ve designed and hired several strategic and systems-level roles to give our team support and direction as it grows. Here’s a brief summary:

Head of Product, Giuliano Maciocci. Giuliano leads our efforts to define and steward our value proposition and the roadmap of development for products and services that feeds into it. Giuliano has 10+ years experience driving growth in companies, was the ex-Chief Product Officer at Ex Ordo, ex-head of Product at eLife Sciences where he led the open science product Executable Research Article, and contributed significantly to mobile design and innovation at Adobe.
Chief of Staff and Delivery Manager, Harold Campbell. Harold leads our delivery and operations efforts, and stewards our system of work and coordination around it to ensure we deliver on our commitments efficiently and reliably. Harold has 15+ years of industry experience spanning companies in Africa and Jamaica, and 10+ years experience in agile consulting and coaching in technical and product teams.
People Lead, April Johnson. April leads and stewards our system to support our team as individuals, ensuring that we provide the guidance and support needed to grow our team members in their careers and skills. April has 20+ years growing and guiding technology organizations. She is the ex-Global Head of Transformation at Thoughtworks (Europe, Latin America, India, North America, and Asia), with expertise in human-centered design, agility, people leadership, change, leading remote and asynchronous agile teams, coaching, and non-profit development.

We’ve re-organized our team into separate product and business development teams, in order to focus on providing an excellent technical platform and a collection of services that maximizes community impact, as well as sustaining this service for our communities. This has allowed us to more effectively coordinate our service enhancement and development efforts, and increases our ability to deliver improvements to our communities and to upstream projects.

As a result, our organization has a much stronger foundation to build upon as we continue to grow and refine our sustainability model in 2025. It has positioned us to more effectively deal with the challenges in reaching our next milestones for scale and impact, and gives us the tools to be more adaptive and responsive to community needs.

Along the way, we also generated a lot of impact through our collaborations with communities in our network, and in the upstream projects that we support. For more details about our impact, see the summaries below.

Community impact #

2i2c’s core mission is to support its network of communities that create and share knowledge with open infrastructure. Here are the highlights of how our community network has grown and had impact.

First, we’ve grown our network of hubs and users through several new partnerships. We grew the number of active hubs from ~75 to ~105, and grew our end-of-year Monthly Active Users (MAUs) from ~6000 to ~8000.

You can see an interactive version of these numbers in our platform usage dashboard: 2i2c.org/kpis/cloud/

Beyond the numbers, we also re-focused our team on reporting impact stories from our collaborations with community members, and have published these into a (growing) list of posts on our blog:

Here are a few community highlights from this year:

We served around 20 communities from Latin America and Africa for the Catalyst project
Our community partner Openscapes were invited to the White House to discuss the importance of open science
The NeuroHackademy used our infrastructure to support their annual summer school
We enabled ephemeral and sharable interactive computing environments for the Amerigeo workshop in the geospatial community
We ran a pilot for an HHMI-affiliated open source project called Spyglass for reproducing their pre-print with a live interactive environment using BinderHub to support publishing infrastructure
We began a collaboration with Development Seed around the NASA VEDA project, to support them with interactive cloud environments for geospatial research
Several members in our community network showed off their work at AGU 2024
We co-organized a workshop alongside Project Pythia to create computational narrative content for geospatial analytics, and upgrade their stack to Jupyter Book 2.0

Open source technology enhancements #

Our second pillar of impact is to improve the ecosystem of open infrastructure and the open science workflows it enables. We use collaborations with our community partners to drive new cycles of development in open source tools that we support. Here’s a brief overview of our impact across the open source ecosystem this year.

In 2024, 2i2c team members authored over 500 pull requests that were merged in our key open source communities communities. Find our list of key open source communities here:

compass.2i2c.org/open-source/key-communities/

Here are a few highlights where we focused our effort this year - each of these efforts required both development with and for our community network, as well as upstream contributions and support:

We released JupyterHub Fancy Profiles, which allows for a more flexible and modern interface to launch environments with JupyterHub.
We used this to allow users to build and launch custom environments in JupyterHub in a way that users can also share with others.
We’ve added a Grafana dashboard for resource and cost monitoring with JupyterHub to give communities more visibility over their projected cloud costs.
We began incorporating Jupyter Book 2.0 workflows into our community hubs and laid a foundation for enabling our communuty networks to communicate with one another more effectively using the new MyST document engine. Read more in our blog post about Jupyter Book 2.0.
We built frx-challenges, a tool to help communities host data challenges with secure, automated evaluation of submissions. This was built in collaboration with the HHMI Cellmap Challenge competition.

Looking to next year #

2025 is going to be a critical year for 2i2c to build upon the work we began in 2024 to achieve a more sustainable and scalable community model. Here are the main areas that will guide our work in the new year and into 2026, pulled from our recent proposal from The Navigation Fund:

Goal #1: Delivery. Develop the operating structure and team skills to efficiently scale our product and service delivery.
Goal #2: Product. Develop a product system that continuously improves and delivers value and impact at scale.
Goal #3: Sustainability. Build a business model that is competitive and gives us resources to sustain and scale our service.

These are the key goals 2i2c must achieve in order to ensure that its service remains impactful, sustainable, scalable, and accessible. We believe that we’ve laid a strong foundation to get there, and are excited to begin work next year.

Overall, 2024 has been a challenging, but also a rewarding year for our team. We’ve encountered and successfully worked thorugh a number of scaling challenges, and we’ve made significant progress at laying a foundation on which we can build for the years to come.

I’m incredibly proud of 2i2c’s team for all of their hard work this year, and also honored to be working with a network of communities that care about open infrastructure and its value for creating and sharing knowledge with the world. Here’s to another year of impact!

Acknowledgments #

Support for organizational and strategic work like this is provided by a grant from The Navigation Fund and CZI.

Financial support from The Navigation Fund for identifying and building a scalable sustainability model

Sun, 08 Dec 2024 00:00:00 +0000

We are proud to announce that 2i2c has received financial support from The Navigation Fund to assist us in our mission to design and build a sustainable and scalable model for helping communities create and share knowledge with open infrastructure.

The award totals ~$1.5M over 2 years. It provides support for several key strategic roles that are traditionally difficult to fund in a young organization: product management, delivery management, and business development. Here are the key goals this funding works toward:

Goal #1: Delivery. Develop the operating structure and team skills to efficiently scale our product and service delivery.
Goal #2: Product. Develop a product system that continuously improves and delivers value and impact at scale.
Goal #3: Sustainability. Build a business model that is competitive and gives us resources to sustain and scale our service.

We believe this is a critical step in helping our organization define and build a pathway to sustainability so that our service remains accessible, scalable, and resilient for years to come.

We’re incredibly honored to be supported by the Navigation Fund, and excited to continue our work helping communities create and share knowledge with open infrastructure.

`frx-challenges`: A new tool to host data challenges for Frictionless Research Exchanges

Fri, 06 Dec 2024 00:00:00 +0000

2i2c is pleased to announce the frx-challenges project, a new open source tool to help communities host data challenges on shared infrastructure:

2i2c-org/frx-challenges

This project aims to make it easier for administrators to provide a service that enables users to submit code and data that are evaluated on secure infrastructure with access to private data and resources. It also provides a leaderboard that helps users compare their performance against others.

An example leaderboard for a data challenge, taken from the Cellmap Challenge. Users make submissions that are run against secure and private infrastructure and data, and provides feedback about the submission’s performance. Learn more about the FRX challenges project here: 2i2c.org/frx-challenges/

It is designed to be lightweight and flexible, and can be run on a variety of shared infrastructure. For those who wish to run this project on cloud infrastructure, we’ve also published a Helm Chart to help you deploy frx-challenges with Kubernetes.

While it can be run on its own, we believe that it naturally complements other tools and services for interactive computing and data, such as JupyterHub, Jupyter Book, and Binder. More on that below.

Below is a brief description of the motivation behind this project.

What are Frictionless Research Exchanges #

The project is heavily inspired by David Donoho’s vision of Frictionless Research Exchanges (FRX) as described in Data Science at the Singularity.

In this article, Donoho describes three key pillars for Frictionless Research Exchanges:

The three initiatives are related but separate; and all three have to come together, and in a particularly strong way, to provide the conditions for the new era. Here they are:

[FR-1: Data] datafication of everything, with a culture of research data sharing. One can now find datasets publicly available online on a bewildering variety of topics, from chest x-rays to cosmic microwave background measurements to uber routes to geospatial crop identifications.

[FR-2: Re-execution] research code sharing including the ability to exactly re-execute the same complete workflow by different researchers.

[FR-3: Challenges] adopting challenge problems as a new paradigm powering scientific research. The paradigm includes: a shared public dataset, a prescribed and quantified task performance metric, a set of enrolled competitors seeking to outperform each other on the task, and a public leaderboard. Thousands of such challenges with millions of entries have now taken place, across many fields.

We considered the landscape of tools and services, and felt that [FR-1] and [FR-2] were already well-served by a variety of tools and services for community workspace infrastructure (e.g., JupyterHub: jupyterhub.readthedocs.io), sharable computational environments (e.g., BinderHub: binderhub.readthedocs.io), authoring and reading computational narratives (e.g., Jupyter Book: jupyterbook.org and MyST: mystmd.org), and data I/O tools and standards (e.g., Zarr: zarr.readthedocs.io and Intake: intake.readthedocs.io).

However there was a natural missing piece for [FR-3 Challenges], and we could not identify any community-managed infrastructure that facilitated data challenges. This is the goal of frx-challenges.

Why facilitate data challenges? #

Data challenges are harder than you think! While it is simple enough to run somebody else’s code locally, data challenges require a systematic, secure, and automated approach to accepting and evaluating submissions in a fair and repeatable way. Here are some of the big challenges to tackle:

Submissions must retain user and team identity, which means that we must keep track of users and their submissions over time, since data challenges are designed to encourage iterative improvement and optimization.
Evaluations must use potentially complex resources and data since many data challenges operate by publicly sharing a small dataset, and then running it against a much more complex dataset.
Evaluations must be totally secure, so that submissions can’t do nefarious things like mine cryptocurrency or extract the challenge’s private data in unintended ways.
Evaluations must be automated, so that running the challenge does not require extensive human intervention and can scale to many users.
Evaluation must be flexible, so that the infrastructure can accept a variety of types of submissions (e.g. code, data, model weights, etc), run them with arbitrary environments designed by the organizers, and run them with the right hardware to get the job done.

These are just a few of the major challenges that we’ve tried to address with frx-challenges, and we’re excited to see how it goes with our first assisted community challenge: the Cellmap Challenge.

If you’re interested in learning more or participating in this project, follow along at its GitHub repository:

2i2c-org/frx-challenges

This is still the very early stages of the project, and we imagine it will evolve significantly. We welcome feedback for how it can more effectively serve a variety of communities.

Acknowledgements #

Thanks to the Howard Hughes Medical Institute (HHMI) for collaborating with us on the Cellmap Challenge, which led to the creation of this project.

Thanks to Kristen Ratan and Strategies for Open Science (Stratos) for enabling this collaboration, and providing strategic guidance and support.

Improving the logged in home page experience in JupyterHub with `jupyterhub-fancy-profiles`

Mon, 18 Nov 2024 12:55:20 -0800

On most research oriented JupyterHub installations, users would like to customize their server (the environment, resources available, etc) after logging in. In Kubernetes based JupyterHub environments, a profile list provides this functionality.

(Profile List for the NASA VEDA JupyterHub with the default implementation from KubeSpawner)

The profile list is the de-facto “logged in homepage” for these users, as that is what they see after they have logged in.

In collaboration with Development Seed, funded by our earlier grant from GESIS as well as the NASA VEDA project, we have been building the jupyterhub-fancy-profiles project to improve this experience.

(Profile List for the NASA VEDA JupyterHub with jupyterhub-fancy-profiles)

Last week, we rolled this new experience out to all 2i2c managed JupyterHubs! Here’s a quick rundown of what this enables:

Descriptions for choices in the dropdowns, making it much easier for users to know what they are getting with each environment (or resource selection).
Fully backwards compatible with the existing KubeSpawner profile list implementation. In our PR to roll this out to all hubs, you notice that we didn’t have to change the structure of any profile lists! So you can safely roll this out to your hubs too without needing to fundamentally change how your profiles are set up.
It is a modern web app (built with react), just like the JupyterHub admin panel. This allows us to evolve and satisfy user needs much faster, as well as expanding the pool of people who can contribute to the project!
Support for dynamically building images using mybinder.org style repositories! It talks to the binderhub API so users can build reproducible environments as they wish without admin involvement nor needing to fully understand how docker and containers work. Our earlier blog post has more information.

This is just the start, and thanks to ongoing funding from the NASA VEDA project, we are going to continue making improvements to this experience.

Use this in your JupyterHub #

As with everything we build at 2i2c (per our right to replicate policy), this project can be used with any JupyterHub installation that uses Kubernetes. There are instructions in the README. Please try it out on yours and let us know what you think!

Credit #

The project was initiated with funding generously provided by GESIS (see our earlier blog post).
Sanjay Bhangar and Oliver Roick from Development Seed for advocating for this project and contributing heavily to it.
The NASA VEDA project (in particular, Brian Freitag and Alex Mandel), for continued funding (in the form of engineering time) plus being early adopters!

Announcing the Jupyter Book 2 alpha

Mon, 18 Nov 2024 00:00:00 +0000

Cross-posted from the Jupyter Book blog. Note that some MyST functionality is not supported on the 2i2c website – please see the original post for previews.

Over the last ten months, the Jupyter Book team have been hard at work; Jupyter Book has become a Jupyter subproject, and the team¹ announced a plan to release Jupyter Book 2. This post announces the alpha release of Jupyter Book 2.0, which has been re-written from the ground up to use the new MyST-MD engine.

Over the next few months, we will work in preparation for the full release of Jupyter Book 2. Stay tuned for more! The initial documentation for the alpha release can be found at:

next.jupyterbook.org/

Install the Jupyter Book 2 Alpha #

The Jupyter Book 2 alpha is available from PyPI.org. You can install it with pip, using

pip install -U jupyter-book==2.0.0a0

If you use pipx, it’s recommened to run Jupyter Book 2 using

pipx run jupyter-book==2.0.0a0

Jupyter Book 2 needs Node.js installed on your computer. If this is not the case, running jupyter book will prompt you to install it using the nodeenv package that ships with Jupyter Book 2:

❗ Node.js (node) is required to run Jupyter Book, but could not be found`.
❔ Install Node.js in '...'? (y/N):

Press y and Enter to proceed.

The Jupyter Book 2 project is a complete re-write of Jupyter Book. We expect there to be bugs and breakages! Please use our support channels to keep us up to date with your findings!

Discord

GitHub Issues

New Features in `2.0 alpha` #

Rich Hover Previews #

The new MyST book and article themes provide useful hover previews for links to other MyST content, Wikipedia, GitHub issues, and many more.

Content from other websites built with the MyST engine can be embedded in your own sites and PDFs:

Cross-referenced content can easily be embedded and re-captioned into other pages and projects, such as this figure to mystmd.org/guide/embed#mylabel.

Simple Instant Search #

A new client-side search uses a simple, modern algorithm for fast local search that finds the results that you care about.

Client-side search uses simple, modern, Algolia-inspired search algorithm to provide useful search results. We will be iterating on this in the near future for even richer search results!

High Quality PDFs #

PDF documents can now be built with Typst, a high-quality typesetting engine that produces readable error messages and beautiful documents. This feature was the basis for the 2024 SciPy proceedings, which is now built on MyST Markdown and will be accepting Jupyter Notebooks in 2025.

Example of the LaPreprint Typst template for rendering PDFs from Jupyter Book (via the MyST Engine).

Coming Soon in `2.0 beta` #

Custom Styles & Scrips #

Jupyter Book 2 will make it easy to tweak your website styles, and add new website behaviors.

Generate Markdown from Code Cells #

The MyST engine is on-track to support the inclusion of references and other markup features generated by code cells.

Control Cell Visibility with Tags #

In the beta release, Jupyter Book 2 will once-again be able to show and hide content according to cell tags.

Jupyter Book 2 vs MyST-MD #

At this early stage, the new Jupyter Book application jupyter book behaves identically to the mystmd engine that it is built upon; as outlined in our Jupyter Book 2 plan, we intend for Jupyter Book to be an “opinionated distribution” of mystmd that shares the same configuration format and CLI. This contrasts with Jupyter Book 1, which was built on top of the Sphinx documentation engine, but offered its own CLI and configuration files. In future, the jupyter book and mystmd CLIs may diverge from one another, but we expect that this will be handled in a graceful manner: mystmd commands should always be compatible with the jupyter book application.

Acknowledgements #

Thanks to Project Pythia for funding some of our ongoing work on Jupyter Book.
Thanks to the Jupyter Book community for their collaboration.

Jupyter Book project has historically been a technical project of the Executable Books organisation. In 2024, the establishment of a Jupyter subproject means that the Jupyter Book project now has its own identity outside of Executable Books. ↩︎

Track and manage cloud costs using Grafana

Fri, 15 Nov 2024 00:00:00 +0000

Grafana dashboard showing cloud costs broken down by compute, storage and other components for the Openscapes hub.

We are pleased to unveil a new feature to track cloud costs within our Grafana dashboards! Community Champions now have the ability to monitor the cost and usage of their 2i2c-managed hubs that displays up to date aggregated costs as well as detailed breakdowns for more granular reports.

Note that this feature is currently available to AWS hosted hubs only and will be rolled out to other cloud providers in the future.

Accessing the cloud cost dashboard #

Community Champions can view the Cloud Cost dashboard from their Grafana instance (please see the Service Guide for how to gain access).

From the main menu of Grafana, navigate to Dashboards > Cloud cost dashboards > Cloud cost attribution to view the dashboard.

Understanding the cloud cost dashboard #

A typical 2i2c-managed deployment comprises of a staging hub and a production hub, although some other communities may have extra hubs such as a workshop hub. By default, costs are not broken down on a per hub basis unless the community has opted in to this feature.

The dashboard is made of several panels:

Daily costs
Daily costs per hub (opt-in only)
Total daily costs per component
Daily costs per component per hub (opt-in only).

For more detailed information on the data that each panel displays, please consult our Service Guide for reference.

The dashboard can be shared with other community members and stakeholders so they can understand usage and cost patterns. Community Champions can export data to a CSV file, or they can generate a snapshot of the Grafana dashboard and share a public link.

For instructions on how to export data from the dashboard, please see our Service Guide for reference.

Next steps #

We would love to know whether this feature is useful and how it can be improved. We will be contacting individual communities to share their feedback with us – please share your thoughts with us!

We will work on rolling out this service to GCP hosted clusters in future. Stay tuned to know when this feature is available to your community.

Acknowledgements #

Thank you to Erik for spearheading the rollout effort and to the rest of the 2i2c team for their support.
Thanks to Openscapes and Cryocloud communities for providing valuable insights during the prototyping and testing phase, and for funding part of this work.

Introducing the Catalyst Project Community Partner Highlights

Thu, 31 Oct 2024 00:00:00 +0000

Cross-posted from the Catalyst Project blog

Catalyst Project community partners using accessible cloud infrastructure for open science leadership and training. (clockwise from top-left) NNB-CCG, MUST, CICADA and INER. Photos courtesy of Shirley Alquicira Hernández, Bennett Kankuzi, María Inés Fariello Rico and Yalbi I. Balderas-Martinez.

The Catalyst Project is a community-engaged initiative designed to support the adoption of open science principles in under-served bioscientific research communities through the provision of reliable and sustainable cloud computing infrastructure. It’s a project we’ve been working on now for almost two years, which involves staff from seven different organizations: 2i2c, The Carpentries, CCAD, CSCCE, IOI, MetaDocencia, and OLS, and is funded by the Chan Zuckerberg Initiative.

A key part of the project is engaging with Community Partners in Africa and Latin America: Institutions, organizations, and individuals who are undertaking bioscientific research projects that require cloud computing infrastructure. As collaborators on the Catalyst Project, Community Partners can access and use 2i2c’s open science cloud services, and also receive training from 2i2c, The Carpentries, MetaDocencia, and OLS to support their work. Community Partners also play a vital role in shaping an evolving governance model for the Catalyst Project to help sustain, scale, and maximize impact in Latin America, Africa, and under-served communities around the world.

In a new collection of blog posts (that we hope will expand over the next couple of months!) we’re highlighting the work of the Catalyst Project Community Partners. This post is a gateway to learning more about the Catalyst Project and its Community Partners. If you have any questions or feedback about the project, please send an email to the core team.

Highlighting the Catalyst Project Community Partners #

The Catalyst Project currently involves 19 Community Partners, 9 in Africa and 10 in Latin America. Our initial blog post series showcases seven of the Partners, and each post is available in English and Spanish:

African Institute of Biomedical Science and Technology (AiBST) #

At the African Institute of Biomedical Sciences and Technology (AiBST) in Zimbabwe, Zedias Chikwambi and colleagues are working to discover and utilise biomarkers to guide personalized medical treatment.

“Through the Catalyst Project we are able to bring genomic information interpretation to patient bedsides.” - Zedias Chikwambi

Read more: EN | ES

Malawi University of Science and Technology (MUST) #

The Catalyst Project Community at the Malawi University of Science and Technology (MUST) is working to popularize the applicability of data science and artificial intelligence in various undergraduate and postgraduate research contexts in Malawi, including health, business, and education.

“…many staff and students need… a robust and easily accessible platform from which they can efficiently run their machine learning models and do advanced data analysis for their data science research…” - Bennett Kankuzi

Read more: EN | ES

MolerHealth #

MolerHealth is focused on revolutionizing healthcare in Nigeria by developing an accessible electronic health record (EHR) system aimed at reducing disease misdiagnosis.

“Access to training, like The Carpentries Instructor Training, has empowered our team with essential skills for effective teaching and collaboration.” - Monsurat Onabajo

Read more: EN | ES

Nelson Mandela African Institution of Science and Technology (NM-AIST) #

The Northern Tanzania One Health Research Group, hosted at the Nelson Mandela African Institution of Science and Technology (NM-AIST), is using the Catalyst Cloud Infrastructure to understand the transmission dynamics, genetic diversity, and antimicrobial resistance of the Mycobacterium tuberculosis complex (Mtb) between humans and livestock in Northern Tanzania.

“…access to training, particularly through the 2i2c Hub Champion Training, has significantly enhanced our ability to manage and optimize cloud-based resources." - Beatus M Lyimo

Read more: EN | ES

Nodo Nacional de Bioinformática (NNB-CCG) #

The Nodo Nacional de Bioinformática (NNB-CCG) of the Centro de Ciencias Genómicas (CCG) - Universidad Nacional Autónoma de México (UNAM) is a group that brings together professionals and academics to support, provide services, and maintain the growth of the field of bioinformatics in the country’s research.

“(Our) goal is to optimize our participation in events, assess the usefulness of the Catalyst Project’s resources, and, in turn, provide the Catalyst Project with guidelines to improve their service by identifying the necessary areas for improvement within the institutions." - Shirley Alquicira Hernández

Read more: EN | ES

Instituto Nacional de Enfermedades Respiratorias (INER) #

Collaborators at INER are using the Catalyst Cloud Infrastructure to implement machine learning algorithms that will classify radiology images of pulmonary thromboembolism (PTE), with a view to improving patient outcomes.

“The Catalyst Project is helping us to collaborate more efficiently and work remotely.” - Yalbi I. Balderas-Martinez

Read more: EN | ES

Centro Interdisciplinario en Ciencia de Datos y Aprendizaje Automático (CICADA) #

CICADA, an interdisciplinary center researching data science and machine learning, is using the Catalyst CLoud Infrastructure to analyze Uruguayan population data to understand patterns of migration, how much of the native footprint remains, and what can be said about the people who lived in the Uruguayan territory before the arrival of Europeans.

“The Catalyst Project…trainings are attractive, as they are respectful of the people, no previous knowledge is assumed, and the instructors are welcoming.” - María Inés Fariello Rico”

Read more: EN | ES

About the blog posts – Acknowledgements #

Creating a series of blog posts to highlight the work of the Catalyst Community Partners was a collaborative effort involving staff from CSCCE, 2i2c, OLS, and MetaDocencia. Specifically, Lou Woodley, Katie Pratt, Jenny Wong, and Tajuddeen Gwadabe conceived the idea during our regular Catalyst Project “website team” meetings, and developed a strategy for reaching out to community partners to gather information.

Katie then led that outreach, which involved a representative of each Community Partners completing a Google Form to answer three key questions and sharing a photo (or a selection of photos) to use on the blog. Katie curated all of the information, edited together the blog posts, and secured sign-off from all of the partners. Sabrina López and her team at MetaDocencia coordinated the translation of the posts from English to Spanish, and Jenny formatted and published them on the website.

Acknowledgements #

Thanks to the Catalyst Community Partners for generously sharing more about their work.
Thanks to CZI for funding this work.

Support from CZI to sustain 2i2c's mission to help communities create and share knowledge with open infrastructure

Sun, 13 Oct 2024 00:00:00 +0000

We are proud to announce that 2i2c has received financial support from The Chan Zuckerberg Initiative to sustain our efforts at helping open science communities create and share knowledge with open infrastructure.

Funding comes from the Open Science Program at CZI, which aims to ‘…support a diverse scientific community working in the open to accelerate our understanding of human health and disease. We invest in tools, platforms, and organizations that help expand participation and access to the scientific process by making it open and reproducible, and helping scientists build on each others’ work.’

This builds upon previous core support provided by CZI, and provides an additional ~$700K over 1 year to help 2i2c sustain its mission. We are deeply grateful to CZI for their support, and this funding provides key runway for 2i2c to serve its community network and explore a sustainable and scalable model for impact.

From the GeoLab team - Pancakes are the future of geophysical data processing

Tue, 01 Oct 2024 00:00:00 +0000

Our partner EarthScope published a blog post about their cloud stack which includes heavy mention of 2i2c’s infrastructure model. Check it out!

Openscapes goes to the White House!

Mon, 23 Sep 2024 00:00:00 +0000

Our partner OpenScapes recently took a trip to the White House to advocate for Open Science and the Open Source ecosystem, check out their blog post about the experience.

Hub Champion Training Reflections (English)

Wed, 04 Sep 2024 00:00:00 +0000

We’ve developed and are now offering a Communtiy Hub Champion training, see this blog post from the Catalyst Project for more details.

Acknowledgements #

Thanks to the Catalyst Project for this work.
Thanks to CZI for funding this work.

Reflexiones sobre la formación de Campeones y Campeonas del Hub (Español)

Wed, 04 Sep 2024 00:00:00 +0000

MyST Mini-Hackathon with the DeepLabCut Team

Mon, 02 Sep 2024 00:00:00 +0000

The DeepLabCut Team #

Animal pose estimation using deep neural networks. Courtesy of the DeepLabCut Jupyter Book

The DeepLabCut team is a group of researchers and developers who are working on open source tools for analyzing animal pose estimation by training deep neural networks on videos.

Chris Holdgraf visited the lab in early August to learn more about how the group were using open-source tools to document and share their work.

Jupyter Book and MyST #

Extensive documentation for using the DeepLabCut software package is already available as a Jupyter Book. The group was interested in adopting MyST Markdown to stay ahead of the curve and upgrade their Jupyter Book (see the related announcement Jupyter Book 2 will be build upon the MyST-MD engine).

Chris led a mini-hackathon to introduce the group to MyST and collect feedback on where enhancement features could be made in the future. Here’s a summary of the outcomes:

Many improvements were made to the MyST documentation 📖
- The MyST Quick Start Guide was used to onboard new users. Amendments were upstreamed to the MyST docs directly and were immediately available to all.
- A tutorial on executable documents was added to the collection of MyST tutorials.
- MyST-MD installation instructions were simplified using mamba.
A bunch of enhancement features were requested ✨
And we found a bug in the table of contents validation 🐞

Summary #

Hackathons are a great way for quickly imparting knowledge and gathering feedback in a short space of time. The event spurred rapid contributions to the MyST ecosystem – embracing reuse of the MyST quick start guides saved time and effort, while engaging with users directly closed a tight feedback loop for enhancements.

Acknowledgments #

Thank to the Mackenzie Mathis Lab for hosting Chris Holdgraf at EPFL, Lausanne, Switzerland.
Thanks to the Jupyter Book team for collaborating on this with us.

NeuroHackademy Summer School Reflections

Mon, 19 Aug 2024 00:00:00 +0000

Thank you to Ariel Rokem and Noah Benson for guest writing this blog post!

Group photo from NeuroHackademy 2024

What is NeuroHackademy? #

Part summer school, part free-wheeling hackathon, all focused on the use of data science methods in neuroscience, NeuroHackademy is an event that was recently hosted by the University of Washington eScience Institute in Seattle, WA, USA. This event, that has been running annually since 2016, aims to provide early-career researchers in Psychology, Medicine, Neuroscience, and other related fields with the skills and knowledge that they need to effectively and rigorously work with open source tools and workflows for analyzing human neuroscience data. This supports the effort to make scientific analysis and results shareable, reproducible, and accessible.

Global and inclusive #

In 2020, the event had to rapidly pivot to an online format, and this format was also used in 2021. Through this experience, the organizers ( Ariel Rokem and Noah Benson) realized that many participants preferred the online format. For example, participants who could not afford to travel to Seattle, or participants who had care-taking responsibilities that precluded them from participating in a two-week event away from their homes. In 2022, the event pioneered a hybrid format, where half of the participants are present in-person and half join the event via zoom, slack, GitHub, and of course through a dedicated 2i2c JupyterHub. Taken together, this format allows the participation of students from a larger range of backgrounds and locations. This aspect plays an important part in building a global and inclusive community of practice. See the paper Hands-On Neuroinformatics Education at the Crossroads of Online and In-Person: Lessons Learned from NeuroHackademy to read more on this subject.

Collaboration with 2i2c #

Previous years #

NeuroHackademy has been an early adopter of the cloud-based JupyterHub model, setting up its first hub using the zero-to-jupyterhub guide in 2018. NeuroHackademy partnered with 2i2c as soon as it was founded, and 2i2c has operated a JupyterHub for the last 3 years. The hub provides an interactive computing platform for learners, and implements the “digital watering hole” for practical and immediate access to a range of cloud-based datasets in human neuroscience (see blog post announcing support for this year’s event).

In terms of the software environment, the following tools and features that have benefited the event over the years include

nbgitpuller allows students to synchronise lesson content with an organizational GitHub repository that is collaboratively maintained by the lesson instructors.
Shared data file storage with read-only access for learners and read-write access for instructors
Access to an abundance of neuroimaging data hosted in cloud object storage
- The Human Connectome Project
- The Natural Scenes Dataset
- OpenNeuro
- The Healthy Brain Network
- And more.

This year #

This year 2i2c supported the following tools and features for NeuroHackademy

A “Bring your own image” option where users can pull any image hosted on a container registry into the hub. See our Integrating BinderHub with JupyterHub: Empowering users to manage their own environments blog post for more details.
repo2docker and GitHub actions to build and prototype images from a repository.
The support services provided by 2i2c and the ability for instructors to open pull requests on 2i2c infrastructure for speedy resolution.
GPU instances to support more compute intensive workloads for machine learning.

Next year #

One thing we have learned is that 2i2c automatically shuts down a user server after one hour of inactivity by default to ensure efficient resource usage and limit runaway cloud costs. Naturally, we are seeing increasing demand from learners for longer and more complex analyses. In response to this, we are keen to explore how the jupyter-keepalive extension can keep the server alive for long-running processes.

We are pleased that learners have made great progress in making use of cloud-native, open-source workflows for analyzing human neuroscience data. We are keen to benefit from lessons learned this year and are looking forward to collaborating with 2i2c once again to deliver the NeuroHackademy Summer School in 2025.

Watch this space next year!

Acknowledgements #

Funded by grant R25MH112480 from the US National Institute of Mental Health awarded to Ariel Rokem and Noah Benson.

The NeuroHackademy Summer School is sponsored by

References #

Keeping PACE with GPU enabled compute to detect global cloud cover using satellite data

Mon, 12 Aug 2024 00:00:00 +0000

(left, b&w) Model inputs and (right, color) model outputs of a simple multi-layer perceptron for detecting cloud cover.

PACE is the NASA Plankton, Aerosol, Cloud, ocean Ecosystem mission that focuses on understanding ocean health and its impact on the atmosphere. Together with the Ocean Carbon and Biochemistry (OCB) program, a one-week hackathon ran from Aug 4 to Aug 8 on the 2i2c-hosted CryoCloud hub. The goal of the hackathon was to explore new Earth science data streams provided by the OCI, SPEXone and HARP2 instruments using Python.

Machine Learning with GPUs #

One of the most advanced tutorials delivered during the hackathon was the Machine Learning Tutorial. The tutorial focused on creating a machine learning pipeline to detect cloud cover from satellite imagery. This was done by training a convolutional neural network (CNN) to assign each pixel a binary value to indicate whether the location was covered by cloud or not. To improve the spatial context beyond a single pixel value, as the likelihood of a pixel containing cloud cover increases if its neighbours also contain cloud cover, the CNN needs to be trained on the entire image at once rather than at a single pixel level. This massively increases the training time, but also allows the CNN to learn more complex relationships between pixels.

GPUs have a far greater number of cores than CPUs that are well-suited for accelerating the massive parallel processing needed to train a neural network on the large amounts of image data in the above scenario. PyTorch is a popular Python library for training CNNs, available for both CPUs and GPUs, and is an ideal tool for performing this kind of work. In terms of the accelerator hardware available on the CryoCloud hub, 2i2c provisions an instance with an NVIDIA Tesla T4 GPU with 4 CPUS, 16GB of RAM and 2,560 CUDA cores.

Managing shared memory on 2i2c hubs #

While developing the above tutorial, tutorial lead Sean Foley (NASA/GSFC/SED & Morgan State University & GESTAR II) noticed that training neural networks was way slower than it should be given the GPUs available to them. They investigated the issue, and with help from the 2i2c engineering team, it was determined that shared memory was the issue. PyTorch uses shared memory via /dev/shm for faster parallel processing, and maximizing use of GPU. However in containerized environments, this is limited to a maximum of 64MB by default.

You can check the amount of shared memory available on your hub in a terminal with the command

df -h | grep /dev/shm

As you might expect, 64 MB of shared memory is not enough for training over 160,000 images in the tutorial. 2i2c was able to remove the limit, making /dev/shm share the memory the user has selected via their profile list, rather than be artificially limited to any particular size. This was done for all users on the CryoCloud hub within an hour of the issue being reported and we upstreamed the change for all 2i2c hubs (see GitHub pull requests for CryoCloud and all 2i2c hubs).

Conclusion #

This event demonstrates the economy of how running shared and open infrastructure dynamically solves problems for the benefit of many users, not just for one occasion. Learning experiences such as the above are transferred and embedded upstream into transparent and flexible open source software that impacts not only all users of 2i2c operated hubs, but also generalized for the wider research community at large (case in point, see the Slack thread below from Eli Holmes, operator of the NOAA Fisheries hubs)! We are grateful for the strong partnerships with our communities who help us to co-design impactful solutions that are specific for their needs and accessible to all.

The power of open infrastructure beyond 2i2c-operated hubs

References and Acknowledgments #

Sean Foley (NASA/GSFC/SED & Morgan State University & GESTAR II)
Tasha Snow (ESSIC UMD & NASA GSFC & CryoCloud)
PACE Hackweek Jupyter Book

Ephemeral Interactive Computing for the AmeriGEO Workshop

Mon, 05 Aug 2024 00:00:00 +0000

AmeriGEO provides a framework for cooperation in the Americas for the use of Earth data to benefit science and society with data driven decision-making. As part of a virtual workshop held on 1st August 2024, 2i2c provided an interactive computing environment to support the delivery of a NASA TOPST water module.

The workshop was facilitated by Kytt MacManus and Juan F. Martinez (both of CIESIN, Columbia University, New York). Juan presented interactive R code, with explanatory content written in Quarto, for hotspot vulnerability analysis for floods and landslides focused on Ecuador using earth observation data and socioeconomic data to develop an index of vulnerability. Check out their GitHub repo and explore interactively yourself on our BinderHub (see our blog post for more details of how to access the BinderHub deployments to provide Ephemeral Interactive Computing for NASA Communities).

Over 100 participants were able to access the interactive workshop on our infrastructure, with 8 GB of RAM per user to facilitate the processing of large amounts of earth data. We are pleased that the workshop was successful and the platform was able to provide a great experience for participants. After the workshop, Kytt reported that

The technology worked as expected and we didn’t run into 1 major technical problem. Thank you so much for that!".

Acknowledgements #

Funding from Science Mission Directorate’s Open Source Science Initiative, Research Opportunities in Space and Earth Science (ROSES-2022), F.14 Transform to Open Science
NASA NSPIRES F.15 High Priority Open-Source Science Award NNH22ZDA001N-HPOSS
NASA Socioeconomic Data and Applications Center (SEDAC)
Kytt MacManus
Juan F. Martinez
James Munroe for providing support and assistance for setting up the cyberinfrastructure for this workshop.

Collaborating with Development Seed to deliver cyberinfrastructure for NASA VEDA

Fri, 12 Jul 2024 00:00:00 +0000

Thank you to Sajjad Anwar and Sanjay Bhangar for contributing to this post.

The VEDA dashboard

The 2i2c team are proud to continue our strong working collaboration with Development Seed, following our previous work on launching the US GHG center (also see the Development Seed blog post). Together with scientists at NASA in our regular sync touchpoints, we have recently delivered a tranche of improvements to the Visualization, Exploration and Data Analysis (VEDA) project.

This platform is designed to thread open-source components together to consolidate GIS delivery mechanisms, processing, analysis and visualization tools, and presented in a collaborative interactive computing environment. All code repositories and associated resources stemming from this work are available on the VEDA GitHub page.

In the spirit of fully open development, you can see the objectives the combined 2i2c and Development Seed team had for the last quarter. In this blog post, we will describe some of the significant ones!

Better image management and testing #

The repo2docker-action is a GitHub action simplifying image building and testing for use with JupyterHub, using either a Dockerfile or various configuration files (like requirements.txt, environment.yml, etc) supported by repo2docker. We migrated our image building pipeline from a somewhat homegrown solution to this upstream action, making image updates and testing much easier. In particular, we can automatically run test notebooks on every change we make to the image! This way, we can easily catch any breaking changes in library versions or other package installs without disrupting users. We also debugged and contributed upstream fixes to the testing infrastructure so everyone could benefit from this, rather than just us.

Automatically pulling example notebooks on startup #

When a user logs into a JupyterHub, it is very helpful if we could have a bunch of example notebooks and other content pre-populated for them so they can get started right away. nbgitpuller is heavily used for this particular use case. However, it requires that nbgitpuller is installed inside the image the user is using - and not all images have it installed. In particular, we wanted to continue using the (wonderful) Rocker images maintained upstream for R users, however they do not have nbgitpuller installed. To solve this problem we built jupyterhub-gitpuller-init, which can be used as an init container to pre-populate user content on persistent home directories regardless of the image used. We also made sure to build this in a way that anyone can use it, and it is not tied into either 2i2c or VEDA infrastructure!

Opening specific visualizations in QGIS via URL #

QGIS is the world’s most used open source GIS software, and previously 2i2c had worked with Openscapes and QGreenland to bring this desktop software to JupyterHub. We had previously worked on a container image that allows users to access large datasets stored in the cloud directly through QGIS on the JupyterHub, allowing users to work with much larger datasets than they could on their desktops by bringing cloud compute adjacent to the data. As a continuation of this work, we developed jupyter-remote-qgis-proxy, which builds QGIS specific features on top of jupyter-remote-desktop-proxy. In particular, it allows creation of shareable links that when clicked, opens specific datasets and layers in QGIS in a JupyterHub! You can see this in action:

Launching QGIS on a Linux desktop served by the VEDA JupyterHub

This opens up exciting future possibilities. Imagine this exploration of the Camp Fire having an ‘Open in QGIS’ button that enables further exploration of the data without the user needing to download or install anything! Work will continue in the coming quarter towards achieving this vision.

We are also excited to see recent work in this space from QuantStack and Simula Labs, and will follow up to ensure an orderly transition to more web native workflows for existing users of QGIS in due time.

Better Profile Selection #

This is a continuation of our GESIS collaboration. In the path to deploying dynamic image building to end users, we wanted to stabilize jupyterhub-fancy-profiles enough to deploy to users of VEDA (and eventually everyone else). This is the primary interface users see after they log in to JupyterHub, and was ripe for UX improvements. The default interface looks like this:

The revamped one is much more streamlined and looks like this:

Revamped Profile Screen

This is currently deployed to a staging hub and has helped us shake out a lot of bugs! We expect the improved interface will be rolled out to all users in the near future. We are also planning further development to make the user experience even better and smoother for everyone.

Supporting workshops #

End users benefiting from our work is what ultimately gives meaning to our work. To that end, we were very happy to support running workshops during this collaboration – see our related blog post US Greenhouse Gas Center supports summer school at CIRA for more information.

Ongoing Collaboration #

Delivering on these objectives in a timely way heavily depended on the success of the team collaboration. Sanjay Bhangar of Development Seed commented

Working closely with the 2i2c team on growing features to support users on the VEDA and GHG Center hubs has been absolutely amazing. With 2i2c’s deep experience in the Jupyter ecosystem, we have been able to implement some fairly complex features quite easily, and their strong open-source roots have ensured that whatever we work on is broadly useful to the wider Jupyter and scientific computing communities.

Take a look at the companion Development Seed blog post of this work.

This collaboration continues, and we have now published our objectives for the coming quarter. Watch this space!

Acknowledgements #

Development Seed
NASA IMPACT
Tarashish Mishra, Julia Signell, Oliver Roick, Slesa Adhikari and Sanjay Bhangar for various code contributions towards these objectives

Openscapes Host a Surface Biology and Geology Workshop with Shared Password Feature

Tue, 09 Jul 2024 00:00:00 +0000

Thanks to Brianna Lind, Julia Lowndes and Andy Teucher for contributing to this blog post!

Surface Biology and Geology: VITALS Workshop

Openscapes is a value-based initiative that supports kinder, better science based on open source community. NASA Openscapes is in its fourth year as a project supporting NASA Earth science in the Cloud, co-developed by Julia Lowndes (Openscapes) and Erin Robinson (Metadata Game Changers).

The initiative recently supported the Surface Biology and Geology: VITALS Workshop hosted by NASA Land Processes Distributed Activate Archive Center (LP DAAC) and NASA Jet Propulsion Laboratory (JPL).

Instructors used the 2i2c Openscapes Hub to lead hands-on exercises teaching learners how to manipulate data collected from the ECOSTRESS and EMIT instruments onboard the International Space Station. They used Jupyter notebooks in the Hub to demonstrate how open source tools together with cloud data and compute resources could effectively analyse the the Canopy Water Content and the Land Surface Temperature over the Jack and Laura Dangermond Preserve, Santa Barbara, CA.

Plot of the Canopy Water Content over the Jack and Laura Dangermond Preserve, Santa Barbara, CA from a VITALS Workshop Jupyter notebook.

This event was attended by around 250 participants. An event of this size therefore requires a frictionless login flow so that organizers could focus on the essential complexity of teaching data analysis rather than the accidental complexity of managing Hub authorization. GitHub authentication is the default option for most 2i2c Hubs for research use cases, but for an educational event of this size this option was not fit for purpose since organizers had to

Retrieve the GitHub usernames of each participant (assuming everyone was familiar with GitHub!)
Manually invite GitHub users to a GitHub organization to authorize access to the Hub (invitations would expire within seven days)
Repeat the above two steps last-minute for participants who showed up on the day without preparing
Manually remove GitHub users from the GitHub organization if they wanted to revoke access to the Hub after the event.

In response to this need, we developed a shared password feature so that workshop organizers can simply hand the share password out to learners for access to the Hub. This bypassed the manual labour of managing GitHub accounts while not adding to the learner’s high cognitive load and improving the participant’s learning experience overall.

One of the elements that enabled us to recognize and solve this issue effectively is our close partnership with the Openscapes team. We engage in regular 6-weekly catch-ups where we can learn about user requirements and how we can develop our infrastructure to co-create optimal solutions. Together with our Product Delivery Flow, we were quickly able to architect the shared password solution in time for the workshop.

Feedback from Brianna Lind (LP DAAC)

We have documented the technical infrastructure changes required to enable a shared password for the Hub in our Infrastructure Guide and hope to support many future events with this mechanism!

Acknowledgements #

Determining Climate Risks with NASA Earthdata Cloud at Scipy 2024

Mon, 08 Jul 2024 00:00:00 +0000

Determining Climate Risks with NASA Earthdata Cloud is a ScienceCore curriculum module that comprises part of NASA’s Open Science and Transform to Open Science (TOPS) initiatives. The aim of this module is to deliver a hands-on experience with “data-proximate computing” in the cloud with NASA Earthdata products with content co-developed with MetaDocencia.

This module was delivered as a SciPy tutorial at this year’s conference. 2i2c have been working closely with the organizers to provide the hub infrastructure for the tutorial, including enabling a shared password for easy authentication (see our Openscapes post for more about this feature) and operating a small binder service for participants to view content after the event.

You can take a look at the tutorial on the NASA ephemeral hub!

The event was well-attended, with 40 learners taking part. Special thanks go to the organizers Dhavide Aruliah, Karthik Venkataramani and Patricia A. Loto for leading the tutorial.

Acknowledgements #

NASA F.14 Transform to Open Science Training award NNH23ZDA001N-TOPST
MetaDocencia
Dhavide Aruliah
Karthik Venkataramani
Patricia A. Loto

Enabling neuroscience in the cloud with HHMI Spyglass and MySQL on JupyterHub

Fri, 05 Jul 2024 00:00:00 +0000

The HHMI Spyglass tutorial

Spyglass #

Spyglass is a framework for reproducible and shareable neuroscience research produced by Loren Frank’s lab at the University of California, San Francisco. Check out our blog post about the release of their preprint to read more about the methods.

This post focuses on the complex data storage needed for the project, which can be difficult to set up locally or at scale in the cloud. In particular, the analysis needed a MySQL database for reproducibility. This is a fairly common task across many fields. The aim of 2i2c is to enable researchers to focus on the essential complexity of what they were doing, i.e. the science, without managing the accidental complexity of how to do it – in this case, setting up databases.

We describe how you can do this too for your own JupyterHubs. Since 2i2c commits to running our infrastructure in line with open-source values as much as possible, you can also directly see the configuration for the hub referenced in the paper.

What is a “sidecar container”? #

The Kubernetes definition of a sidecar container is

Sidecar containers are the secondary containers that run along with the main application container within the same Pod. These containers are used to enhance or to extend the functionality of the primary app container by providing additional services, or functionality such as logging, monitoring, security, or data synchronization, without directly altering the primary application code.

In this case, the primary app container is the JupyterLab instance where people are interactively running code and doing science. We want to provide a MySQL database as a sidecar so that each user server gets their own independent MySQL server instance (that is not accessible to anyone else). We can then run code such as

%%bash
mysql -h 127.0.0.1 -u root --password=tutorial < path-to-sql-file-with-data

to load data into the database. Note the IP address 127.0.0.1 - the MySQL server is listening on localhost, even though it is not running in the same container! Thanks to the magic of Linux Network Namespaces, the sidecar and main app container can share 127.0.0.1. This allows you to write code that works in the exact same way on a user’s local computers as on the JupyterHub, making transitions and replication easier.

Setting up sidecars in JupyterHub on Kubernetes #

We’re leveraging multiple tools from the open-source ecosystem - JupyterHub, Kubernetes, Linux as well as MySQL itself.

Since this is a Kubernetes feature, we can pass through config to it. There are two layers here, which are

singleuser.extraContainers in z2jh configuration
KubeSpawner.extra_containers in KubeSpawner configuration

The hub configuration looks like

 singleuser:
 extraContainers:
 - name: mysql
 image: datajoint/mysql:8.0 # following the spyglass tutorial at https://lorenfranklab.github.io/spyglass/latest/notebooks/00_Setup/#existing-database
 ports:
 - name: mysql
 containerPort: 3306
 resources:
 limits:
 # Best effort only. No more than 1 CPU, and if mysql uses more than 4G, restart it
 memory: 4Gi
 cpu: 1.0
 requests:
 # If we don't set requests, k8s sets requests == limits!
 # So we set something tiny
 memory: 64Mi
 cpu: 0.01
 env:
 # Configured using the env vars documented in https://lorenfranklab.github.io/spyglass/latest/notebooks/00_Setup/#existing-database
 - name: MYSQL_ROOT_PASSWORD
 value: "tutorial"

By setting this up, we allow users to insert the code snippet above

%%bash
mysql -h 127.0.0.1 -u root --password=tutorial < path-to-sql-file-with-data

into their Jupyter Notebooks, which gives access to their MySQL database in the hub!

However, this configuration does not include permanently store the database itself between hub server sessions. Thanks to a pilot in a prior collaboration with University of Texas, Austin, we do have some documentation on how you can enable that as well!

Acknowledgements #

Howard Hughes Medical Institute
National Institute of Mental Health (NIMH), grant number RF1MH130623
kubespawner
zero-to-jupyterhub-k8s and the JupyterHub community

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. ↩︎

Ephemeral Interactive Computing for NASA Communities

Thu, 27 Jun 2024 00:00:00 +0000

We are pleased to announce that we have deployed two ephemeral hubs for NASA communities!

What did we do? #

As part of the deliverables for our NASA High Priority Open-Source Science (HPOSS) award, we deployed two new ephemeral hubs:

a public small BinderHub that offers a “reader” experience where learners can interactively view GitHub repositories that deliver light scientific content with small compute and no barriers to authentication
a big BinderHub that offers an “explorer” experience where learners can log in to access more substantial compute resources to interactively investigate large datasets and run large workflows from any GitHub repository.

These services enrich the interactive computing ecosystem for NASA communities by

improving the shareability and reproducibility of scientific information
broadening participation for historically excluded and under-resourced science communities
enabling activities such as hackathons, demonstrations or training, during workshops and conferences.

How did we do it? #

Ephemeral interactive computing services benefited from some of our previous development work in collaboration with GESIS (see our detailed blog post for more information). The research and development of this project achieved wide-reaching impact across many NASA communities we currently serve, including TOPST ScienceCore, Openscapes, US Greenhouse Gas Center, VEDA and CryoCloud; as well as networks beyond the NASA scope, such as the NSF-funded Project Pythia and HHMI-funded Spyglass projects.

What next? #

We will focus on bolstering the community- and knowledge-building needed for making the best use of these binder services in the next phase of our HPOSS work to accelerate broader participation in science. This includes opportunities such as running workshops and tutorials, as well as disseminating best practices for collaborative research. Further engineering developments will proceed in collaboration with the NASA VEDA project to set up a binder service, improve the sharing of custom environments, and refine QGIS integrations for analysing geospatial data.

Can I use this ephemeral hub service? #

The answer is yes!

For the public small BinderHub anyone can view GitHub repositories that deliver light scientific content with small compute and no barriers to authentication
For the big BinderHub you will need to be member of a NASA community. This requires a GitHub account for membership of the GitHub Team 2i2c-nasa-binder-access:big-binder-team for authorization. Please send us an email at binder-requests@2i2c.org to be added to the GitHub Team.

Acknowledgements #

NASA NSPIRES F.15 High Priority Open-Source Science Award NNH22ZDA001N-HPOSS

Neurohackademy Summer School in Neuroimaging and Data Science 2024

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

Neurohackademy Summer School

2i2c are pleased to support the Neurohackademy Summer School in neuroimaging and data science again!

Following the success of our collaboration in previous years (see the event page for 2023), this year’s course will be held July 29th – August 10th, 2024 and will be hosted by the University of Washington eScience Institute.

We provide an interactive computing platform for participants to get hands on experience in data pipelining, machine learning and data visualization techniques. Take a look at the following links to learn more about the neurohackathon:

Acknowledgements #

Funded by grant R25MH112480 from the US National Institute of Mental Health awarded to Ariel Rokem and Noah Benson.

The Neurohackademy Summer School is sponsored by

US Greenhouse Gas Center supports summer school at CIRA

Thu, 20 Jun 2024 00:00:00 +0000

Summer school for inverse modeling of greenhouse gases 2024

The Cooperative Institute for Research in the Atmosphere ( CIRA) is an interdisciplinary cooperation between NOAA research scientists and Colorado State University. CIRA is hosting a summer school for inverse modeling of greenhouse gases using atmospheric data assimilation techniques. The US Greenhouse Gas Center is supporting the workshop by providing 40+ attendees access to their interactive computing hub operated by 2i2c (see our blog post about their launch).

Hub administrators have built a customized software environment with container technology for use at the workshop. In doing so, this bypasses the need for participants to individually install software on their own machines and the online hub provides a consistent and reproducible interactive computing environment that is easily accessible and scalable.

Acknowledgements #

2i2c would like to credit the following individuals for their great efforts supporting this workshop:

Sanjay Bhangar ( Development seed)
Slesa Adhikari (NASA IMPACT)

Hacking the Project Pythia Cook-off with MyST Markdown

Tue, 18 Jun 2024 00:00:00 +0000

Photo courtesy of Dr Debanjana Das

What is Project Pythia? #

Project Pythia is the education working group for Pangeo, a community platform for Big Data geoscience in which 2i2c operates a cloud hub. The core aim of Project Pythia is to spearhead the creation and curation of community-driven, open-source documentation, in the form of “cookbooks”, to enable the adoption of open, scalable and reproducible workflows for geoscientists.

What did 2i2c do? #

Jenny, James and Angus from the 2i2c team participated in the annual Project Pythia Cook-off 2024, a hackathon where cookbook authors and collaborators can spend dedicated time on creating and maintaining their content using Jupyter Book and deploying their cookbooks with GitHub actions.

2i2c teamed up with the infrastructure breakout group during the hackathon, led by Katelyn FitzGerald ( UCAR) and Kevin Tyle ( University at Albany), and members of the Curvenote team also joined the group.

Day 1 #

2i2c deployed and demonstrated a dedicated BinderHub service for Project Pythia that allowed hackathon participants to “self-serve” images of their software environment, which were specified by including a list of packages in an environment.yml file placed in their GitHub cookbook repository. Participants could then pull the image from a container registry into their 2i2c hub (or indeed, any other JupyterHub server) to share and reproduce their computational environments with ease.

Day 2 #

During the first half of the day, we quickly identified a number of issues that were proving to be a maintenance headache for the Project Pythia infrastructure group:

Configuration files for each cookbook were difficult to update at scale. Project Pythia currently have a gallery of over 30 cookbooks!
Changes to Sphinx-based themes inherited from upstream were prone to breaking custom Project Pythia branding downstream.
Executable content was not able to run on the Project Pythia’s dedicated BinderHub hosted on JetStream2 (operated by NSF).
Cookbooks frequently cross-referenced materials from other cookbooks to build upon pre-existing knowledge, but this was not easy to author and the reader experience was not as smooth as it could be.

Following the announcement that Jupyter Book 2.0 will use MyST last month, Rowan (Curvenote) and Angus (2i2c) delivered a compelling demonstration of the MyST ecosystem centered around modern web-first technologies (JavaScript/TypeScript) that offers improved interactivity and accessibility.

In the second half of the day, we decided to use the hackathon to explore migrating the Pythia cookbooks from using a Sphinx-based to a MyST-based document structure and engine. Within one afternoon, the group migrated four cookbooks to use MyST MD

This moment was palpably exciting! It was evident that MyST MD supported backwards compatible content out of the box, which alleviated fears of sunk cost into existing Sphinx-based cookbooks. The migration workflow was as simple as executing the following commands

conda install mystmd

myst.

Day 3 #

We spent this day tackling support for managing a gallery of Project Pythia cookbooks at scale. See the Executable Books blog post for technical details on how we

Centralized configuration
Prototyped a gallery plugin in Python
Fixed a number of bugs related to integrated computation with Binder and JupyterLite
Embraced the referencing and reuse of content with simple markdown syntax for hover-references.

Day 4 #

Looking to the future, we spent time reflecting on our experiences and discussing the potential, transformative impact MyST MD tooling could have in the hands of the scientific community at large, including the communities served by 2i2c. Knowledge-sharing based on static figures and PDFs would fall obsolete and give way to a dynamic, web-first approach to sharing interactive narratives backed by compute from a Jupyter server.

Throughout the course of the hackathon, the rate of iterated development for both end users of the community cookbook and the developers of the open-source tooling was astounding. For example, we were able to quickly expose small bugs ( e.g. support for HTML video tags) in the MyST MD tooling, which were immediately fixed upstream and released within minutes. The feedback loop that connected the user experience with the software tooling was incredibly synergistic, with immediate impact both upstream and downstream that 2i2c hopes to continue replicating across many facets of their operations.

Beyond the Project Pythia Cook-off, the breakout group will continue conversations around strengthening their community of practice and hopefully advocating for wider adoption of MyST MD amongst the scientific community (say hello to some of our group members at SciPy 2024 in July!).

Acknowledgements #

University at Albany (NSF award 2324302): Led the funding acquisition, helped organize and facilitate the event
UCAR (NSF award 2324303): Led the planning and logistics for the event
Project Pythia for organizing this workshop.
Jupyter Book for providing development and collaboration at this workshop.
2i2c / Code for Science and Society (NSF award 2324304): Provided tailored compute services and on-site support
Curvenote: Contributed engineering cycles to MyST MD development.

Towards scalable and sustainable networks of community hubs

Tue, 18 Jun 2024 00:00:00 +0000

Over the past several years, 2i2c has built a platform for serving community-centric hubs that provide a digital home for workflows in creating and sharing knowledge. See our three-year retrospective for a report about the growth and impact this service has had.

During that time, we’ve experimented with several models for funding and sustaining this infrastructure. We’ve tried everything from direct cost-recovery from individual communities, to institutional contracts that cover several hubs, to grant-based models that fund many communities at the same time.

There are pros and cons associated with each, and we believe that a combination of all of them is important for a long-term service sustainability model for 2i2c. However, with this post we’d like to share the community funding model that strikes the right balance between short-term sustainability and scalability.

In short: 2i2c aims to serve networks of communities that are joined by a domain or workflow, and fund the network at once rather than through one-on-one contracts.

A model of the funding and service relationships we aim to build.

We believe that this model strikes a balance between “scalable and very simple hubs” (which require a lot of administrative toil) and “fully bespoke hubs” (which are expensive and unscalable). By using a single funding contract to serve many communities, we can reduce the amount of sales and contracting toil for each community. This will let us raise funds more quickly, and focus more of our time on delivering service.

We are seeking community leaders to collaborate #

If you’re part of one or more communities that would benefit from cloud infrastructure for creating and sharing knowledge, and believe a network like this would benefit you, please reach out! We are seeking leaders collaborate in designing service for networks like the ones described above, and identifying potential funding sources for it.

If you’re interested in collaborating on this, send an e-mail to partnerships@2i2c.org.

Learn more #

You can find more information about this fundraising and service strategy in our Team Compass documentation.

Acknowledgments #

Support for organizational and strategic work like this is provided by a grant from CZI.

Low storage alerting for the UToronto cluster

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

The UToronto hub landing page

2i2c has operated The University of Toronto hub since 2021 and this hub supports over 6000 educators and learners in a day! With a community of this size, file storage can quickly grow out of control and cause issues.

The 2i2c engineering team have implemented a low storage alerting system for Microsoft Azure, so that they can pre-emptively take remedial action before the filesystem is about to run out of diskspace.

Great job team 🚀

UToronto hub usage

Howard Hughes Medical Institute publishes preprint on Spyglass, a framework for reproducible and shareable neuroscience research

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

Spyglass landing page

Spyglass is a framework for reproducible and shareable neuroscience research produced by Loren Frank’s lab at the University of California, San Francisco. They recently released a preprint about their toolbox, and are using a 2i2c hub to provide accessible interactive cloud environments that demonstrate its functionality and helps researchers get started.

Acknowledgements #

Thanks to HHMI for funding and collaborating on this work.

Jupyter Book 2.0 will use MyST

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

See the Executable Books blog for a post on the future directions of the Jupyter Book project, which will be built on top of the MyST Markdown engine.

Acknowledgements #

This post relates to our ongoing collaboration with the Jupyter Book project.
Thanks to Project Pythia for funding part of our work on Jupyter Book.

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 ↩︎

An update to 2i2c's value proposition

Mon, 06 May 2024 00:00:00 +0000

2i2c recently finished it’s three year retrospective after closing out its original seed grant. As part of this process, we’re revisiting our organizational strategy, structure, and overall plan, in order to incorporate the learning that we’ve done over our first three years.

Our value proposition is a key framing for 2i2c’s intended impact, key stakeholders, and platform strategy. We recently completed a team exercise to refine this statement for 2i2c, and are excited to share it with you below:

A global network of community hubs for interactive learning and discovery

Our interactive computing platform gives your community a digital home to create and share knowledge, and a global network of communities to learn from.

This is an exciting direction that leans into and builds upon the way we’ve described our service so far. It recognizes that the value in our service doesn’t end with simple access to an interactive computing environment, but lies in how that environment’s tools empower a community to create and share knowledge with one another.

We believe that this is an exciting direction to build towards, because it is based in the value of the collection of communities we serve, and the way that this network can be greater than the sum of its parts. We’re excited to lean into this direction in how we shape our platform, what open source contributions we make, and where we aim to have impact in the coming years.

To begin, we’ve interwoven some ideas from this value proposition into 2i2c.org, and the way that we describe our service. We’d love feedback from anyone who has an idea, a critique, or “yes, and” to share.

A recent talk with this value proposition #

As part of this work, 2i2c’s Executive Director, Chris Holdgraf, gave a talk about 2i2c to the Incentivizing Open and Collaborative Research (ICOR) community. Here are some links in case others are interested:

Here’s the video below for quick reference:

Data Sharing and Analysis in Collaborative Open Research Environments from Michael Markie on Vimeo.

Acknowledgments #

Support for organizational and strategic work like this is provided by a grant from CZI and fees from our Member Communities.

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.

Security report for jupyter-server-proxy: CVE-2024-28179

Tue, 19 Mar 2024 00:00:00 +0000

What happened? #

A few weeks ago, the JupyterHub team discovered a security vulnerability in the jupyter-server-proxy package that would allow potential unauthenticated access to a JupyterHub via WebSockets, allowing unauthenticated users to run arbitrary code on the JupyterHub. jupyter-server-proxy is used by many communities to provide alternative user interfaces like RStudio and remote desktops.

This vulnerability was detected by the JupyterHub team, with leadership from 2i2c’s engineers. It was resolved through upstream contributions to the JupyterHub project, and we have deployed a fix that mitigates this vulnerability for all the hubs 2i2c manages.

Does this impact my 2i2c community hub? #

We do not believe that any of 2i2c’s communities were impacted by this vulnerability, and a patch has now been pushed to all community hubs to resolve this issue.

If your community was vulnerable to this problem, you might experience slightly slower startup latency while we work out a long-term solution.

Since this is a vulnerability in the docker image used by our communities, we will be reaching out over the next few weeks to put a more permanent fix in place.

Where can I learn more? #

See the JupyterHub security advisory for CVE-2024-28179 for more information about the security vulnerability, including details on the mitigation we have put in place to protect our communities.

Conclusion #

We’re grateful that the JupyterHub community was quick to acknowledge, respond, and resolve this security vulnerability after it was brought to their attention. We’re also proud that 2i2c’s engineers helped the JupyterHub team throughout the process.

This allowed our team to resolve the problem before it impacted any of 2i2c’s communities. Because 2i2c community infrastructure is managed in a central location, we were able to resolve this for over 80 communities with a single team rather than expecting each community to learn about and fix this problem on their own.

We also believe this reflects the healthy upstream relationships that we hope to encourage with our team’s Open Source strategy and practices. By working with the JupyterHub community and pushing changes upstream, we’ve resolved this issue for any user of jupyter-server-proxy, not just 2i2c’s own ecosystem. In particular, because of 2i2c’s position running hubs for many communities via Kubernetes, we were able to identify a solution that did not require every user image to be updated (as described in section For JupyterHub admins of Z2JH installations).

We believe that all of these lead to a healthier, safer ecosystem of open source tools ❤️.

A three year retrospective report of 2i2c's impact

Fri, 01 Mar 2024 00:00:00 +0000

We’re pleased to share a three-year retrospective report that was created to close-out 2i2c’s original seed funding grant provided by the Chan Zuckerberg Initiative.

See the Zenodo entry here:
See the MyST website for the report at 2i2c.org/report-czi-2021.
Download a PDF version generated by MyST here.

This report was written with the new MyST Markdown document engine and shows off some of the functionality that we’ve been working on in collaboration with the MyST team.

We’re incredibly grateful for the seed funding that CZI provided to kickstart 2i2c’s mission and operations, and excited about more impact to come!

Integrating BinderHub with JupyterHub: Empowering users to manage their own environments

Wed, 03 Jan 2024 16:56:14 -0800

Thanks to Arnim Bleier, Jenny Wong, Georgiana Elena, Damián Avila, Jim Colliander and James Munroe for contributing to this blog post

mybinder.org is a very popular service that allows end users to specify and share the environment (languages, packages, etc) required for their notebooks to run correctly by placing configuration files they are already familiar with (like requirements.txt or environment.yml) along with their notebooks. While not without its own set of challenges, this is extremely powerful because it puts control of the environment in the hands of the people who write the code. They can customize the environment to fit the needs of their code, instead of having to fit their code into the environment that admins have made available.

But, mybinder.org (and the BinderHub software that powers it) is built for sharing your work after you are done with it, not for actively doing work. BinderHubs often do not have persistent storage nor persistent user identity, and UX is centered around ephemeral interactivity that can be shared with others (via a link), rather than persistent interactivity that a single user repeatedly comes back to. JupyterHub is more commonly used for this kinda workflow, but doesn’t currently have the ability for users to easily build their own environments. Admins who are running the JupyterHub can make multiple environments available for users to choose from, but this still puts admins in the critical path for environment customization.

Our collaboration with GESIS, NFDI4DS, and CESSDA, aims to bring this flexibility to JupyterHub directly. We aim to empower users to decide for themselves which applications and dependencies are installed on a per-project basis. Our work enables communities with heterogeneous requirements to share a single Hub. Our approach frees administrators from being overwhelmed by installation requests and transforms the JupyterHub platform into a platform for collaborative computational reproducibility. In this update, we report on our progress and upcoming steps in this project.

What does a BinderHub do, exactly? #

It is helpful to understand that BinderHub primarily has 3 responsibilities:

Present a UI to the end user for them to provide details on what to build (this is what you see when you go to mybinder.org)
Call out to repo2docker in a scalable way to actually build and push an image containing the environment for the given repository, and show the user logs as this build process happens. This also allows users to debug issues with their build more easily.
Talk to a JupyterHub instance to launch a user server with the built docker image, and redirect the user to this.

(2) is really the core feature of BinderHub, and we settled on figuring out how to make that available to JupyterHub users. It was really important to us that this was also done in a way that can be sustainably used by everyone, not just 2i2c. This blog post discusses the various improvements to the broad ecosystem of projects in the Jupyter ecosystem to get this done.

Demo #

But first, a very quick demo of how this looks like right now now!

This is very much a work in progress, but the basic flow can be seen clearly. Users see a Server Options menu after they log into JupyterHub. They can specify the two primary things that determine the server configuration:

The resources allocated (RAM, CPU and maybe GPU)
The environment (container image) used, which can be specified in one of 3 ways:

a. A pre-selected list of environments (container images), provided by the administrators who set up this JupyterHub b. A blank text box where you can enter any publicly available docker image they want c. A mybinder.org style way to specify a GitHub repository, which will be then dynamically built into a docker image for the user!

So what did we need to do to accomplish this, in a way that’s very upstream friendly and usable by everyone (and not just 2i2c)?

A Standalone `binderhub-service` helm chart #

The default upstream BinderHub helm chart includes a JupyterHub as a dependency, and configures itself to be used primarily in a manner similar to mybinder.org. As the person who helped make that choice early on, I can tell you why it was made - for convenience! And it was very convenient, as it allowed us to get mybinder.org going fast. However, it makes it difficult to install a BinderHub service alongside an existing JupyterHub. To this end, we have created a standalone BinderHub helm chart, designed to be installed alongside an existing JupyterHub, so we can use it purely to build images. This allows the BinderHub instance to be used as a JupyterHub Service, which is what we want.

While this helm chart is currently under the 2i2c GitHub org, the hope is that it can eventually migrate to a jupyterhub-contrib organization (once it is created), or it can become the upstream helm chart for BinderHub if enough work can be done in BinderHub to allow it to serve use cases like mybinder.org.

As part of this work, we also added a way for BinderHub to run in API only mode, so we can fully turn off the UI and launching ability of BinderHub. This change decoupled the three responsibilities of BinderHub we discussed previously, allowing us to bring our own UI and JupyterHub. BinderHub could now be used purely for its scalable image building features, which is exactly what we want!

Sustainably extending KubeSpawner’s `profileList` #

We identified KubeSpawner’s profileList feature as the ideal location for UI to dynamically build environments (container images), making it just another ’environment choice’ people can choose, along with picking the resources their server needs. From an end-user perspective, it was also the logical place for them to specify a repository to build into an environment, as they could already choose some pre-built environments from here. They can also select other arbitrary resources they want (such as memory, GPU, etc) from here as well. From a maintainer perspective, it helps with long-term maintenance of the JupyterHub projects.

The implementation of profileList however, was not easy to extend at this point. So this PR improved how easy it was to extend it in more complex ways, without making the implementation in KubeSpawner itself complicated. Even though this had no visible end-user effects, it was an extremely important step in allowing us to experiment with UI in a sustainable way without having to rely on upstream. These kinds of changes can sometimes be hard to sell to stakeholders but are extremely important in ensuring a continuous and sustainable relationship with upstream.

Implementing `unlisted_choice` feature in KubeSpawner #

The profileList feature was built to allow JupyterHub admins to specify an explicit list of container images the end-user can choose from. It did not have a way for any choice that was not pre-approved by the admin to be used. We needed this feature since the BinderHub API will build a new docker image for each environment the user wants, and so this can not be chosen from a pre-approved list. We had to safely add this feature to KubeSpawner in such a way that it was generally useful to everyone. Many other communities had been asking for such a feature anyway - the ability to simply ’type in’ an image and have that be used.

NASA VEDA was one such community, so we partnered with Sanjay Bhangar from Development Seed (an organization that helps run NASA VEDA) to implement this feature. Engineers from 2i2c contributed heavily to this feature as well, and after several PRs ( 1, 2, 3, 4 and 5), this feature is now available for everyone to use!

A key component of doing sustainable upstream work is that every addition needs to be useful by itself for a broad group of people. This change was very helpful for many communities that wanted to allow their users the freedom to pick whatever image they want to use, regardless of wether they wanted to use dynamic image building or not. The broad interest allowed us to build a coalition with other interested parties, and get the change accepted upstream more easily!

`jupyterhub-fancy-profiles` #

Once we had all these pieces in place, it was time to actually work on the frontend UI that would allow users to build images dynamically and launch them. Since this will replace the ‘profileList’ feature, it should also allow them to select different resources (RAM, CPU, etc) as needed, as well as type in an existing image if they desire. So it was a full re-implementation of the profileList frontend.

This is ongoing now at the jupyterhub-fancy-profiles project. It is a pure frontend web application, using modern frontend tooling ( React, webpack, Babel, etc) and written in JavaScript. It’s gone through a few revisions, but the demo provided earlier in the blog post is in its current state. Because the default profileList implementation is pure HTML / CSS with very minimal JS, it is limited in what kind of UX it could have. jupyterhub-fancy-profiles aims to be very helpful even when dynamic image-building features are not enabled on a JupyterHub. We hope to roll this out to a few JupyterHubs and improve it over time based on feedback.

`jupyterhub/@binderhub-client` npm package #

While building jupyterhub-fancy-profiles, we wanted to use the same javascript code used by BinderHub frontend to interact with the BinderHub API, instead of re-implementing it. However, the existing BinderHub JavaScript code was not easily consumable by external projects. We refactored the code, added tests, migrated to use modern JS practices and published the jupyterhub/@binderhub-client NPM package that can be used not just by jupyerhub-fancy-profiles but any external project for talking to the BinderHub API.

This had to be done in such a way that current BinderHub installations (such as mybinder.org) do not break. That took quite a few pull requests: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15. This refactoring work was very helpful to us, and also appreciated by the broader community.

Defending against cryptojacking with `cryptnono` #

For Open Science to flourish, we need to allow access to resources without login / paywalls wherever possible. A new menace against this has been cryptojacking - where attackers use up any and all available free compute to mine cryptocurrencies. This has affected many folks on the internet, including GitHub Actions and mybinder.org, the primary public BinderHub installation. mybinder.org has some extra protections against cryptojacking that aren’t easily usable elsewhere, and this has unfortunately meant that the demo JupyterHubs we have with these features enabled have been behind a login wall. I personally believe login walls are long term antithetical to open science, and so this was an important problem to solve.

cryptnono is an open source project designed to help fight cryptojacking, and as part of this grant we ported some of this functionality out of mybinder.org specific code into cryptnono, so other deployments may also benefit from it! We also migrated to using the super efficient ebpf Linux Kernel subsystem, allowing for more complex heuristics to catch a much broader range of cryptomining activity. We have been slowly tweaking the config on mybinder.org, and it has proven to be very effective! This will be very helpful for anyone who wants to provide a JupyterHub (or any other computational service) without a login wall. If you are interested in using cryptnono in this fashion, please reach out to us so we can work together!

Explored pathways that were then discarded #

List of things that were tried and then decided as not good pathways:

repo2docker-service, a separate JupyterHub service that could only build images. As we worked on it, we realized that it was replicating a lot of features that BinderHub already has, so we pivoted to working on BinderHub directly instead.
Building off of tljh-repo2docker. While this already had a nice UI, it would be hard to port it to run on a distributed Kubernetes environment without it becoming a ‘hard fork’.

While these did slow down the implementation of the project, it has allowed us to be very confident that the methods we have chosen are long-term sustainable.

Want to try this out? #

We have a demo of this running at imagebuilding-demo.2i2c.cloud, but unfortunately as we are still fine-tuning cryptnono config, at this moment it is not open to the public. Please contact me with your GitHub account if you want access, and promise to not be a cryptominer and you shall be granted access.

Want to set this up on your own JupyterHub? There is some work in progress documentation and more is being worked on. Drop a line in the linked pull request and we’ll be happy to help. The eventual goal is for anyone to be able to simply follow documentation and set this up for themselves.

We also have user facing documentation on using this service on docs.2i2c.org.

Future work #

This is not complete of course, and there is a lot of future work to be done.

mybinder.org also helps you distribute your content, not just the environment for your code to run in. Since JupyterHub usually comes with a persistent home directory for the user, nbgitpuller is commonly used for this purpose instead. We should explore ways to integrate nbgitpuller (and other ways to distribute content) in the future.
More thorough documentation for how you can recreate what is in the demo for yourself in your own JupyterHub installation.
Better UX for specifying images, including figuring out how to ‘save’ them for future reuse.
Better compatibility with mybinder.org, particularly in allowing other sources of environments (not just GitHub, but Zenodo, raw git repositories, etc) and URL compatibility.
Better authentication workflow between the frontend and the BinderHub API.

Credit #

All this work would not be possible without a large group of collaborators!

From 2i2c: Erik Sundell, Georgiana Elena, Yuvi, James Munroe, and Damián Avila.
The persistent BinderHub project was the direct inspiration for all this work, with particular thanks to Kenan Erdogan.
The tljh-repo2docker project, which explores similar ideas in the context of running only on a single node.
The broad JupyterHub and MyBinder.org community, particularly Simon Li and MinRK.
Funding generously provided by GESIS in cooperation with NFDI4DS (project number: 460234259) and CESSDA.
Arnim Bleier from GESIS was instrumental in making this project happen.

Digital public goods for Earth system management: U.S. Greenhouse Gas Center launches

Tue, 05 Dec 2023 00:00:00 +0000

Abstract

The International Interactive Computing Collaboration ( 2i2c.org), working with NASA VEDA, Development Seed and other partners, operates an interactive computing platform for The U.S. Greenhouse Gas Center. The U.S. GHG Center, announced yesterday at the 28th annual United Nations Climate Conference (COP-28) in Dubai, is an interagency collaboration of the Environmental Protection Agency (EPA), the National Aeronautics and Space Administration (NASA), the National Institute of Standards and Technology (NIST), and the National Ocean and Atmospheric Administration (NOAA). This note places the launch of the U.S. GHG Center in a scientific, international, and national context and argues that similar digital public goods are needed for humanity to understand and manage the Earth system.

Scientific Context #

It was controversial in 1827 when Joseph Fourier (the discoverer of the law of heat conduction) argued ¹ that the atmosphere keeps the Earth warm, like a puffy down comforter, but it’s not now. Gases in the atmosphere trap heat near Earth. How much heat is trapped depends on the gas mixture. Putting more heat-trapping gases in is like putting a wool blanket on top of the down comforter. Human activity since industrialization is injecting lots more heat-trapping gas into the atmosphere and changing the Earth’s climate.

The science is clear. The up-to-date consensus view of the global scientific community is expressed in the Sixth Assessment Report of the Intergovernmental Panel on Climate Change (IPCC):

International Context #

The international community officially recognized human-influenced climate change at the World Climate Conference (WCC-1) ² in 1979. The 1979 declarationis remarkably prescient and detailed. A complex and interconnected collection of scientific and diplomatic activities were catalyzed by WCC-1. Some important milestones from this history are captured in the chart and numbered list below.

gantt dateFormat YYYY-MM-DD title International Climate Change Milestones section Study WCC-1 (1979) :crit, done, admin0, 1979-02-12, 1979-02-23 WCP :crit, adminA, 1979-06-01, 2025-12-31 CMIP1: crit, done, adminT, 1995-01-01,1995-12-31 CMIP2: crit, done, adminR, 1997-01-01, 1998-12-31 CMIP2+: crit,done,adminS, 2000-05-09, 2001-12-31 CMIP3 :crit, done, adminP, 2004-10-01, 2006-12-31 CMIP5 :crit, done, adminO, 2008-09-01, 2013-03-15 CMIP6 :crit, done, adminQ, 2014-02-01, 2024-12-31 IPCC :crit, admin1, 1988-12-06, 2025-12-31 IPCC-AR1 :crit, done, adminH, 1990-08-01, 1992-06-30 IPCC-AR2 :crit, done, adminI, 1995-01-01,1995-12-31 IPCC-AR3 :crit,done, adminJ, 2001-01-01, 2001-12-31 IPCC-AR4 :crit, done,adminK, 2007-01-01,2007-12-31 IPCC awarded Nobel Prize :crit, done, adminN, 2007-10-12, 2007-11-12 IPCC-AR5 :crit,done,adminL, 2014-01-01,2014-12-31 IPCC-AR6 :crit,done,adminM,2023-01-01,2023-12-31 section Treaties Rio Earth Summit (1992) :crit, done, adminC, 1992-06-03, 1992-06-14 UNFCC :crit, admin2, 1994-03-21, 2025-12-31 Berlin (COP-1) :crit, done, adminE, 1995-03-28, 1995-04-07 Byrd-Hagel Resolution :crit, done, adminX, 1997-07-25, 1997-07-30 Kyoto (COP-3) :crit, done, adminD, 1997-12-01, 1997-12-10 Kyoto Protocol :crit, done, admin3, 1997-12-11, 2020-12-31 Paris (COP-21) :crit, done, adminF, 2015-11-30, 2015-12-12 Paris Agreement :crit, adminG, 2016-11-04, 2025-12-31 Glasgow (COP-26) :crit, done, adminV, 2021-10-31, 2021-11-12 Dubai (COP-28) :crit, adminW, 2023-11-20, 2023-12-12 ETF :crit, adminU, 2024-01-01, 2025-12-31

The table above describes a subset (for a more systematic review see ³, ⁴) of key milestones in global efforts to understand and address climate change. A glossary of acronyms and additional background:

The First World Climate Conference (WCC-1) ² was held in 1979.
The World Climate Programme ( WCP), an activity overseen by the World Meteorological Organization was established after WCC-1. WCP, in partnership with other organizations, operates programs (e.g. the World Climate Research Program (WCRP)) that organize and integrate international scientific efforts to understand the climate. The WMO also operates the Integrated Global Greenhouse Gas Information System (IG3IS), a natural partner for the emerging work described below.
WCRP manages the Common Model Intercomparison Project (CMIP). CMIP serves as a kind of league for intercomparing models of the Earth’s climate system developed by teams who approach the problems with different methods and designs. Intercomparison, an approach that enables finding the consensus views of teams with divergent approaches to problems, is used in other modeling scenarios.
Research papers on the climate are rapidly produced by scholars from essentially all knowledge disciplines. This overwhelming stream of content, like snowflakes in a blizzard, is coalesced into coherent and carefully scrutinized IPCC Assessment Reports by the Intergovernmental Panel on Climate Change (IPCC).
The Earth Summit held in Rio de Janeiro in 1992 led to the United Nations Framework Convention on Climate Change (UNFCC). The UNFCCC is an international treaty that recognizes the dangers to the climate system caused by human activity, calls for ongoing study, and establishes recurring Conference of the Parties (COP) meetings.
COP-3 (Kyoto) led to the Kyoto Protocol Treaty.
The Byrd-Hagel Resolution was a unanimous United States Senate Resolution that stipulated the United States would not sign treaties promising greenhouse gas reductions by developed countries that did not mandate similar reductions from developing countries. This killed USA participation in the Kyoto Protocol Treaty.
The Paris Agreement, established at COP-21 (Paris), effectively replaces the Kyoto Protocol, includes specifications by participant countries on greenhouse gas reductions called National Determined Contributions (NDCs). The United States entered the Paris Agreement under President Obama, exited under President Trump and rejoined under President Biden.
COP-26 (Glasgow)established an accountability system for the Paris Agreement called the Enhanced Transparency Framework (ETF). Participant countries to the Paris Agreement will submit their first Biennial Transparency Reports (BTR1) under the ETF in 2024.

🇺🇸 U.S.A. Context #

The United States Environmental Protection Agency (EPA) annually releases the Inventory of U.S. Greenhouse Gas Emissions and Sinks reports. These reports are submitted to the United Nations in accordance with the UNFCCC. The EPA openly shares software, tools, data, and builds capacity to assist other nations to assemble their own greenhouse gas inventories.

An Interagency Working Group (IWG) on the Social Cost of Carbon was set up by the Obama Administration in 2010. The IWG, renamed as the Interagency Working Group on Social Cost of Greenhouse Gases in 2016, synthesizes research on integrated assessment modelling to quantify the dollar costs associated to damage caused by an incremental increase in GHG emissions in a given year. Quantifying the impacts of GHG emissions in monetary terms is vital to effective rulemaking across the Federal Government. This EPA fact sheet on the social costs of carbon provides further background. A 2017 consensus report ⁵ of the National Academies of Science Engineering and Medicine (NASEM) offered recommendations for ongoing research to improve the assignment of social costs to GHG emissions.

Other federal agencies have developed expertise, data, and analyses that give insights into GHG emissions that compliment and potentially extend the Inventory reports developed annually by the EPA. How should the United States integrate federal agency efforts to monitor and measure greenhouse gas emissions? A 2022 NASEM consensus report ⁶ investigated this question. In January of this year, the Biden Administration released guidance⁷ for federal agencies on incorporating GHG emissions information in policies and reports. Shortly thereafter, a draft federal strategy to advance an integrated greenhouse gas monitoring system was released by NASA with a request for public input.

Some important insights from the NASEM consensus report, the draft federal strategy, and the IWG reports:

Data streams on greenhouse gas emissions can be sorted into two broad categories:
- Activity-based: Activity-based data, sometimes called “bottom-up” data, quantify GHG emissions by measuring activities that generate GHG emissions. Economic or business activity data (gallons of diesel sold in a county on Tuesday; miles flown by a 747 in October) can be converted into quantified GHG emissions information.
- Atmospheric-based: Atmosphere-based data, sometimes called “top-down” data, quantify GHG emissions by performing atmospheric measurements. For example, the Orbiting Carbon Observatory (OCO2) remotely senses $CO_2$ from space.
- A hybrid approach that blends activity-based and atmospheric-based GHG data has the potential to provide new insights.
Interoperable and easily accessed tools and data products for analyzing GHG emissions information and assigning costs should be made available across the Federal government.
GHG emissions information is needed in scenarios outside the international context of participating nations reporting for UNFCCC and Paris Agreement ETF compliance:
- Subnational governments – cities, states, provinces, counties – want GHG data products to measure their progress on emission reduction programs.
- Facilities – harbours, toll roads, power plants, factories, universities – similarly want GHG data products.
- Companies – airlines, trucking, construction – want GHG data products.
Reliable and transparent GHG emissions information is required to enable effective environmental-social-governance (ESG) investment without “greenwashing”.
Accurate and improving quantifications of the social costs associated to GHG emissions require ongoing research.

The U.S. Greenhouse Gas Center #

The launch of U.S. GHG Center, an interagency collaboration of the Environmental Protection Agency (EPA), the National Aeronautics and Space Administration (NASA), the National Institute of Standards and Technology (NIST), and the National Ocean and Atmospheric Administration (NOAA), was announced on 2023-12-04 at COP-28 (Dubai)

How much GHG emission is generated through oil and gas production? How much GHG emission is generated by urban centers? Do landfills contribute significant GHG emissions? How do human-generated GHG emissions compare to natural sources of GHG emissions? The U.S. GHG Center is designed to assemble the data, tools, and people to scientifically address these kinds of questions.

The U.S. Greenhouse Gas Center builds on EPA’s leadership to openly share the data and tools for the Inventoryand the 2023 Year of Open Science. Instead of building a walled garden with proprietary technology from a vendor selected through RFP, the Center launched a prototype platform using curated open source tools integrated with public federal data. This open toolchain approach amplifies the open data efforts developed over the past two decades.

The U.S. GHG Center’s interactive computing platform is open source science infrastructure. The platform is:

transparently operated by 2i2c on a cloud data center under a right to replicate that ensures zero vendor lock-in with data integrations and visualizations built with using software from a vibrant open source ecosystem by Development Seed, NASA VEDA, and collaborators;
proximate to and optimized ⁸ for analyzing geospatial data (e.g. NASA, NOAA);
designed to be a digital public good.

Research, data and recommendations developed by scientists and engineers that influence policies set by democratic governments should be accessible by voters. No entity should own the ways humans communicate and learn about the Earth system. The U.S. Greenhouse Gas Center’s generous approach to digital infrastructure – an open toolchain adjacent to open data – is vital for democracy and should be replicated across government agencies worldwide.

Acknowledgements #

This work was developed in collaboration with Development Seed and NASA VEDA, key partners in building the U.S. Greenhouse Gas Center’s open source science infrastructure.

References #

Mémoire sur les températures du globe terrestre et des espaces planétaires. in Oeuvres de Fourier: Publiées par les soins de Gaston Darboux (eds. Fourier, J. B. J. & Darboux, J. G.) vol. 2 95–126 (Cambridge University Press, 2013). ↩︎
World Climate Conference. World Climate Conference - Declaration and supporting documents. library.wmo.int/records/item/54699-world-climate-conference-declaration-and-supporting-documents (1979). ↩︎ ↩︎
Gupta, J. A history of international climate change policy. WIREs Climate Change 1, 636–653 (2010). ↩︎
Zillman, J. A history of climate activities. WMO Bulletin 58, (2009). ↩︎
Valuing Climate Changes: Updating Estimation of the Social Cost of Carbon Dioxide. (National Academies Press, 2017). doi: 10.17226/24651. ↩︎
Greenhouse Gas Emissions Information for Decision Making: A Framework Going Forward. (National Academies Press, 2022). doi: 10.17226/26641. ↩︎
CEQguidance. National Environmental Policy Act Guidance on Consideration of Greenhouse Gas Emissions and Climate Change. Federal Register www.federalregister.gov/documents/2023/01/09/2023-00158/national-environmental-policy-act-guidance-on-consideration-of-greenhouse-gas-emissions-and-climate (2023). ↩︎
Abernathey, R. P. et al. Cloud-Native Repositories for Big Scientific Data. Computing in Science & Engineering 23, 26–35 (2021). ↩︎

2i2c supports Jupyter Docker Stacks ARM builds

Fri, 01 Dec 2023 00:00:00 +0000

The Jupyter Docker Stacks project provides a collection of ready-to-use Docker images for Jupyter environments. These images are used by many in the Jupyter community, including 2i2c which uses them as base images for our JupyterHub deployments.

The project recently began publishing ARM-compatible images alongside the standard x86 images, making it easier for users with ARM-based systems (like M1 Macs) to use these environments. However, building and hosting these ARM images comes with additional cloud computing costs that were being personally covered by @mathbunnyru, one of the project’s maintainers.

A part of 2i2c’s mission is supporting upstream communities that we rely on, especially where the upstream project has limited resources. For this reason, we’ve decided to support Jupyter Docker Stack’s ARM building costs, with a total budget of $2000 (approximately $150 per month). As a regular user and beneficiary of the Jupyter Docker Stacks, we believe it’s important to contribute to the maintenance and sustainability of this crucial piece of infrastructure that benefits the entire Jupyter community.

We hope this support helps the Docker Stacks project remain healthy, and continue providing high-quality, multi-architecture images that work across different computing platforms. We’ll revisit this decision as the landscape of technology providers changes and other options arise.

Acknowledgments #

Thanks to Project Jupyter (particularly the jupyter-stacks team) for this project.

Community Update: October 2023

Fri, 10 Nov 2023 00:00:00 +0000

Over the past few months, we’ve been investigating ways to improve our reporting both internally and externally. We’ve decided to experiment with a monthly community update to create a regular cadence of transparency and highlights from 2i2c for our broader community. This is the first such update, so bear with us as we work out the kinks!

Our goal with these updates is to share what stands out at 2i2c - what we’ve learned, what we’re proud of, where we’ve struggled, and where we’ve had an impact. We hope this can be a historical record of “what stands out” to our team and that it is useful for our broader community to see. We also want this to be relatively short and to the point to make it sustainable to both write and read.

We’d love feedback on what else you’d like to see. If you have any ideas, please send an email to hello@2i2c.org.

Rough Numbers #

First off, a few numbers on the scale and status of our interactive computing hub service:

We are currently running around 73 JupyterHubs that are collectively averaging more than 4000 average monthly users. We have several communities in the educational sector, so October was a peak in the Fall semester of activity.

We’re recovering roughly 40% of our monthly staffing costs through recurring service revenue. The remainder we’re making up with a combination of grants and more focused development contracts.

Assuming minimal growth in our service and fundraising, our runway is roughly until August 2025 - however, we anticipate this to shrink in the short-term once we make critical new hires in the coming months.

Organization Updates #

This section describes some major organization-wide efforts we’ve started or progressed over the last month.

Improving Our Quarterly Sprints and Goals #

This month our team kicked off the second round of our new quarterly sprints and goals process. This is an attempt to focus our team around a few goals and sub-teams dedicated to them throughout each quarter. Our hope is that this allows us to make strategic “pushes” in directions that feel important for 2i2c’s operations and the communities we serve.

This quarter, we incorporated a lot of learning that took place after our first iteration in Q3 2023. We are hoping to sharpen up the timing of events throughout the process, including communicating internally and externally about our status (thus, this blog post series).

In the next quarter, we aim to build off of this work, and to identify where our future new hires of Delivery Manager / Interim Chief of Staff and our Product Lead will fit in.

Three New Jobs Posted #

In October, we began a short hiring push to address many of the organizational challenges noted in our organizational structure and strategy audit. We aim to have each of these positions filled by the end of the year and begin incorporating new team members into our organization. Here’s a list of the three job postings:

Product Strategy Work #

We kicked off a collaboration with Richard Pope to provide us with some short-term product strategy work. In Q3, our team took stock of the many different kinds of services and technology that we deploy, aiming to refine this into a long-term product model.

Richard will join us for several months to take these outputs and help us craft them into a model for where 2i2c is delivering value that we can build upon for the coming years. We’ll provide more updates for the community as this work continues.

Continued Onboarding of Communities in Our Catalyst Project Collaboration #

We continued onboarding communities onto infrastructure managed by 2i2c as part of a CZI-funded project to serve communities in Latin America and Africa. The grant team began its operations last April and spent the first several months creating an onboarding pipeline and rubric for identifying and connecting with communities. As of October, we’ve onboarded our first few communities - there is still a lot of content, training material, and documentation to create, and we will begin iterating on this in collaboration with our early-adopted communities in Q4 2023 and Q1 2024.

Partnerships and Impact #

This section describes notable new partnerships and developments with communities in our interactive computing hub service.

We began several new partnerships with communities in the research space this month.

The NASA Visualization, Exploration, and Data Analysis (VEDA) project is an open-source science cyberinfrastructure for data processing, visualization, exploration, and geographic information systems (GIS) capabilities.

The US Greenhouse Gas Center provides a cloud-based system for exploring and analyzing U.S. government and other curated greenhouse gas datasets.

In addition, we’ve celebrated considerable growth in one of our partner communities: CryoCloud. This community focuses its work around studying the Cryosphere using satellite imagery data. They’ve grown their community hub to roughly 300 users in a year and have piloted several novel interfaces for data analysis in a JupyterHub context, such as using QGIS via a Linux desktop browser.

2i2c team members also gave several talks in October, and you can find links to each of these below:

Chris Holdgraf on 2i2c’s overall purpose and operations thus far, delivered at the Policy Simulation Library demo day.
Jim Colliander on the impact 2i2c wishes to have and what it means for open science, delivered to the ESIP community.

What We’ve Learned and What Stood Out #

These are things that we’ve learned in the past month that we’re using to improve our service moving forward.

Communities like to define and select their own environments. We began rolling out new functionality to allow communities to define their user environments on-the-fly. This brings mybinder.org-style environment creation into a JupyterHub, and gives both more control and more visibility into the environments that communities use. We noticed that this also begins to blur the line between different workflows and types of communities that can be served on a single hub. It means that a hub is no longer strictly tied to a small number of user environments created for it. We’ll explore the implications of this in the coming months.

We need to improve our billing and invoicing infrastructure. This month we began going through another backlog of cloud infrastructure invoices to send out to communities. For many communities, 2i2c pays a cloud bill on their behalf and passes through costs directly to them. This allows them to know exactly what they’re paying for. However, it is also starting to generate a lot of work! We aim to explore ways to automate and standardize this process in the future.

Digital Public Goods is a concept that resonates with many community leaders. Jim and Chris both gave talks that leaned heavily into the notion of open tools and services as “Digital Public Goods”. As public goods, it is important that they remain “driven by the public” and that they have sustainable and scalable models to grow the value that these goods provide. We’ve noted that this topic resonates heavily with people across the research and education spectrum, and we’re considering how to lean into these values more heavily in 2i2c.

Open organizational report: Strengths and challenges for 2i2c's team

Wed, 08 Nov 2023 00:00:00 +0000

Over the last several months 2i2c has been working with an organizational consulting group called Difference Digital to help us identify the major opportunities and challenges in our organizational structure and strategy. The result of this work is a report that describes in detail the major strengths, weaknesses, challenges, and opportunities that 2i2c faces. It also recommends major actions to take as an organization.

2i2c values organizational transparency and a willingness to be honest about where you’re struggling. Stress is a natural part of both individuals and organizations, and should be embraced with the goal of learning and improving. Moreover, as a young organization 2i2c has benefitted heavily from the documents and learning that other organizations have made publicly available. We wouldn’t be where we are without building on the backs of others who are willing to share what they’ve learned.

So, we are making this organizational audit and report public for anyone to see. We hope that it provides transparency into 2i2c’s current status, and that it serves as a useful resource for other non-profits that are growing and facing similar challenges.

Here’s a link to the report on Zenodo.

For more background on this report, check out the short description below.

In April of this year we had our first in-person team meeting. We were excited and grateful to have the opportunity to speak to each other face-to-face. We also learned that many people on our team were stressed out! Our service had grown slow-but-steadily over the previous year, and we were feeling the tension that comes with growing your partnerships without significantly changing your team’s capacity or structure.

So, we decided to work with an organizational consulting group called makeadifference.digital to help us identify where we need to make improvements. They spent several weeks having one-on-one conversations with each member of the team, as well as doing a broader organizational analysis and comparison to other technical organizations at a similar stage of their lifecycle.

The result of this work was a report that outlines the major opportunities and strengths, as well as challenges and gaps in capacity, that our team currently faces. It makes a number of recommendations for how we should shift our practices, and importantly it also notes that the only way to gain that capacity is by hiring for new people and skills.

Here’s a link to the report on Zenodo.

The immediate result of this work is that we currently have three jobs posted:

A Product Lead role to help us build a “product function” within 2i2c’s team.
A Delivery Manager / Chief of Staff role to oversee and manage 2i2c’s system of work.
A cloud and operations engineering role to grow our cloud engineering team’s capacity in serving communities.

Our next steps are to fill these positions, and to then begin the work of implementing many of the recommendations that are contained in the report. We’re confident that this is a natural part of being a small and growing organization, and we are grateful for the expertise of makeadifference.digital in guiding us through this work.

Note: if you’d like to work with makeadifference.digital, you can reach out to them at hello@makeadifference.digital.

Acknowledgments #

Support for organizational and strategic work like this is provided by a grant from CZI.

Community update Q3 2023: Service growth and growing pains

Tue, 31 Oct 2023 00:00:00 +0000

It’s been two quarters since our last major update - this isn’t quite as frequent as we’re hoping to post updates from our team, but we’re making adjustments to have more regular communication for reasons that will hopefully be a bit clearer below! In that time, we’ve been hard at work serving and growing our interactive computing service, as well as doing some introspection as a team and identifying major next steps moving forward. More on that in the following sections, but first a short service update.

How has our service evolved over the past few months? #

New partnerships and service growth #

Our service has grown several new partner communities over the last two quarters. A few notable communities are the NASA VEDA project, a team at the Smithsonian, a team at NCAR, and the U.S. Greenhouse Gases Center. We are running about 71 hubs across 24 clusters, with about 4000 weekly users ( more usage stats here).

We also began operations on a major collaboration to serve communities in Latin America and Africa, called the Catalyst Project. This team met together for the first time in April, and we’ve been laying a foundation for service growth in the first several months. We are just onboarding our first communities and hope to grow that service in the coming year.

Finally, we’ve been fortunate to receive some grants around creating content and designing workflows that utilize cloud infrastructure. For example, a NASA TOPS grant and an upcoming collaboration with Project Pythia around geospatial workflows.

Financial picture #

At this point, we’re recovering roughly 40% of our operating costs through recurring fees of our managed hub service (making up the remainder in development contracts and grants), and we’ve currently got around 2 years of runway.

However, both of these will be lowered soon because we are about to hire for several more positions. Improvements to our product model will allow us to estimate and recover our service costs more effectively, but we also intend to raise some funds next year to support our efforts in making our service more robust, sustainable, and valuable to communities.

It’s always difficult to strike a proper balance of team (and cost) growth against the financial buffer needed to assure your partners you’ll stick around, but we’re confident that the new hires described below will serve critical needs for our team and mission.

For more context on why and how we’re trying to make up that capacity, read on…

How service growth can lead to team stress #

Over the past year we’ve had a slow-but-steady stream of new communities interested in working with 2i2c for managing cloud infrastructure for interactive computing. We’ve taken a “let’s make it work somehow” approach to all of our community partnerships thus far, with the idea that we must use these partnerships to learn what communities want and identify common patterns.

This is exciting, and we’re fortunate to see the interest and growth in our service. It suggests to us that something about our model is fundamentally right. Communities really love the Right to Replicate, and our participatory service model based around upstream contributions, transparency, and shared responsibility is attractive to many in research and education.

However, each new community is also a new set of stresses on the technical and social infrastructure of our team. Without the capacity to manage the demands of the service, you run the risk of over-extending – and in a worst case scenario, burning out – your team.

This became clear in our first in-person team meeting last May. At that meeting, we realized that many on the team were spending too much of their time “reacting” to demands from the service. We also learned that the scope and complexity of our various workstreams had gotten to a size where our informal team structures of work prioritization were no longer adequate.

Growing the complexity of our team to match the complexity of our service #

So, for the past several months we’ve been working on a plan to evolve 2i2c’s team structure in order to more effectively manage the complexity of our service, and balance long- and short-term thinking.

This began with an organizational audit carried out by makeadifference.digital, a consulting group that focuses on tech-for-good and non-profit products and services. They conducted interviews with everybody on the team, and concluded that we have a few key functions missing that were creating or compounding the stresses people felt.

We hope to make some of their key findings public soon (Update: this is now available at this blog post about the organizational report), and in the meantime here is an overview of some highlights:

We need a dedicated product functionality #

First, we realized that we have a number of new “signals” pushing our service in many different directions. Some are external - from communities we work with or from funders. Some are internal - from different team member visions of where work is needed. After growing our service and our team, there are now too many perspectives and voices to balance in an unstructured and purely organic way.

So we’re creating a dedicated “product function” within 2i2c. Its goal will be to serve as an integrator across the many stakeholders that are interested in 2i2c’s service, and synthesize a collective product strategy and system of prioritization to move the organization forward. They’ll help 2i2c grow a culture of iteration and decisions that are driven by the needs of our community partners and users.

We’re hiring a Product Lead to kick off this effort. If you think you’d be interested in this role, please consider applying!

We need a more structured system of work and execution #

Next, we realized that there are many different workstreams we must balance simultaneously. There are new communities to be onboarded, infrastructure bugs to be fixed, questions to be answered, and strategic priorities to improve the service. Expecting each team member to individually find the right balance between all of these is increasingly unrealistic. We need capacity to oversee this system of work and bring some structure to it.

So, we’re creating a Delivery Manager role to oversee the system of work that our engineering team uses for its planning and execution. In addition, this role will serve at an organization-wide capacity as an interim Chief of Staff. This will allow them to improve and standardize practices organization-wide, and coordinate major projects that span our team.

You can find a job posting for a Delivery Manager / interrim Chief of Staff role. If you think you’d be interested, please apply!

We need more capacity to support our team and its individuals #

In addition to moving forward our workstreams, we also have a unique challenge in team support and dynamics. 2i2c is a small team, it is also distributed across 10 time zones! This adds a lot of extra challenge in getting the team to communicate with one another, support one another as individuals, and learn and grow as a team. We believe that it’s critical to support one another, and to have systems in 2i2c that recognize these challenges in distributed collaboration to design around them.

So, we’re exploring how to create a “People Operations” function within 2i2c that can dedicate their time to supporting 2i2c’s team as a group as individuals. This might mean defining creative ways for team-building, creating mechanisms to surface where team members are struggling or need support, and growing best-practices in inclusive asynchronous team culture.

We’re in the process of designing this role, and hope to have it out in the coming months!

We need more engineering capacity #

Finally, we also realized we need more cloud engineering capacity on our team, particularly in a timezone that overlaps with the American continents. This will give our team a bit more breathing room to balance reactive and project-based work, and have more capacity to focus on personal growth and learning.

You can find our Open Source Infrastructure Engineer job post here if you’re interested.

What’s up next for our team? #

Finally, we’ve also adopted a new quarterly planning system to align our team around key goals that deserve focused attention in each quarter. This will let us be more intentional about considering our work in the context of 2i2c’s broader opportunities and challenges.

For the final quarter of 2023, we’re focusing on these key goals:

Begin to standardize and refine our product offering. In advance of our Product Lead role, we are doing a bit of work to more precisely describe and structure our current service offering. Our goal is to lay a foundation that our upcoming Product Lead can then use to learn about 2i2c’s product and make progress more quickly.
Pay down technical debt. Our engineering team is going to focus on streamlining their operations and reducing toil, in order to reduce the number of “unexpected distractions” that come with inefficient infrastructure and processes. It will also make the service more reliable and transparent for our communities.
Build foundational resources for hub champions to support their community. Our Partnerships team will lead an effort to build basic infrastructure and content that communities can use to create their own knowledge bases around hubs. This will be ongoing work so the goal here is to create a foundation to build upon in the future.

We hope that this has been an informative update from our team, and we appreciate everybody’s input and collaboration over the past few months. We think that the tensions described in this post are healthy - they’re reflective of an organization that is growing and reaching organizational milestones. We’re excited to tackle them and to continue growing our impact and partnerships.

Acknowledgments #

Support for organizational and strategic work like this is provided by a grant from CZI and fees from our Member Communities.

Product Lead

Sun, 29 Oct 2023 00:00:00 +0000

We’re looking for a Product Lead who will be instrumental in shaping 2i2c’s product vision, strategy, and execution. You’ll own the product vision, align it with user needs, and translate it into a clear product roadmap which defines cross-functional priorities and guides our partnerships and engineering teams, enabling efficient product delivery and continuous improvement.

For more information and to apply, see our Greenhouse application page for this job.

❌❌❌
This posting is closed to new applications.
See the jobs page for our open positions.
❌❌❌

About the position

Salary: $95,000-125,000
Location: Remote, preference for working hours that maximizes overlap in time zones with the existing team (currently distributed from UTC-7 through UTC+3)
Deadline: We will begin reviewing applications around November 5th, and will accept them on a rolling basis until the position is filled.

Major duties

Define and own the product vision and strategy assuming ‘the voice of the user’, and doing so collaboratively and inclusively.
Create a clear product roadmap that guides the engineering and partnerships teams.
Collaborate closely with our engineers and users in partner organizations to translate the product roadmap into actionable plans and tasks.

For more general information about 2i2c, see the links below:

Click here to Apply

Product Lead

Sun, 29 Oct 2023 00:00:00 +0000

Please see the Product Lead page.

UNITEFA forms the first community of the Catalyst Project at UNC, through the CCAD (in Spanish)

Mon, 23 Oct 2023 00:00:00 +0000

Delivery Manager / Chief of Staff

Fri, 13 Oct 2023 00:00:00 +0000

We’re looking for a Delivery Manager who will serve as a key facilitator in ensuring the successful and efficient delivery of our product. Acting as a servant leader, you’ll guide our engineering team, promote collaboration, and eliminate obstacles to deliver high-quality results that are aligned with our mission and goals.

For more information and to apply, see our Greenhouse application page for this job.

❌❌❌
This posting is closed to new applications.
See the jobs page for our open positions.
❌❌❌

About the position

Salary: $85,000 - $107,000
Location: Remote, preference for working hours that maximizes overlap in time zones with the existing team (currently distributed from UTC-7 through UTC+3)
Deadline: We will begin reviewing applications around October 23rd, and will accept them on a rolling basis until the position is filled.

Major duties

Ensure the successful and efficient delivery of our product ( 2i2c.org/service/)
Organize and oversee cross-functional work across the team
Detailed planning and day-to-day management of engineering tasks

For more general information about 2i2c, see the links below:

Click here to Apply

Open Source Infrastructure Engineer

Tue, 10 Oct 2023 00:00:00 +0000

We are looking for an experienced Open Source Infrastructure Engineer who will help shape the future of data-intensive scientific research and make a big impact on democratizing the design and access to cloud-based resources for research and education purposes. This engineer will be part of an awesome engineering team pushing forward the development and reliable operations of our cloud-based infrastructure.

For more information and to apply, see our Greenhouse application page for this job.

❌❌❌
This posting is closed to new applications.
See the jobs page for our open positions.
❌❌❌

About the position

Salary: $121,600 - $130,500
Location: Remote, required overlapping for US Pacific timezones
Deadline: We will begin reviewing applications around October 16th, and will accept them on a rolling basis until the position is filled.

Major duties

Cloud infrastructure management and operations
Site Reliability Engineering
Development of open source infrastructure for hosted JupyterHub service

For more general information about 2i2c, see the links below:

Click here to Apply

A new design and logo for 2i2c

Thu, 07 Sep 2023 00:00:00 +0000

We are thrilled to announce a revitalized visual brand for 2i2c. As we continue to grow and evolve, it’s essential that our branding communicates who we are, what we stand for, and how we envision our future. We hope that this new design will unify our visual style across the many places where 2i2c operates.

In pursuit of these objectives, we teamed up with Zack Adell, a designer based in Nairobi who has worked with several similar projects over the years (having most-recently overhauled the Invest in Open Infrastructure brand design). After several rounds of brainstorming, design reviews, and fine-tuning, we’ve landed on a visual identity that resonates with our organization.

Meet Our New Logo and design system #

Zack has created a set of Brand Guidelines that will guide our use of color and visual style in 2i2c’s materials.

Below is our new logo in square and wide form:

Our logo comprises the International Interactive Computing Collaboration wordmark, characterized by our interactive i. We can fly it just about anywhere. A mark of constant progress & community-driven technology, it isn’t stuck to the borders that separate people. It brings us closer together.

Our primary and secondary color palette is below:

Color is the first visual thing we remember and a powerful asset in building brand recognition. Our color is blue. Our community blue says the sky is not the limit. It’s energetic and vibrant, just like the community we serve. And it’s our primary colour, supported by a lively secondary palette that’s as at home on digital platforms as it is on billboards.

We’ve chosen two fonts to use in the majory of the text that we write. Poppins for big, bold sentences, and Work Sans for more versatile and everyday use.

Finally, you might notice these curving, criss-crossing strands in some of our materials. For example, in our new social media header:

They’re the strands that intersect and show how our work and values are interconnected to our community. We like them because they represent 2i2c’s core mission, which is to build connections between people, computation, and data in order to share open knowledge. We’ll try and think of creative ways to incorporate them into our visual style.

We believe our new visual identity is more than just a fresh coat of paint. It’s a reaffirmation of our commitment to our stakeholders and an exciting milestone in our ongoing journey. We can’t wait for you to see it in action, and are excited to hear what you think about it!

❗ Note

If you’d like to get in touch with Zack Adell, please reach out on his LinkedIn profile, or his Instagram account.

A QGIS desktop in the cloud with JupyterHub

Sat, 05 Aug 2023 00:00:00 +0000

The QGreenland Researcher Workshop

JupyterHub is a versatile platform that can serve a desktop with Geospatial Information Systems (GIS) software in the cloud. This was demonstrated by the QGreenland Researcher Workshop that was hosted by the NASA CryoCloud hub. The hands-on workshop trained 25-30 researchers, from Germany, India, France, Canada, Poland and the United States, on how to work with geospatial data in an open science framework.

QGreenland Overview #

QGreenland is an open-source geospatial data package designed for QGIS, a community-owned GIS platform. It focuses on Greenland, offering researchers and educators a comprehensive toolset for FAIR (findable, accessible, interoperable and reproducible) data analysis. The package integrates a variety of datasets into a single, easy-to-use data-viewing and analysis platform, supporting both offline and online use. This makes it particularly valuable for remote fieldwork and areas with limited internet access.

Workshop Success #

The QGreenland workshop demonstrated several key benefits of using JupyterHub for cloud-based GIS:

Accessibility: Participants from across the world could access the same powerful GIS tools through a web browser, eliminating the need for complex local installations while enhancing reproducibility
Cloud block storage: Using a JupyterHub in the cloud allowed for faster data access than a traditional NFS file store by provisioning each user with an elastic block store disk, reducing load times from 5 minutes to under 3 seconds.
Cost Efficiency: Utilizing the CryoCloud JupyterHub instance managed by 2i2c drastically cut down setup costs and time, with only minimal cloud operating expenses of roughly $1/person/day.

Conclusion #

The success of the QGreenland workshop underscores the potential of integrating interactive software applications in JupyterHub. This approach not only democratizes access to advanced geospatial tools but also fosters a collaborative research environment. We look forward to supporting more workshops for QGreenland in the future!

Want to know more? Check out the companion post by QGreenland on the Jupyter Blog

Acknowledgements #

Trey Stafford (CIRES)
Matthew Fisher (CIRES)
*Fisher, M., *T. Stafford, T. Moon, and A. Thurber (2023). QGreenland (v3) [software], National Snow and Ice Data Center.
Snow, Tasha, Millstein, Joanna, Scheick, Jessica, Sauthoff, Wilson, Leong, Wei Ji, Colliander, James, Pérez, Fernando, James Munroe, Felikson, Denis, Sutterley, Tyler, & Siegfried, Matthew. (2023). CryoCloud JupyterBook (2023.01.26). Zenodo. 10.5281/zenodo.7576602

* Denotes co-equal lead authorship

Technical Content Specialist

Wed, 12 Jul 2023 00:00:00 +0000

2i2c manages, supports, and builds community-centric infrastructure for interactive computing in the cloud with partner communities in research and education.

We’re looking for a Technical Content Specialist that will create and curate documentation that supports interactive computing and cloud based open science. It intersects job titles such as “technical writer” and “content creator” while emphasizing previous experience working with open source science and related tools and a desire to share that knowledge.

❌❌❌
This posting is closed to new applications.
See the jobs page for our open positions.
❌❌❌

About the position

Salary: $75,000 - $85,000
Location: Fully remote
Deadline: We will begin reviewing applications around August 2, 2023, and will accept them on a rolling basis until the position is filled.

Major duties

Create documentation for cloud-based interactive computing.
Curate documentation and resources from open source and open science projects.

For more general information about 2i2c, see the links below:

Click here to Apply

If you’re interested in advancing your career at an impact-driven non-profit that is dedicated to open communities and public knowledge, then read on…

About you… #

Below are several skills that will make somebody well-suited for this role. You should apply even if you do not have all of these skills. We expect any new hires to learn and grow into this role over time. If you aren’t sure whether you have the right skills for this job, you should just apply! This is a fully remote role with a preference for working hours that overlap timezones with the existing team (currently distributed from UTC-7 through UTC+3).

Necessary qualities #

Demonstrated excellence in communicating complex technical information to learners with a different levels of background and experience
Demonstrated experience in using open-science tools (e.g. Python or R) in a scientific or scholarly domain
Willingness to continually learn and share emerging technologies and techniques in the interactive computing and open science ecosystems

Useful qualities #

Experience with open source workflows, research and educational contexts, and an understanding of the value that cloud-based infrastructure provides
Experience with the Jupyter ecosystem and other tools for interactive computing
Experience working with distributed service teams that use asynchronous methods of communication
Experience collaborating and coordinating work via online platforms and distributed revision control
Ability to communicate in Spanish, Portuguese, or French

What you’ll do… #

As a Technical Content Specialist, you’ll be responsible for…

Working as part of the 2i2c Partnerships Team towards Community Success
Creating documentation (tutorials, how-tos, explainers, and reference materials) that are shared across our communities using cloud-based interactive computing
Curating documentation resources from open source and open science projects
Developing training materials for communities such as
- Version control for collaborative cloud-based workflows
- Environment management for hub administrators
- Best practices for analysis-ready cloud optimized data
Assisting the 2i2c Engineering Team by editing technical documentation and documenting solutions from our support desk
Authoring content for 2i2c for use in marketing, blog posts, and website copy.

Our benefits and compensation #

We believe it is important for mission-driven non-profits to also provide competitive benefits and compensation packages. See our compensation philosophy page for more information about our compensation and benefits.

How to apply #

2i2c is committed to hiring processes that are inclusive of people with many lived experiences and qualities. We try to structure our hiring process so that it is predictable, doesn’t take too long, and doesn’t take too much effort.

If you’d like to apply for this position, please upload your resume and cover letter using this application form. We will begin reviewing applications after August 2, 2023 and will fill this position on a rolling basis once we find a candidate with the right fit for the job.

On the Jupyter Blog: From intern to mentor.

Fri, 30 Jun 2023 00:00:00 +0000

6——1———————– #

Community update Q1 2023: Growing our community partner network and our team

Fri, 28 Apr 2023 00:00:00 +0000

It’s a month after the end of Q1 2023, and we’d like to share a belated update about what we were up to in the first quarter of this year (we have good excuses for being late, including new tiny humans, I promise).

This quarter we grew our engineering team significantly, and started to refine our team processes and structures to accommodate this extra complexity. We expanded our managed cloud service with new community partners, and made a number of improvements to our technical infrastructure and organizational processes for managing this service.

Read on below to learn more about what we’ve been up to!

New community partnerships #

We added several new community partnerships to our managed hub service. We’ve deployed new hub infrastructure for each of the following groups:

Our University of Toronto Jupyter service now has a dedicated R hub.
We ran an event hub for the Drakkar Ocean project
We deployed a hub for the NASA Visuaslization Exploration and Data Analysis (VEDA) project.
We deployed a hub for the QuantifiedCarbon organization.
We ran an event hub for OceanHackWeek 2023.
We onboarded several new community colleges to our “JupyterHubs Education in Community Colleges” collaboration with CloudBank and UC Berkeley CDSS.

Service improvements #

Below are a few highlights for ways in which we improved our Managed Cloud Service for our partner communities.

We simplified our authentication workflow with CILogon #

Authentication services allow us to identify a user when they log onto a hub, which determines their ability to access hub resources. Previously we had used a combination of Auth0, CILogon, or GitHub for authentication.

However, over the past year we’ve been happy with our use of CILogon so far, especially because of its non-profit status and alignment with many research and education institutions that we work with. This quarter, we decided to streamline our authentication process by dropping the use of Auth0 and grow our partnership with CILogon.

💡 Learn more

We exposed user activity dashboards in JupyterHub so communities know how many people are using the service #

We tend to work with leaders of communities that utilize our service and infrastructure for many others in their network. For example, a teacher with a classroom of students, or a researcher with a global network of collaborators.

In these cases, it’s useful to track how many users are actively using a platform over various metrics of time. This can tell you whether your community finds a service useful, and whether this is growing or shrinking.

We use Grafana to automatically generate dashboards of activity for all of our community hubs and clusters. However, tracking daily, weekly, and monthly active users was not part of JupyterHub’s core functionality.

So, we decided to upstream this functionality into JupyterHub and expose it via the JupyterHub Grafana project. All 2i2c hubs now track daily, weekly, and monthly unique active users. And importantly, anybody else deploying the Zero to JupyterHub for Kubernetes can use this feature now too.

💡 Learn more

See Yuvi’s blog post about this feature.

We’ve added a support widget to our service documentation site. This will allow users to provide structured support requests directly to our team, allowing us to triage and respond more quickly.

Here’s our support button and widget in action:

Our fancy new support button!

We upgraded Kubernetes across all of our AWS clusters #

Kubernetes is at the core of our cloud infrastructure and scalability. We use either a shared or a dedicated Kubernetes cluster for each of our community partners, and it is the foundation upon which all of their Jupyter infrastructure rests.

One of the biggest challenges with managing an ongoing cloud service is keeping the underlying infrastructure upgraded. This brings in new stability and functionality, but also often involves manual steps and toil. This quarter, we upgraded each of our AWS JupyterHubs to Kubernetes 1.24 and will continue this effort with other providers in the coming quarters.

We streamlined our hub uptime checks to be more efficient #

The best kinds of failures are ones that your operations team recognizes and solves before any users run into the problem themselves. We use the Google Cloud Platform HTTP uptime checker to run regular uptime checks for each of the community hubs that we use. This allows us to get quick alerts if any of our community hubs is down for some reason.

We made several optimizations to this process so that we can more efficiently monitor hub uptime and trigger alerts to our engineering team if action is needed.

Organizational updates #

We made a number of broader improvements to our team processes and policies, and even got a shout-out from a few community partners!

We defined organizational principles around engaging in healthy ways with open source communities #

2i2c interacts with many open source communities throughout its work, due to the fact that the majority of the improvements we make are done via upstream contributions. We define several key open source communities that we interact with, and we needed a philosophy and set of practices to ensure that our relationship with them remains healthy and supportive.

💡 Learn more

Check out Principles and considerations for ethically accepting funding for open source for our first take on this, and our Open Source Strategy page for our current team policies around this.

We responded to a NASA RFI on “Scientific Data and Computing Architecture to Support Open Science” #

NASA recently put out a Request for Information around open science and open source infrastructure: NASA RFI NNH23ZDA005L: Scientific Data and Computing Architecture to Support Open Science. We responded with some of our ideas around how to build more open, inclusive, collaborative scientific communities with cloud infrastructure and open source tools.

💡 Learn more

Check out our submission, “Building the open source stack”.

We added two new team members and a new team role #

Our Product and Services Team continues to grow! We added a new team member to improve and manage our cloud infrastructure service: Erik Sundell. As our team has grown, we have also had to manage more complexity in communicating and coordinating across a globally-distributed team of engineers. To help us manage this system, we’ve created a new Engineering Manager Role and promoted Damian Avila as our team’s first engineering manager.

OpenScapes wrote up a blog post about our cloud service collaboration #

We got a nice shout-out from Luis Lopez at the OpenScapes project, describing the benefits of the cloud service that we run for their communities. Check out his blog post: The why, what, and how of our NASA Openscapes cloud infrastructure: 2i2c JupyterHub and corn environment.

Onward to Q2 #

Many thanks to the 2i2c team, our partner communities, our funders, and the many others that have provided us support and guidance. We hope that this update provides a helpful idea of our priorities and major efforts, and we look forward to giving you a new update in Q2!

Acknowledgments #

Support for organizational and strategic work like this is provided by a grant from CZI and fees from our Member Communities.

CILogon usage at 2i2c

Fri, 24 Feb 2023 00:00:00 +0000

About CILogon #

CILogon is an open source service provider that allows users to log in against over 4000 various identity providers, including campus identity providers. The available identity providers are members of InCommon, a federation of universities and other organizations that provide single sign-on access to various resources.

CILogon and 2i2c #

For the past year, 2i2c has been successfully using CILogon for more than fifteen of the hubs it manages.

Currently, most of the hubs that use it are hubs for communities in education that want to manage their hub access through their own institutional providers.

With using a tool like CILogon, we allow hub access to be managed both through the communities’ institutional providers, but also through social providers like GitHub and Google. Because both authentication mechanisms can coexist, there’s no need to provide specific credentials for 2i2c staff in order to have access to the hub. This reduces both the burden on institution’s IT departments, but also the complexity of a hub deployment.

Moreover, as we migrate away from our current Auth0 setup, the number of hubs using CILogon will further increase in the following year.

The setup #

The setup that 2i2c uses, is based on two important tools, the CILogon administrative client and the JupyterHub CILogonOAuthenticator.

The CILogon administrative client #

The 2i2c administrative client provided by CILogon allowed us to automatically manage the CILogon OAuth applications needed for authenticating into the hub.

For each hub that uses CILogon, we dynamically create an OAuth client application in CILogon and store the credentials safely, using the script at cilogon_app.py. The script can also used for updating the callback URLs of an existing OAuth application, deleting a CILogon OAuth application when a hub is removed or changes authentication methods, getting details about an existing OAuth application, getting all existing 2i2c CILogon OAuth applications.

The JupyterHub CILogonOAuthenticator #

For CILogon’s integration with JupyterHub’s authentication workflow, we’re using the CILogonOAuthenticator, which is part of the JupyterHub OAuthenticator project. This is what allows JupyterHub to use common OAuth providers for authentication, and it’s also a base for writing other Authenticators with any OAuth 2.0 provider.

As part of this 2i2c integration with the JupyterHub CILogonOAuthenticator some important upstream fixes and enhancements to the oauthenticator were identified and performed. For example, the GHSA-r7v4-jwx9-wx43 vulnerability was reported and fixed, and a migration guide containing a description of the breaking changes that were made, together with a step by step guide for the users on how to update their usage of JupyterHub CILogonOAuthenticator was provided.

Read more about how CILogon is setup for use at 2i2c from the docs.

Celebration #

Thanks to the 2i2c - CILogon partnership, during this past year we were able to integrate CILogon into 2i2c’s infrastructure and to observe its importance, usefulness and great support for 2i2c and the communities we server.

We are now happy to announce that the 2i2c - CILogon partnership has been expanded to another year!

Acknowledgements: The upstream jupyterhub-oauthenticator project mentioned in this post as being used at 2i2c is a JupyterHub package, kindly developed and maintained by the JupyterHub community and the 2i2c integration described was developed by the 2i2c engineering team. Also, this post was edited by Jim Basney.

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. ↩︎

2022 in review: growing our partner communities and expanding our operations

Wed, 04 Jan 2023 00:00:00 +0000

2022 was a busy year for 2i2c - we not only grew our operations as well as our organization, but also grew our understanding of our mission and where we can have impact. This is a brief reflection on this experience, and an attempt to identify our opportunities for impact and growth in 2023.

Our major goals in 2022 #

We wrapped up 2021 with two major new changes. We had just finished moving fiscal sponsors and had just finished a prototype of our alpha service offerings.

Our 2x2 matrix of service offerings and prices created at the end of 2021. See the documentation for more details.

Our biggest challenge in 2022 was to identify the bottlenecks in this service model, and to begin building the infrastructure to operate and scale it. This included team infrastructure, technical infrastructure, and administrative infrastructure.

Let’s see what we did to accomplish this goal.

Highlights from 2022 #

In 2022, we thoughtfully grew the number of communities we worked with, and used this to make iterative improvements in our model. As a result, we learned some important things and made significant improvements to our service model and infrastructure. Here are a few highlights.

We grew the number of our partner communities #

As noted above, we needed to grow the number and diversity of communities we worked with to understand where our model needed to change. At the end of 2022, we now have 43 community partner hubs across 17 clusters (and at least one on AWS, Azure, and Google Cloud). This amounts to roughly ~2,500 active users each week. We also ran more dedicated infrastructure for more than 11 workshops and events.

We grew our revenue from community partnerships #

One of our goals is to reach self-sustainability without requiring grant funding for most of the communities we serve. In 2022 we built administrative infrastructure to more efficiently recover monthly costs, and were able to bring in funding for our team from community partnerships. Here’s a plot of our monthly non-grant revenue over the last several months:

Our monthly non-grant revenue over the last several months. June is much larger because we filled a backlog of invoices from previous months that weren’t billed yet.

We got grant funding to serve communities in Latin America and Africa #

We also learned that some partnerships may require subsidization from a third party, such as historically marginalized communities and those without dedicated resources. To explore sustainable ways to serve these communities, we applied for and received a new grant to serve communities in Latin America and Africa! Here’s the blog post announcing this grant and our open grant narrative from the proposal.

We improved our continuous integration and deployment system #

Our ability to sustainably grow our service requires being able to technically serve many communities from a relatively small team. We centralized and standardized configuration and operations of many community hubs in one transparent space for all of our partner communities. This allowed us to more easily grow the number of communities we served from one repository. You can read a write-up about these improvements in this blog post.

We defined a Shared Responsibility Model #

Our goal is to frame each community hub as a partnership with a clear breakdown of responsibility to give communities more agency over the infrastructure and service. The Shared Responsibility Model provides a framework for assigning responsibility for various tasks with our partner communities. See our Shared Responsibility Model docs here.

We defined a formal Incident Response process #

Cloud infrastructure inevitably degrades over time, and running ongoing services is largely about quickly responding to issues and resolving them quickly. To do so, we need clear processes to follow in order to quickly identify and respond to major incidents in the infrastructure. Our Incident Response process defines formal team roles and alerting mechanisms that are served by PagerDuty, following best-practices in industry. This will make our service more reliable and make our processes more transparent for our partner communities. Here’s our current incident response process.

We expanded our service offerings to include community and workflow guidance #

We recognized that many communities need more than just infrastructure running in the cloud - they will also benefit from usecase and community guidance. We’re exploring a new range of roles that we could fill, starting with hiring a new team member to help us lead these efforts. Here’s a blog post about the Product and Community Lead.

We began a collaboration with GESIS to develop environment building in JupyterHub #

This marks our first efforts into development-focused work as opposed to operating cloud infrastructure. We will use this experience to learn how to pair focused development with cloud operations (more on that below). It will also make it more likely that we can implement often-requested improvements to the JupyterHub / BinderHub ecosystems. Here’s a blog post about this collaboration.

We helped maintain several upstream open source projects #

We made a number of contributions to key open source communities as part of our organizational mission. These spanned technical improvements as well as organizational and community efforts. One highlight is that several team members have participated in JupyterHub’s latest round of Outreachy interns.
See the JupyterHub community strategy page for more information.

As a brief summary, here is a plot of the issues in key open source repositories that were closed in 2022 that were authored by a 2i2c team member.

Upstream issues opened by a team member that were closed in 2022.

We refined our organizational strategy #

Finally, the experience from this year gave us a lot to think about regarding our role and potential for impact in the research and education ecosystem and the open source community. We updated our strategy in order to focus on a more holistic and collaborative approach to the work with our partner communities. We’ll continue to refine this strategy moving forward.

Things to accomplish in 2023 #

We’re excited about all of the progress we made in 2022, and to continue that progress in 2023. Here are a few areas where we wish to focus our efforts as we begin the new year to keep this momentum going.

Sharpen our Shared Responsibility Model #

Our Shared Responsibility Model is in a kind of “alpha” phase right now. We have some of the high-level skeleton there, but there’s a lot of detail to fill in. Thus far, communities have really liked the idea but we need to make it clearer how we break-down specific jobs and how to decide when to give more or less responsibility to another community. We’d also like to define more intersection points with our partner communities at the level of strategic and service planning so that our communities have a say in our vision and strategic plan.

Grow our community support operations #

We’ve begun exploring how to support communities in their usage of cloud infrastructure, but still have a long way to go to understand what role we should play here. For example, how can we assist communities in cloud workflows without becoming domain experts ourselves? How can we guide communities in a sustainable and scalable way? How can we recover the costs of doing this work? We hope to use our experiences in our upcoming project to serve communities in Latin America and Africa to explore these questions.

Define a cost recovery model that balances sustainability and accessibility #

Our current cost recovery model is intentionally very simple - we charge a fixed monthly cost for human time, and pass-through cloud costs directly. We charge a bit more for more complex deployments and use-cases.

However, we’ve learned that this is both too expensive for simple deployments, and too cheap for really complex deployments. It’s also inaccessible to organizations that do not have the resources to pay, which correlates heavily with historically marginalized communities. We’ll need to refine this model to be both scalable and sustainable, but also accessible to the variety of communities we want to serve.

Incorporate a dedicated software development practice that aligns with open values #

In 2022 we learned that our position in running infrastructure in the cloud gives us visibility into the ways that researchers and educators want open source tools to be improved. In some cases our partner organizations are also willing to contribute resources to help make this happen, or we can identify third parties to fund development work.

Thus far we have focused our efforts on deploying and managing cloud infrastructure. We do make improvements to software as a part of this, but there’s a big difference between running a cloud service and making significant enhancements to software.

We’d like to use our position to help funnel more resources into open source development, but there are a few tricky things to figure out. For example: How can we accept funding to do open source work in a way that doesn’t effectively make us sole decision-makers or gatekeepers for doing development? How can we incorporate software development team practices into a team that has thus-far focused on operating cloud infrastructure?

Thanks for reading this update about our work in 2022. We’re excited about what we’ve accomplished thus far, as well how we hope to expand our impact in the near future.

Acknowledgments #

Support for organizational and strategic work like this is provided by a grant from CZI and fees from our Member Communities.

New project: Open science cloud infrastructure and training for communities in Latin America and Africa

Tue, 20 Dec 2022 00:00:00 +0000

We are excited to announce that the team and proposal described in this blog post has been awarded funding by the Chan Zuckerberg Initiative! We informally call this project The Catalyst Project.

This announcement may be cross-posted on the websites of several collaborating organizations of this grant. Para leer este post en español, vea el blog de MetaDocencia.

Our goal is to create a collaborative cloud infrastructure service that enables community-based cloud-native workflows in the biosciences. We will promote values of open and inclusive community practices, infrastructure that enables these practices, and a “train the trainers” approach that empowers community leaders to share expertise in cloud infrastructure with others in their communities. Our focus will be on communities in Latin America and Africa, and we hope to learn how this model could be extended to other global communities that are historically marginalized from large-scale scientific infrastructure projects.

2i2c will be providing cloud infrastructure operation and support for the communities that we partner with in this effort. We will also assist with creating content to teach cloud-native workflows and assist community leaders in learning this content so that they can share these skills with others.

This is a collaborative effort between 2i2c, The Carpentries, CSCCE, Invest in Open Infrastructure, MetaDocencia, and Open Life Science. For more detailed information, see the blog post with our full grant narrative.

We are hiring #

As a part of this effort, we will also hire several new team members! There are currently two job postings open. Here are links for more information in case you are interested:

Cloud infrastructure engineer to join 2i2c’s Site Reliability Engineering team that will operate and support the cloud infrastructure in this project.
Programme manager role to join Open Life Science and support this project via project management and operational support.

We may be hiring other positions related to this effort, so please stay tuned for more information if you are interested.

Where to follow along #

If you’d like to follow along with this work, please share your e-mail address in this short form. We’ll send updates as we work out longer-term spaces for communication or documentation.

💡 Follow our work! Sign up for our mailing list for updates about 2i2c. Send us an e-mail about collaborating or partnering on a project. See our Service Documentation or our Team Compass to learn about our service and organization.

GESIS - 2i2c collaborate to build a persistent BinderHub experience

Mon, 28 Nov 2022 00:00:00 +0000

Introduction #

Mybinder.org enables researchers across the world to replicate computational environments in the cloud. It allows researchers to turn static code into interactive literate coding environments with a click of a button within seconds. The mybinder.org service is powered by BinderHub, an open-source tool developed by the Jupyter Project that many organizations have deployed for their own communities. It does this by _dynamically building _the software environment needed to reproduce a computation (using a tool called repo2docker), and making this environment available to users.

BinderHub was developed for use-cases that are temporary and fully open by design. BinderHub sessions are destroyed after a fixed amount of time and there is no persistent storage or authentication. However, many research institutions also need more “standard” service features like authentication and persistent storage.

Over the past several years, the GESIS Notebooks team made the first steps towards bridging this gap through their Persistent BinderHub implementation. This was a modified and authenticated BinderHub that included persistent storage across sessions. The Persistent BinderHub service was very successful at GESIS and with its partner communities, and the team wishes to build this functionality into the JupyterHub community’s core technology so that these features can be enjoyed for more use-cases and by many communities.

To enable this vision, we have partnered with GESIS in cooperation with NFDI4DS (GAN: 460234259), CESSDA, and members of the JMTE project. This collaboration has three primary goals:

Generalize the Persistent BinderHub functionality/experience to run on cloud-agnostic infrastructure, so that other stakeholders in NFDI, CESSDA, and the broader scientific community may benefit from this functionality and experience.
Upstream this functionality by making contributions into Jupyter community projects, so that it will be maintained and improved by a community moving forward, thus improving its reliability and sustainability.
Improve the implementation and user experience around Persistent BinderHub, in order to make it more reliable, scalable, productive, and enjoyable to use.

We began this collaboration several months ago, and have focused our efforts on exploring potential implementation pathways for this functionality. We believe that we now have a path forward for this functionality, and this blog post is a brief report of our efforts and future plans as we undertake this effort. See this GitHub Projects Board for issues that implement this effort.

Exploration 1: Adding persistent storage directly into BinderHub #

Our initial intention was to incorporate persistent storage and authentication from the GESIS Persistent BinderHub into the BinderHub codebase. We began by holding a series of meetings to discuss technical requirements from our experience in the JupyterHub/BinderHub ecosystem, and also conducted an audit of the Persistent BinderHub codebase. The Persistent BinderHub implementation is a modified Helm Chart that configures a JupyterHub to expose its authentication and persistent storage functionality, overriding the BinderHub default behavior. We were concerned that building this functionality natively into BinderHub would be challenging given that the BinderHub codebase was designed for ephemeral user sessions.

So, we decided to take another approach:

Exploration 2: Add dynamic image building to JupyterHub #

We realized that there is a way to make this functionality more broadly useful and more maintainable, while still achieving the end-user experience that the GESIS team needed. Instead of modifying BinderHub to incorporate JupyterHub’s storage and authentication features, we would give JupyterHub the ability do dynamically generate user environments using repo2docker.

This would give JupyterHub users more flexibility over the environments served by their hub, and expose Binder-style workflows to the “typical” JupyterHub workflow. BinderHub could then be simplified to re-use JupyterHub’s image building functionality as a part of its own service. We also identified a prototype of this functionality in the tljh-repo2docker project that QuantStack had built for the PlasmaBio project. This implementation was seen as successful, and something others in the community had wanted to generalize for some time.

Our implementation plan #

Two phases of implementation #

With this alternative implementation route in place, we identified two major steps to accomplish this project:

Build a back-end for dynamic environment building. JupyterHub needs to understand how to call repo2docker’s image generation from a Docker-based environment. It needs to expose this ability via APIs that others can build interfaces on top of.
**Build a front-end that is user-friendly and accessible. **Once the back-end is functional, we must build a front-end experience that feels familiar to BinderHub users and is easy and intuitive to use.

Here are a few tasks that we’re carrying out next to make progress on the above two items.

Build a working prototype for image generation via a JupyterHub Service (see below for current status)
Research the tljh-repo2docker code base to understand how we could build upon its UX and functionality.
Understand the typical process that GESIS and NFDI users follow in their BinderHub workflows, to ensure that it can be replicated via this new implementation.
Perform UI/UX research validation to inform the implementation from a user’s perspective.

As a follow-up, we’ll likely re-work the BinderHub codebase to utilize JupyterHub’s new repo2docker service, rather than defining its own custom repo2docker functionality.

Back-end implementation as a JupyterHub Service #

We’re planning to use JupyterHub Services to add the back-end functionality for dynamic image building to a JupyterHub. Services are a way to expose functionality via a JupyterHub REST API, and would allow us to expose basic image generation on-the-fly with repo2docker. We aim for basic functionality to be as close as possible to repo2docker’s default behavior, but to make this functionality _composable and customizable _if a JupyterHub administrator wants to provide different out-of-the-box functionality.

While details may still change, we believe that the major architectural plan has now been settled. We have an experimental codebase with a basic implementation of the repo2docker service described above. As part of this effort, this team has also made a number of improvements to repo2docker’s codebase and project infrastructure. We hope that this effort will continue to push resources and attention to repo2docker by growing the number of users and stakeholders that rely on the project for their success.

Front-end implementation that uses this service #

Once the back-end setup exists, we can use it to begin prototyping user interactions that can trigger and use repo2docker’s image generation. Bringing dynamic environment image building into JupyterHub is a significant improvement in its functionality, and may introduce new kinds of workflows that we hadn’t initially imagined. Understanding, interpreting, and extending the original “Persistent BinderHub” workflow will require a more thorough understanding of user stories and needs in order to identify new workflows that feel natural not only in a JupyterHub scenario but also in a Binder-like scenario.

For example, here are a few major UI/UX questions we must answer:

When a user builds an image, should it also become available to other users as well?
How can a user store, find, and delete old images that they’ve built?
What about new versions of the same image?
Should we simply mimic the mybinder.org UX, or should this be improved as well?

We must answer these and several other questions next. With that vision in place, we’d like to expand our efforts in UI/UX and user research. This will help inform the technical implementation of this work as we expand on our prototype, and help us choose the right way to expose this functionality to users. We welcome collaboration around this work - if you know of an organization that is interested in collaboration, please reach out.

Collaborate and follow along #

Below you’ll find a rough project plan to give an idea for the major actions needed and a timeline for when we hope they’ll be completed. We’ll track further updates and progress on this project in this dedicated GitHub issue and this dedicated GitHub project board.

After a few months working on this project, we are even more excited about the potential for dynamically building environments in a JupyterHub. We believe that it adds a new class of workflows to JupyterHubs that were not possible before, and will be immediately useful to the hundreds of communities that deploy JupyterHub for their communities.

The why, what, and how of our NASA Openscapes cloud infrastructure: 2i2c JupyterHub and corn environment

Thu, 17 Nov 2022 00:00:00 +0000

We recently shared a demo of our infrastructure stack with the OpenScapes community. Check out the blog post about it here.

Grant progress report: CZI Foundational grant year 2

Sun, 13 Nov 2022 00:00:00 +0000

We recently completed a progress report for Year 2 of our primary CZI funding grant. This funding covers some core operations of 2i2c as well as engineering capacity to run our cloud infrastructure for JupyterHubs.

Below is a link to the 3-page grant narrative that summarizes some of our major progress and milestones from year two:

zenodo.org/record/7319289

Acknowledgements #

Thanks to CZI for funding this work.

Celebrating our progress in Q3 2022

Sun, 16 Oct 2022 00:00:00 +0000

Quarter 3 of 2022 has wrapped up, and the 2i2c team has been busy making improvements across our infrastructure, organization, and operations. This is a quick post to celebrate the work we’ve done over the past three months, and to briefly share what we’re working on next.

Below we’ll provide a brief update about major developments this quarter, broken down by functional areas of 2i2c.

These are the main highlights from this quarter - if you’d like to check out more of the work that we’ve done, see:

All the PRs we’ve merged in Q3

All closed issues in Q3

Community impact #

These are a few ways in which we’ve collaborated with communities and demonstrated impact over the last few months.

New JupyterHubs for communities. We’ve deployed JupyterHubs for several new partner communities. Here’s a quick list:

PaleoCube and PaleoHack Hubs infrastructure#1418
NeuroHackademy 2022 infrastructure#1505
Alabama Water Institute CIROH hub infrastructure#1444
OceanHackWeek 2022 infrastructure#1515
COESSING Pangeo-Style Hub infrastructure#1516
Temple University Education Hub infrastructure#1648
Callysto Hub infrastructure#1439
London Interdisciplinary School infrastructure#1485

We also ran hubs for several community events:

NeuroHackademy: infrastructure#1300
OceanHackWeek 2022 infrastructure#1576
COESSING workshop: infrastructure#1516
Eddy Symposium: infrastructure#467
Allen Institute Summer Workshop on the Dynamic Brain infrastructure#1621

Please see our service documentation for more details.

Organization wide updates #

These are large-scale organizational and strategic efforts that impact all of 2i2c.

We applied for a CZI Grant: In partership with The Carpentries, CSCCE, MetaDocencia, Invest in Open Infrastructure, and OpenLifeScience, we applied for a CZI grant to provide cloud infrastructure services to global communities.

We grew our team: We’ve hired two new team members to lead new major efforts with 2i2c. James Munroe will lead efforts around community guidance and product design, and Jim Colliander will lead efforts around partnerships and sustainability. We also updated our Hiring and Candidate Search documentation in the process.

We’re refining our strategy: We’ve begun a process of revisiting and refining our strategy after a year of major operations, see our strategic update blog post for more information.

We completed the CSCCE community management training. Two of our team members (James and Sarah) both completed a several-week community management course that was offered in partnership with CZI.

Our team member Sarah began a part-time role as the JupyterHub Community Strategic Lead. Sarah will be leading community strategy efforts within JupyterHub for the next two years thanks to a grant to the JupyterHub team from CZI. Check out this issue to follow our progress.

Service improvements #

We made a number of improvements to our cloud infrastructure and the processes around our service. Here’s a brief breakdown:

We expanded our shared clusters to new cloud providers and regions. We now have shared clusters already deployed on Google Cloud Platform on us-central1-b and europe-west2.

We defined an incident commander process. This will allow us to coordinate and respond to major outages in our cloud infrastructure more efficiently. See our incident response documentation for more information.

We improved our cloud usage monitoring infrastructure. We’ve deployed a centralized Grafana Dashboard that aggregates cloud usage across all of our partner communities, and allows us to keep track of any unexpected behavior or outages across them all.

Where we’re focusing next #

In the final quarter of this year, we’ve decided to focus our efforts on growing capacity across all of the aspects of our team. Now that we have brought on several more partner communities into our Managed JupyterHub Service, it has shown us where we have bottlenecks in our technology, process, and structure. In 2023 we hope to significantly grow the number of communities we work with, and so we must grow our capacity to be able to take on these new partnerships.

We aim to accomplish this in a few ways:

Make technical improvements to our cloud infrastructure that reduces the amount of human labor associated with regular actions. This will make our cloud infrastructure more scalable and reliable.
Improve our invoicing and partnership leads pipeline so that we can reduce the amount of administrative toil for ourselves and for the communities we work with in billing and cloud cost pass-through.
Refine our organizational strategy and structure so that we are better-able to agree on our most important objectives, and to execute on them efficiently as a distributed team.
Hire people! While improving our efficiency will certainly grow our capacity, we also hope to grow our capacity the old fashioned way: by hiring more team members. We’re identifying the biggest needs on our team now and will hope to have postings soon. Stay tuned!

Thanks #

If you are interested in partnering with 2i2c to have your own managed JupyterHub, please contact us at partnerships@2i2c.org. We have a shared cluster on Google Cloud, with plans to deploy one on AWS soon, and dedicated clusters can be run on any major cloud provider. Please see

our service documentation for more details.

Open Source Infrastructure Engineer: Site Reliability Engineering and Cloud Infrastructure

Fri, 14 Oct 2022 00:00:00 +0000

2i2c manages, supports, and builds community-centric infrastructure for interactive computing in the cloud with partner communities in research and education.

We’re looking for an Open Source Infrastructure Engineer that will join our Site Reliability Engineering team and make our cloud infrastructure more reliable, scalable, and efficient. It will help build a future of data-intensive scientific research and democratize the design and access to cloud-based resources for research and education purposes.

If you’re interested, learn more about 2i2c at the links below, and more about this job posting on the rest of this page.

❌❌❌
This posting is closed to new applications.
See the jobs page for our open positions.
❌❌❌

About the position

Salary: $120,000 - $135,000
Location: preferred at the US/Pacific time zone
Deadline: We will begin reviewing applications around November 17th, and will accept them on a rolling basis until the position is filled.

Major duties

Site Reliability Engineering
Cloud infrastructure management, operations, and support.
Development of open source infrastructure for hosted JupyterHub service

For more general information about 2i2c, see the links below:

Click here to Apply

Who we are #

2i2c is a non-profit organization with a mission to make interactive computing more accessible, scalable, and powerful for research and education: 2i2c.org/organization/.

We accomplish this mission by providing managed cloud services for interactive computing, by providing development and technical leadership to researchers and educators that utilize this infrastructure for specific communities, and by providing support for open source tools and communities in this ecosystem.

We have deep ties to the open source community, and have been leaders and core contributors across dozens of projects - in particular in the Jupyter ecosystem. We also have deep ties to research and education - our team has spent years deploying infrastructure for universities, community colleges, and research teams, and now we’re bringing this experience to a wider audience with 2i2c.

We believe strongly in communities that are inclusive, transparent, equitable, effective, and diverse, especially 2i2c itself. We believe that our values should permeate everything about 2i2c, including the work we do, the communities we serve, and our own organizational culture.

2i2c is a fiscally sponsored project of Code for Science and Society, a registered US 501(c)(3) nonprofit corporation.

What you’ll do #

Ensure the reliable operation of the 2i2c infrastructure (leveraging production-ready cloud-based tools such as JupyterHub, BinderHub and Dask).
Address support issues
Explore emerging technologies in the Cloud / DevOps space, design and implement cloud computing architecture in partnership with our team.
Participate in upstream open source communities we rely on (such as JupyterHub, BinderHub, Dask, etc) in partnership with the established leaders of those communities and collaborate with the Community Lead in the education and outreach around cloud computing.
Work with a distributed and global team - team members are given a lot of autonomy, and expected to be proactive at communicating with one another and working with others to allocate effort that will maximize our impact.

Essential requirements #

Experience deploying applications on cloud infrastructure.
Experience deploying and developing with Linux container-based technologies, such as Docker and Kubernetes.
Experience with continuous integration services (e.g. Circle CI, GitHub workflows).
Experience developing tools in a general purpose programming language (eg. Python).
Experience collaborating and coordinating work via online platforms, such as GitHub, GitLab, or BitBucket, and distributed revision control.
Experience working with distributed service teams that use asynchronous methods of communication

Desirable requirements #

Experience with major cloud providers.
Experience in programming and software engineering with a track record of leadership in open, collaborative projects with broad community adoption.
Experience working on geographically distributed open-source projects.
Experience with the Jupyter ecosystem and other tools for interactive computing.
Evidence of existing connections and relationships in the worldwide ecosystem of open source software for data-intensive research and ability to establish new ones.
Experience with common data science methods, platforms, workflows, and infrastructures; with data management systems, practices, and standards; and the capacity to gain familiarity with new related topics.
Experience engaging with highly technical researchers across a variety of methodological fields, research domains, and computational platforms.
Experience building and maintaining continuous deployment pipelines.
Interpersonal skills to work with researchers and students, including skills to communicate complex information in a clear and concise manner both verbally and in writing.

What it is like to work at 2i2c and why you’ll like working with us #

2i2c is a remote-first team that believes strongly in our organizational values and mission. We recommend that you visit our jobs page, to learn about what it’s like to work at 2i2c and why you should work with us. You will also find relevant information about our compensation philosophy and our commitment to equal opportunity. For an even deeper look into how 2i2c works, check out our Team Compass.

How to apply #

Please fill out the following application form. We will begin reviewing applications on November 17th, and will accept them on a rolling basis until the position is filled.

We are eager to receive your application!

One year later: an update of 2i2c's mission, strategy, and impact

Sun, 09 Oct 2022 00:00:00 +0000

This post is an exploration of 2i2c’s current strategy and direction after a year of major operations. It is a brainstorm from the Executive Director, shared as a blog post to invite feedback and provide transparency into our current thinking. Its goal is to explore the context of 2i2c’s stakeholders and their needs, and identify an opportunity and plan for having a positive impact with these communities. It is not a concrete proposal but a snapshot of thinking in time meant to trigger reflection. Over time we will incorporate some of these ideas into our Team Compass.

When we founded 2i2c, we largely did so from the “bottom up” - we identified several patterns around hosted infrastructure that were useful at UC Berkeley, Pangeo, and similar communities, and we wished to make them more generalized, accessible, and scalable.

We defined our mission as the following:

Our mission is to make research and education more impactful, accessible, and delightful by developing, operating, and supporting infrastructure for interactive computing.

And a description about our immediate activities to make things a bit more concrete:

2i2c designs, develops, and operates JupyterHubs in the cloud for communities of practice in research & education. It builds and supports open source infrastructure that serves these communities.

Around a year ago we began our pilot JupyterHubs project to learn more about our biggest challenges and opportunities in making interactive computing more accessible and useful for research and education. While both of these statements are still accurate, over the past year we’ve also learned more about the value that 2i2c provides. This post is an exploration of how these statements and our strategy may evolve in the near future.

What did we miss with our original strategy? #

In short: it is too-focused on actions rather than impact.

While running JupyterHubs is a key part of what 2i2c does, it is a means to an end rather than our end-goal. Infrastructure is only useful if it changes workflows in a way that aligns with the goals and values that we wish to achieve. We’ve historically defined these in a few scattered places. For example, here are the values listed on our website:

2i2c values fairness and justice as requirements for successful communities.

2i2c values learning and discovery for all people.

2i2c values collaborating and connecting to foster environments for learning and discovery.

However, it is difficult to tie our operations directly to values and goals without making them concrete, and without defining a plan that ties them to our work.

Through our JupyterHubs pilot, we’ve learned how our actions-focused approach was missing some important aspects of these broader goals. For example, we came to understand that a big part of 2i2c’s value isn’t just providing a JupyterHub, it is de-risking cloud native workflows for communities that are inherently skeptical of what cloud infrastructure offers. Doing this entails many things: teaching, making decisions on behalf of others, supporting and answering questions, building trust, and yes, managing infrastructure.

Refining our strategy #

With this in mind, we’d like to make our strategy more clearly-defined and tied to our operational choices. Here are a few ways we’d like to do this:

Define our organization’s values and vision for the impact we wish to have.
Define the key stakeholder communities that we wish to serve, the context of tools and services that are relevant to these stakeholders, and the assumptions we’re making.
Define the problems these stakeholders have, the ways in which their current workflow could be improved, and the opportunity to help them.
Describe our strategy to positively impact these stakeholders with our work.
Define a collection of goals and objectives to carry out this strategy in the near-term.

The rest of this post will take a crack at answering a few of these questions. It is intentionally messy, and meant both as a public snapshot of my thinking at this moment, and fodder for discussion and more specific proposals in the future.

Context: Our key stakeholders and the impact we wish to have #

2i2c’s key stakeholders are communities of practice that are dedicated to creating and sharing public knowledge. These are primarily made up of researchers and educators in the global community.

For these stakeholders, we wish to catalyze and support a transformation in their data workflows that allows them to be more collaborative, inclusive, efficient, and powerful in the impact they wish to have.

Assumptions we make about our stakeholders #

There are a few unique things about these communities that are important for us:

Researchers and educators see their job as creating and sharing knowledge with a heterogeneous and global community. They can’t make many assumptions about the organizational context or resources of this community, or their work will become inaccessible to others.
They work at vertically-oriented institutions (e.g., a university with an in-house IT department), but their communities are organized horizontally across institutions (a researcher may identify more with colleagues in their field than with their co-workers at the university).
As a result, these communities value workflows that are maximally accessible, portable, modular, simple, and long-lasting. This allows them to define a shared set of practices across their institutional boundaries without requiring a lot of vertical decision-making.

Historically, this means that scientists must choose between workflows that are underpowered but accessible (e.g., collapsed into a PDF describing the work), or powerful but inaccessible to many (e.g., they rely on extensive training or resources only accessible to some institutions).

Open source tools have boosted standardization and collaboration across communities #

Over the past ten years, the proliferation of open source tools has vastly expanded our potential to create public knowledge in a more accessible, modular, inclusive, and productive way.

For example, core numerical computing infrastructure like NumPy provides a foundation for more domain specific numerical libraries to build on. Tools like Pandas and XArray allow for more sophisticated data structures that match the complex and heterogeneous data in the research community.

This has led to many domain-specific communities of practice building upon the same APIs and infrastructure to solve their specific needs. By largely sharing the same stack, we have reduced duplication of effort and make it easier to speak the same language across data-rich fields.

…but a local workflow with open source tools is inaccessible or underpowered for many people #

However, this has also led to a few key problems:

Problem 1: The ecosystem of open source tools is huge and complex, and hard to tailor for specific domain workflows. It is hard to decide which tools to use for a workflow, and we do not have efficient community processes for creating and standardizing workflows.

Problem 2: For many users, it is still too difficult to set up a local environment. Installing the right libraries and their dependencies is complex and domain-specific. This leads to wasted time and confusion, especially for newcomers or learners in an educational context.

Finally, there is another workflow-related problem that arises even when you do set up a proper environment:

Problem 3: Local workflows are not scalable enough for many communities. Working with 10GB of data can be challenging in a local context, working with 10TB of data quickly becomes impossible. This leads to communities that “share data” by making lots of local copies that are distributed to individual users. This harms data provenance and makes our work less reproducible and accessible. It limits the scope of questions we can ask with data and increases the friction for sharing our work with others. As our workflows require more computation and data, a “local, fixed hardware” approach will become more and more underpowered.

Managed cloud services can solve the accessibility problem for many workflows and tools #

One way to resolve these problems is to rely on managed infrastructure services to provide the environments needed for data analysis. A systems administrator can set up computing and data resources, and then expose these resources to many users as a service. This makes these complex and powerful environments more accessible, standardizes the workflows of users to make it easier for them to collaborate, and potentially serves as a gateway to more complex data and computing infrastructure.

Historically, this work was done in-house by internal teams at research institutions. This led to many unique infrastructure setups with slight differences across institutions. It also led to data and workflows being institution-centric, even though many communities are organized across institutions.

Cloud infrastructure can solve this problem. It provides a layer of infrastructure that can be used to standardize access and worfklows across communities of practice. It can be more accessible than on-prem infrastructure, as the cloud is already globally distributed in a way that local hardware can never be. Moreover, cloud infrastructure is also much more scalable, and can be used to access more sophisticated data and computing resources in a fluid manner.

But the cloud services landscape is not designed for research and education communities #

Over the last 10 years, a huge ecosystem of cloud-native tools and services have grown to solve this problem in industry. These are often called the Modern Data Stack. However, modern cloud services are largely unused by research and education. Why is this?

We believe it is because most cloud services do not meet many needs of research and educational communities:

They tend to be offered by a single vendor, which results in a fear of lock-in or vendor-specific workflows that result in high-costs.
They require users to learn non-standard workflows that are attached to the cloud service.
They often require extensive knowledge of data and cloud resources to configure properly. They may require an internal dev-ops team to integrate cloud services and expose them for internal teams.
They are often still institution-centric because cloud services are geared towards enterprise contracts within vertically-integrated organizations. Many research organizations are more like collections of little fiefdoms rather than a single kingdom.

In short, many cloud services ask researchers and educators to give up too much agency and choice, and make them reliant on organizations they do not inherently trust. They are perceived as a risky alternative to the “we have control and have visibility into everything” nature of on-prem hardware.

Examples of a potential model for community-centric cloud services #

Over the past several years we have seen several communities strike a balance that made cloud infrastructure more accessible while still retaining agency for the communities of practice that used and managed the infrastructure. For example:

The Pangeo Project is a cloud-native geospatial analytics platform that builds on the Dask, Zarr, and XArray stack to enable distributed and collaborative access to large-scale geospatial datasets.
The UC Berkeley DataHub is a cloud-native educational community that uses a managed service to provide interactive learning environments to thousands of students via the cloud.
The Syzygy service is a federated network of educational hubs that run entirely on open source infrastructure in the cloud, managed for universities in Canada.

Each of these communities roughly followed the same model:

Integrate a collection of open source tools and cloud services into a standardized cloud environment for a community.
Customize the environment and cloud resources via open source tools that provide remote interactive computing sessions. This is usually done with JupyterHub.
Contribute to upstream tools and redeploy improvements to a community’s shared infrastucture in order to enhance the service.

Moreover, they use nearly identical technical stacks: some combination of Jupyter infrastructure to manage cloud infrastructure and provide interactive computing environments, a Scientific Python or R-based stack for the libraries users access, and a collection of online services to facilitate collaboration and workflows.

These services required a combination of dev-ops and cloud engineering skills to integrate the tools and manage the infrastructure, as well as community guidance and teaching to standardize and share workflows across a community.

So why couldn’t this model just be repeated across many other communities as well?

However, running your own cloud infrastructure is a lot of work #

These initiatives demonstrate the potential of building community-centric cloud services on top of open source tools, but they were also unscalable to other communities. Observing these success stories also reveals a few more problems that we must resolve in order to make these services more generalizable and accessible to new communities:

Problem 4: Running your own cloud requires skills and resources that most organizations do not have. In order to make the most of the cloud and to provide it as a resource reliable-enough for important workflows, it is important to have a knowledgeable team with best-practices in distributed cloud management. However, hiring engineers in this space is very difficult, and the team structure and culture needed for these services is often at-odds with the way universities are structured.

Problem 5: Contributing to open source communities requires dedicated time and skills. When building services on top of open source tools, you will invariably need to improve the tools in order to fix bugs or to enhance your service. Doing this is very different from a contract with a traditional vendor, and requires building skills in how to communicate and interact with open source communities. For key open source infrastructure, it also requires an ongoing investment of time into upstream community work that is hard for many institutions to justify.

Problem 6: When institutions run their own clouds, they tend to re-invent institution-centric anti-patterns. For example, an institution might expose a cloud-based service but make it available only to individuals with an institutional account. They might staff it with an under-resourced team (or just a single person). They might make small decisions that differ from institution to institution. All of this limits the effectiveness of the cloud for facilitating collaboration and sharing within communities of practice.

Finally, while vendor-specific cloud services often come with a lot of training material, self-managed cloud services require institutions to build their own practices and guidance for how to use the infrastructure. This results in another major problem:

Problem 7: Communities need assistance in understanding what is possible with cloud-native workflows, and adapting these workflows to their domains. There is enormous value in integrating tools together and exposing them as a highly-accessible managed service via the cloud. However, most communities of practice are still new to cloud-native workflows, and they need considerable guidance to begin sharing their practices within a community.

These are several major problems that we must overcome in order to make cloud infrastructure more accessible and useful to research and education communities while living up to our values of community agency and open workflows.

Our opportunity for impact #

To summarize, we believe that there is the following opportunity for impact:

Make communities in research and education do work that is more collaborative, reproducible, and impactful…
In a way that gives them agency and flexibility to do their work as they wish…
By integrating open tools and standards, managing them as a service with scalable cloud infrastructure, and guiding communities in deciding how to use these tools for their domain-specific problems…

We believe that the best way to do this is via a mission-aligned non-profit service that is based on values of trust, shared responsibility, and transparency. This will allow us to treat our relationships with communities as collaborators, not customers and share responsibility and agency with them. In this way we can act as a vehicle for sharing resources and ideas across communities via our infrastructure and services.

We can make such a service both sustainable and scalable because we are delivering direct value to communities with resources. There are many potential business models that are already in existence (for example, Software as a Service or shared research infrastructure services like supercomputing centers). By generating resources in exchange for these services, we can centralize cloud infrastructure services for many communities into a single, scalable team. By committing ourselves to an upstream-first service model, we can drive resources towards open source communities and make these tools more useful for our key stakeholders.

A model like this naturally sets up a two-directional virtuous cycle where open source communities and public knowledge communities derive value from one another’s work.

flowchart TD RE[Communities in
Research and Education] OS[Open Source Communities] OS -- Builds open tools and
standards used by --> 2i2c 2i2c -- Integrates tools into
managed services for --> RE 2i2c -- Integrates feedback and
upstreams improvements to --> OS RE -- Provides feedback
and resources for --> 2i2c

How should 2i2c try to achieve this impact #

With this in mind, we hope to focus our organizational efforts around building services that focus on the following actions.

Integrate open source tools and services into a cloud-native service that is optimized for scientific workflows and communities. The end-product should not feel like “a 2i2c product” but a service anybody with enough skills could build themselves.
Manage cloud infrastructure with an “upstream first” mentality to provide a high-quality and accessible service for global communities. This will allow communities to focus on their work instead of the infrastructure.
Support the communities that use this infrastructure so that questions and problems are dealt with quickly. This will de-risk the service (and the cloud more generally) with the knowledge that help is available.
Guide communities in using these tools to do their work more effectively and collaboratively. This will speed up the learning and sharing process so that communities are able to make the most of the cloud.
Collaborate with these communities and embody the values we want to see in the research community to build trust and lead others. This will build trust and strengthen relationships between our communities.

Over time, we may add new verbs (such as develop open source software and lead open source communities), but the ones above define our initial organizational focus.

Our most important actions to take #

Accomplishing this requires blending aspects of cloud infrastructure management, domain and workflow expertise, and collaborative service design. As we move forward, these are the biggest challenges to overcome in developing this service further:

Build a top-notch global Site Reliability Engineering Team. First and foremost, the infrastructure that we manage must be reliable and scalable. If you ask communities to do their work in the cloud, they must be confident that it will be stable and highly available. If you wish to serve a global community, then you must build systems management capacity on a global level. This means investing heavily in our asynchronous coordination and communication processes, and building team skills in the modern cloud infrastructure stack and dev-ops practices.
Build centralized cloud deployment infrastructure for community-first services. We need the ability to centrally manage infrastructure that is delivered in a community-specific manner to many different communities of practice. This will allow us to achieve economies of scale in managing and running the infrastructure, while allowing communities to have agency over their tools to customize them for their needs. To do this we’ll need to use open source tools and cloud services that are designed for flexibility and modularity, create out-of-the-box infrastructure that gets communities 80% of the way there, and gives them the power to define the last 20% in a way that is sustainable for both them and our team.
Define two or three scientific workflows to focus on, and integrate the right tools and services into a distribution for each. We must identify a few scientific workflows to focus on, as well as the infrastructure stack that will be most-useful to the communities that require these workflows. We must integrate this infrastructure into a distribution that any community could pick up, but that has enough flexibility for each to solve their “last-mile problem” with customizations.
Define a support and guidance model for community-first services. Our support and guidance similarly needs to be generic enough to be scalable to many kinds of communities, but with the ability for communities to make their own customizations and have agency over their training and content. In this way we can be a centralized resource that communities can use to grow their own practice of cloud-native workflows.
Identify a collaborative service delivery model that doesn’t create too much overhead. We believe that community-centric infrastructure should be transparent and participatory, and provide agency to communities in shaping their service. On the other hand, we wish to serve many different communities, and thus we must minimize the amount of labor associated with serving any particular community. As a result we must build a collaborative model of roles and expectations around our services that balances participation from community representatives against our ability to act quickly to ensure the best service possible.
Identify a cost-recovery model that is globally accessible and scalable. We wish to serve a large and global collection of communities with our services, and so we must identify a way to recover our costs such that we are not restricted to serving only the wealthiest communities in the world, and such that “cost vs. resources generated” gives us the flexibility to grow to serve a large global community.
Create an upstream-first culture. If we wish to leverage open source tools in our work, we need to build team expertise in interacting with open source communities, deploying their technology in our services, and making improvements to our service by upstream contributions to open source tools.
Create an organizational culture that embodies the values we want to support. In order to build a better, more collaborative, more inclusive network of communities of practice, we need to embody the principles we wish to help grow in other communities. This will help us build trust with organizations that are inherently skeptical of “outsourcing” responsibilities to other organizations, and will make us more effective advocates for the same kinds of practices in other communities.

There are many other issues we must tackle, but we’ve identified these as being crucial to 2i2c accomplishing its mission. Over the coming months we will continue to refine our practices and service model. As we learn more, we’ll update our understanding of 2i2c’s situation and potential for impact, and our strategy for accomplishing our mission.

We hope that this framing helps others understand our position relative to the communities we wish to serve, and the impact we wish to have. We welcome any feedback or suggestions about how we can refine these ideas to better-serve our communities.

Appendix: Future growth #

Many people also ask what the growth model looks like for 2i2c. Our pricing strategy above should include our goal of building a financial buffer in order to boost the financial resiliency of the organization, and to provide us room to grow if there is an opportunity to expand our service.

While we want to focus our efforts on the strategic goals described above, here is how I think 2i2c could grow its operations and expand its impact as a next step. These are initiatives for which we might seek grant funding to experiment with sustainable and scalable models.

Create a software development team. Right now our technical efforts are focused on integrating pre-existing tools and services, and managing these services in the cloud. However there are many opportunities to create and enhance the ecosystem of tools that is out there. Doing dedicated software development is very different from Site Reliability Engineering, and we will need to build our financial and staffing capacity to dedicate team members to this work.
Expand the kinds of cloud services we offer. Currently we focus our efforts around providing research and analysis platforms in the cloud. These are often connected to other cloud resources (like datasets) but we do not manage them ourselves. We believe there’s an opportunity to strategically grow the services we provide - most notably in the area of cloud data management and migration. However, this is beyond our current capacity and we will need to grow more before moving in this direction.
Create an open source support operation. There are many things that open source communities need beyond technical improvements. Providing community, operational, and strategic support is another way that 2i2c could use its resources and experience to benefit open source communities that we work with. However, we need to better-understand how to do this in a way that is sustainable for us, and that respects open source communities as independent organizations with their own mission, strategy, and expectations.
Create a cloud infrastructure training operation. Many communities we work with aspire to run their own cloud infrastructure. They wish to work with a trusted partner like 2i2c in the short-term, but in the long term they want to build their own capacity in running similar services. 2i2c’s cloud services are a unique opportunity for others to get hands-on training to grow their skills. Perhaps there is a way for us to share this experience with members from other communities in a way that they can then bring back with them to other organizations. There will be an inherent tension between this and our sustainability model from ongoing services, but we believe it is an important opportunity to explore since it aligns with our values of community agency and choice.

Acknowledgments #

Support for organizational and strategic work like this is provided by CZI.

Open grant narrative: A Collaborative Interactive Computing Service Model for Global Communities

Sun, 28 Aug 2022 00:00:00 +0000

We recently submitted a grant to Chan Zuckerberg Initiative and wish to share some details about it as well as the grant narrative for others to read and re-use.

Go to Zenodo record

Read on for a quick overview of the proposal.

Collaborators #

This grant is a collaboration between several leading organizations in open infrastructure, community, and global leadership:

Problem statement #

Cloud infrastructure is a powerful way to broaden access to workflows and infrastructure across the globe. However, it is also inaccessible to many for a variety of reasons:

There is a large, diverse, and messy ecosystem of open source tools to facilitate cloud infrastructure.
Most communities don’t already have skills in utilizing cloud workflows.
Running infrastructure in the cloud takes dedicated time and expertise that many communities lack.
Many communities do not have organized communities of practice around cloud infrastructure.

These issues are true for most scientific communities, but they are exacerbated in countries that are often marginalized in the global scientific community.

Our proposed work #

For this reason, our goal in this grant is to provide human and technical services to facilitate learning and knowledge transfer of cloud workflows for communities in Latin America and Africa.

It defines four major areas of collaboration:

Cloud infrastructure management - to facilitate access to cloud resources via managed cloud services that integrate open source tools.
Application guidance and training - to provide community leaders with the skills to utilize this infrastructure for their needs. This includes language-localized content and training materials.
Training for trainers - to provide community leaders with skills to share these workflows with others in their communities.
Community leadership and management - to provide community leaders with skills to sustain and grow healthy communities of practice.

If this proposal is funded, over the course of two years the team will provide a combination of the services described above for communities in Latin America and Africa, with the goal of understanding how such services can be most useful for these communities, how we can structure them to provide community representation in the direction of these services, and how we can sustain and scale this model of community-focused services for a global community.

Importantly, we wish to do this work in a way that centers the communities we work with as co-leaders and collaborators in these services. We will explore ways to run these services and workshops so that they are transparent, inclusive, and give agency to the communities they support. Ultimately, we hope that this can be an extensible model for many more communities in the future.

Acknowledgements #

Thanks to CZI for the opportunity to submit this proposal.

Reflections on the Jack Eddy Symposium

Thu, 14 Jul 2022 00:00:00 +0000

Reflections on the Jack Eddy Symposium #

2i2c supported and participated in the 3rd Eddy Cross Disciplinary Symposium held recently in Vail Colorado. The event was hosted by the Cooperative Programs for the Advancement of Earth System Science ( CPAESS) team at the University Corporation for Atmospheric Research (UCAR) with support from NASA.

Context #

The Symposium was framed by the interesting and interdisciplinary scientific career of the late Jack Eddy. Eddy’s legacy was highlighted and his influence has been extended by dynamic leadership from NASA Program Officer Madhulika Guhathakurta (Lika). Lika helped launch and has sustained NASA’s Living with a Star (LWS) program over the past two decades. Prior to LWS, NASA had a variety of siloed efforts focused on near-Sun and near-Earth behavior. The LWS program led to an integration of these efforts under “system science” or “systems engineering” approaches and an expressed desired to connect LWS research activities with impacts on Earth (society, biology, culture, etc.). The program has expanded to include explorations of similar questions arising around other planets in our solar system and the recently discovered collection of exoplanets. Scientists from diverse disciplines (plasma physics, stellar evolution, atmospheric chemistry, space weather, planetary science,…) work together on “cross disciplinary” research that helps us understand our lives near our star.

The Symposium focused on three disciplinary areas (Exoplanets; Sun-Climate and Star-Climate interactions; Risk and resilience of space weather) unified under the cross-cutting thread of open science. Frequent references were made to the upcoming 2023 Year of Open Science and NASA’s Transform to Open Science (TOPS) mission. Symposium attendees listened to talks surveying the four areas in the morning and participated in hackathon-style breakout projects during the afternoons. Work on the projects launched at the Eddy Symposium continues. The space weather group is investigating ways to make the power grid more resilient. The Sun-climate group is exploring plans to establish an institute focused on Sun-climate interactions and improve connections between climate and heliophysics research communities. The exoplanets team is developing tools to programmatically compare Sun-Earth and star-exoplanet interactions.

2i2c’s role #

2i2c, with input from Symposium CoChair’s Dan Marsh and Ryan McGranaghan, rapidly deployed a cloud-hosted JupyterHub for use during the event. The hub provided a shared space for participants to explore data, run analyses, and collaborate with one another using modern tools including Zarr, Xarray and Dask Gateway. Access to the interactive computing platform was granted to any member of the Symposium’s GitHub organization. The work to set up that hub, openly chronicled in this GitHub issue ( 2i2c-org/infrastructure#1329 ), included swapping out a Pangeo-style software environment for a heliophysics-specific resource developed by HelioCloud with special thanks to Brian Thomas!

2i2c co-founder Fernando Pérez gave a talk on how he is “living la vida nube”. Fernando described the ways he, research collaborators, and students are using the Jupyter ecosystem. Diverse and curated tools in Jupyter hubs for the Jupyter Meets the Earth Project and Berkeley’s data science programs were highlighted. The talk showcased how these tools have been integrated to support individuals and communities of practice in data-driven research. In response to requests from the organizers and participants, Fernando gave a demonstration on how to use the hub 2i2c set up for the Symposium and an introduction to version control using git.

2i2c co-founder Jim Colliander gave a talk titled Governing the Science Commons. Three key points from Jim’s talk were: the virtue that should guide the improvements to the scientific enterprise is intellectual generosity; implementation of intellectual generosity into science requires commons-based governance; the convergence of open source tools that support data-intensive collaborative research and learning (as showcased by Fernando) and agency interest ( NASA TOPS, UNESCO) in open science is an inflection point for global change. The talk ended with a call to action for the diverse communities represented at the Symposium to improve the ways we do science.

Things we learned #

Our experience with the Symposium taught 2i2c a few things.

We learned that our engineering team can rapidly deploy interactive computing resources to support a research and education community. Along the way, we confirmed what we’ve been learning from Pangeo and the neuroscience communities: flexible methods to customize the software environment are necessary. We confirmed that our developing shared responsibility model, enabling domain-specific experts to provide curated toolchains for their communities while leveraging 2i2c’s infrastructure expertise, is the right approach.

We learned that managing access to the hub using members in a GitHub organization works but involves some toil since organizers had to work through the GitHub invitation process for each participant. We are exploring others ways to systematically grant event participants access to a hub.

The Eddy Symposium experience reminded us that some skill at using git is vital for collaboration. Fernando’s brief introduction to git provided the mental model of working on a directed acyclyic graph. Roving support from Jim and Fernando during the afternoon hackathon sessions normalized the skill level across the groups but not without a few merge conflicts and frustration. Near the beginning of future workshops, we will follow an improved approach aimed at establishing good git hygeine and familiarity with the collaboration workflow using a simple pull request.

We are honored to have had the opportunity to collaborate with the Eddy Symposium team by managing infrastructure and participating in the workshop. We learned a lot about how to support the Helio and adjacent communities, and are proud of the ways in which our infrastructure helped them do their work more openly and effectively. We hope to build on these successes with these and other communities in the future!

Tech update: Multiple JupyterHubs, multiple clusters, one repository.

Tue, 19 Apr 2022 00:00:00 +0000

2i2c manages the configuration and deployment of multiple Kubernetes clusters and JupyterHubs from a single open infrastructure repository. This is a challenging problem, as it requires us to centralize information about a number of independent cloud services, and deploy them in an efficient and reliable manner. Our initial attempt at this had a number of inefficiencies, and we recently completed an overhaul of its configuration and deployment infrastructure.

This post is a short description of what we did and the benefit that it had. It covers the technical details and provides links to more information about our deployment setup. We hope that it helps other organizations make similar improvements to their own infrastructure.

Our problem #

2i2c’s problem is similar to that of many large organizations that have independent sub-communities within them. We must centralize the operation and configuration of JupyterHubs in order to boost our efficiency in developing and operating them, but must also treat these hubs independently because their user communities are not necessarily related, and because we want communities to be able to replicate their infrastructure on their own.

A year ago, we built the first version of our deployment infrastructure at github.com/2i2c-org/infrastructure. Over the last year of operation, we identified a number of major shortcomings:

Within a Kubernetes cluster, we deployed hubs sequentially, not in parallel. This grew out of a common practice of Canary deployments that allowed us to test changes on a staging hub before rolling them out to a production hub.
We used a single configuration file for all hubs within a cluster, which led to confusion and difficulty in identifying a hub-specific configuration.
Moreover, any change to a hub within a cluster caused a re-deploy of all hubs on that cluster. This is because we did not know whether a given change touched cluster-wide configuration or hub-specific configuration.

Our goal #

So, we spent several weeks discussing a plan to resolve these major problems - here were our goals:

We should be able to upgrade a specific hub alone, by inspecting which configuration files have been added or modified.
Production hubs should be upgraded in parallel when they are effectively run independently.
We should use staging hubs as “canary” deployments and not continue upgrading production hubs if the staging hub fails.

An overview of our changes #

To accomplish this, we needed to identify which hub required an upgrade based on file additions/modifications. This took a lot of discussion and iteration on design, and so we share it below in the hopes that it is helpful to others!

Improvements to our code and structure #

We made a few major changes to the infrastructure repository to facilitate the deployment logic described above. Here are the major changes we implemented:

We separated each hub’s configuration into its own file, or set of files. For example, here is 2i2c’s staging hub configuration.
We created a separate cluster.yaml file that holds the canonical list of hubs deployed to that cluster and the configuration file(s) associated with each one. For example, here is 2i2c’s GKE cluster configuration, which contains a reference to the previously mentioned staging hub.
We updated our deployer module to do the following things:
- Inspect the list of files modified in a Pull Request.
- From this list, calculate the name of a hub that required an upgrade, and the name of its respective cluster.
- Trigger a GitHub Actions workflow that deploys changes in parallel for each cluster/hub pair.

In addition to these structural and code changes, we also developed new GitHub Actions workflows that control the entire process.

A GitHub Actions workflow for upgrading our JupyterHubs #

We defined a new GitHub Actions workflow that carries out the logic described above. These are all defined in this deploy-hubs.yaml configuration file. Here are the major jobs in this workflow, and what each does:

generate-jobs: Generate a list of clusters/hubs that must be upgraded, given the files that are changed in a Pull Request.
- Evaluate an input list of added/modified files in a PR
- Decide if the added/modified files warrant an upgrade of a hub
- Generate a list of hubs and clusters that require upgrades, and some extra details:
  - Does the support chart that is deployed to the cluster also need an upgrade?
  - Does a staging hub on this cluster require an upgrade?
This produced two outputs to be used in subsequent steps:
- A human-readable table including information on why a given deployment requires an upgrade (using the excellent Rich library).
- JSON outputs that can be interpreted by GitHub Actions as sets of matrix jobs to run.
Our staging and support hub job matrix tells GitHub Actions to deploy staging and support upgrades that act as canaries and stop production deploys if they fail.
upgrade-support-and-staging: Update the support and staging Helm charts on each cluster. These are “shared infrastructure” Helm charts that control services that are shared across all hubs.
- Accepts the JSON list described above to determine what to do next
- Parallelises over clusters
- Upgrades the support chart of each if required
- Upgrades a staging hub for the cluster if required (for canary deployments, this is always required if at least one production hub is to be upgraded on the cluster)
filter-generate-jobs: Allows us to treat the support / staging hubs as canary deployments for all the production hubs on a cluster.
- If a staging/support hub deploy fails, removes any jobs for the corresponding cluster.
- Allows production deploys to continue on other clusters.
Our production hub job matrix tells GitHub Actions which hubs to update with new changes. These are triggered if a cluster’s staging/support job does not fail.
upgrade-prod-hubs: Deploy updates to each production hub.
- Accepts the JSON list described above to determine what to do next
- Parallelises over each production hub that requires an upgrade
- Deploy the relevant changes to that hub

Concluding Remarks #

We think that this is a nice balance of infrastructure complexity and flexibility. It allows us to separate the configuration of each hub and cluster, which makes each more maintainable by us, and is more aligned with a community’s Right to Replicate their infrastructure. It allows us to remove the interdependence of deploy jobs that do not need to be dependent, which makes our deploys more efficient. Finally, it allows us to make targeted deploys more effectively, which reduces the amount of toil and unnecessary waiting associated with each change. (It also reduces our carbon footprint by reducing unnecessary GitHub Action time).

We hope that this is a useful resource for others to follow if they also maintain JupyterHubs for multiple communities. If you have any ideas of how we could further improve this infrastructure, please reach out on GitHub! If you know of a community that would like 2i2c to manage a hub for your community, please send us an email.

Acknowledgements: The infrastructure described in this post was developed by the 2i2c engineering team, and this post was edited by Chris Holdgraf.

Celebrating our progress in Q1 2022

Mon, 04 Apr 2022 00:00:00 +0000

Quarter 1 of 2022 just wrapped up, and the 2i2c team has been busy making improvements across our infrastructure, organization, and operations. This is a quick post to celebrate the work we’ve done over the past three months, and to briefly share what we’re working on next.

These are the main highlights from this quarter - if you’d like to check out more of the work that we’ve done, see:

Infrastructure improvements #

This quarter we did a deep dive into a number of core infrastructure improvements for our Managed JupyterHubs Service. Here are a few highlights:

Infrastructure reliability and efficiency. We improved the resiliency, reliability, and efficiency of our deployment infrastructure. For example, we refactored our hub configuration so that each community is better-able to track it, we implemented validation steps to ensure that we don’t accidentally push incorrect config to the hubs, and we’ve significantly improved our CI/CD pipeline to push deployments out to our hubs more efficiently.
Automatic deployments to commercial cloud. With the ICESat hackweek as a test-case for AWS, we’ve finished automating the deployment of clusters and hubs to each major commercial cloud. (there’s not a specific issue for this as it has been a multi-month effort over many PRs and issues!)
CILogon authentication. CILogon is a non-profit organization that provides “single-sign on” authentication services for the same communities that 2i2c serves. We’ve partnered with them to prototype using CILogon for 2i2c’s hubs, which should make it much easier for communities to user their own institutional sign-ons.

Communities we’ve served and lessons learned #

As described in our Managed Hub Services strategy, our goals for this phase of our organization are to balance serving communities of practice and learning where we can improve our infrastructure and practices. With that in mind, here are a few highlights of communities we’ve served, and what we’ve learned from it:

We grew a hub for the University of Toronto to around 4000 monthly users. This has taught us a lot about where our support and operations can and cannot scale, and where we have gaps in our sustainability / pricing model.
We deployed CILogon on a hub for a class at Australian National University. This gives us an opportunity to work out any UX issues and improvements to be made before a deeper CILogon integration.
We deployed a dedicated database per user for a databases course at UT Austin. This is helping us learn more about how to pair slightly more customized per-user infrastructure with our standard hub setups, as well as how our Right to Replicate model could be followed for more complex setups like a database.
We ran an event hub for the ICESat2 HackWeek at the University of Washington. This helped refine our infrastructure and expertise with AWS, as well as improved our event “ready mode” practices.
We deployed a new hub for the LEAP project. This has given us an opportunity to prototype new processes for pass-through cloud costs to simplify our deployments.

Organizational improvements

Beyond our technical and community impact work, we’ve made a lot of significant organizational improvements as well.

We designed a new role in Product and Community Management. We’re excited for this new hire to spearhead efforts in guiding and developing relationships with the communities we serve, as well as guiding and collaborating with our engineering team in developing our services.
We designed a new Project Manager role. Our engineering team had been operating as a largely autonomous and independent group, but we’ve realized that we would benefit from someone to help coordinate our actions and plans, especially as we balance more operations/support issues in addition to new development. This new role is an experiment at growing this capacity within our team, in the hopes that we can dedicate a team member to it in the future.

What’s next #

We are still working out our major priorities for the oncoming quarter, but have a few major projects in the works that we’re hopeful to make progress on quickly. Here are a few major examples:

Improve our process and operations around supporting our users. We are discussing first- and second-line support processes to make our team more responsive and effective at resolving incidents.
Improve our invoicing and contracting process. We are discussing how to reduce toil associated with invoicing in order to make this practice more reliable and efficient, along with our fiscal sponsor Code for Science and Society.
Improving our reporting and monitoring infrastructure. We’d like to boost our ability to monitor activity on each of our hubs in order to identify when something abnormal is happening and get ahead of any potential problems (e.g., to avoid unintentionally large cloud bills). We’d also like to improve our usage reporting to more create more accurate cloud bills for hubs running on multi-tenant clusters.

There is a lot more planned for 2i2c, and if you’re curious to see what we’re up to, we invite you to check out our team compass to learn about our practices, and watch our activity on GitHub to see our work.

Many thanks to the amazing 2i2c team, and the multiple open source and scholarly communities that we collaborate with to make all of this possible. In addition, we are grateful to our funders for making this possible. We are looking forward to Q2! 🎉

Acknowledgments #

Support for organizational and strategic work like this is provided by a grant from CZI and fees from our Member Communities.

Notes from our drop-in meeting about the Product and Community Lead role

Tue, 22 Mar 2022 00:00:00 +0000

Yesterday we had a quick “drop-in” session to take questions about 2i2c’s job posting for a Product and Community Lead. We spent the hour discussing a number of questions that others had about the position. Below is a short overview of the questions and some responses, for those who were not able to attend. These responses are a bit rough, since they are mostly off-the-cuff based on the questions asked.

Update 2022-03-24: We’ve added extra questions and answers below from our latest drop-in meeting.

What does success look like in the short and long term? #

This is an important question, with a few different kinds of answers.

As noted, this is the first hire of its kind inside of 2i2c, and it should bring a strategic and organization-building eye to the work that it does. To some extent, this role will be tasked with coming up with their own answers to these questions. This person should build a near- and long-term strategy for how Product and Community Engagement should evolve to be most-effective in accomplishing our mission. This will also mean defining goals and a strategy to meet these goals over time.

With that in mind, here are a few ideas we have in mind for goals that will drive this role:

6 month goals for this role might be:

Become familiar with 2i2c’s organization, culture, mission, and team.
Define an early strategy for how you’d like to incorporate Product and Community engagement into 2i2c’s operations, and set some Objectives or Key Results that we should use to measure success. This should include a plan for the two major objectives of this role: guiding and connecting with the communities we serve, and building design and planning processes that bring this perspective into our engineering and services.
A few iterations on the execution of this strategy, with some demonstration of impact as well as some documented lessons learned.

2 year goals for this role might be:

An organizational strategy and structure has been created, defining the various roles that make up this division of 2i2c and their functions.
Clearly defined team processes for major programs efforts that this role oversees, as well as interconnections with other major divisions of 2i2c (e.g. engineering or sales). For example, a framework for training community leaders and mechanisms or platforms for communication and engagement with our communities.
A team exists that carries out these efforts, led by the Product and Community Lead.
Clear demonstrated impact in the communities we serve, according to the OKRs and goals that have been set in this division.

How does 2i2c provide mentorship/onboarding? #

You can find our onboarding process in our Team Compass. This roughly comes down to choosing an “Onboarding Champion” for the new team member, to help walk them through our team processes and get them access to the right information and accounts. However, 2i2c is quite young, so has only had a few iterations in onboarding new team members. We look forward to improving this process further via this new hire.

What are the largest challenges that someone might face in their first year in this position? #

The largest challenge is largely related to ambiguity and fluidity of this role, due to the fact that 2i2c is small and relatively young. As noted above, this position will have a great deal of autonomy, and will be expected to show leadership in defining the nature of this work within 2i2c. This can either be exciting or scary depending on your comfort level with ambiguity! We recognize that it is an anti-pattern to have roles without clearly-defined measures of success, so we’re committed to defining this quickly in partnership with the new hire. However, we don’t want to be overly-prescriptive in this role, because we want it to have space to lead these efforts within 2i2c.

How do you hope to protect the “business” aspects of 2i2c, if all the tech is open source? #

2i2c is to some extent committing to a limiting business model: by respecting the Right to Replicate, we encourage other organizations to perform the exact same kinds of services that 2i2c offers. However, we believe this is in-line with 2i2c’s mission, and would consider this to be a measure of impact rather than a sustainability problem. In short: our goal is not to become a tech giant or start-up unicorn, we want to sustain a team with competitive pay, and we want to scale as there is more opportunity to serve new communities. We believe that the complexity of integrating tools and managing cloud services means that there will always be enough of an opportunity to bring in ample funding for this model. We also hope that our mission-driven nature and focus on research and education will bring in new kinds of funding opportunities that can sustain 2i2c and its mission.

How would applying the “1000 true fans” approach work in terms of advocacy? #

The 1000 true fans approach suggests that it is enough to leverage the support of “1000 true fans” to sustain a product or service. We hadn’t considered 2i2c in this light before, but believe it aligns well with our strategy. A common pattern 2i2c follows is to build connections with “champions” in the communities that we wish to serve. These individuals are passionate about open science, open source, and community-led workflows. They advocate for 2i2c’s services, and also serve as leaders for the kinds of workflows that 2i2c wishes to enable. We believe that our mission-alignment with research and education, and our focus on empowering community leaders, will position us to build support and dedicated collaborators across these sectors. We also hope that by centering Jupyter infrastructure in the services we offer, we can benefit from the recognition and demand for this ecosystem via our services.

What challenges have you run into thus far? #

There are many things we could respond with here! In this meeting, we discussed two major challenges we continue to iterate on:

Walking the line between “software as a service” and “custom infrastructure”. 2i2c seeks to run infrastructure on behalf of other communities, but in a scalable and sustainable way. This means that we must centralize configuration and deployment, but use a standardized stack that benefits from economies of scale. This is a complex problem, especially at the interface points with university bureacracies. For example, many universities require a university email in order to manage cloud infrastructure in their organization - doing this for each of 2i2c’s engineers is not a sustainable practice, and we must define creative ways to balance the security concerns of universities with our desire to run their infrastructure.
Building a distributed organization from scratch. The other major challenge we’ve faced is simply the act of creating an organization from the ground up. We have worked together for many years in open source communities, but there’s a new degree of complexity when you’re all working on the same service and development efforts. Throw in a largely asynchronous team split across many time zones, and there are a lot of coordination and planning challenges to overcome. We have tried many things over the past year (see our latest team practices in the team compass, but there is still a lot of improvement to make.

How crucial is a deep-seated knowledge of Jupyter for this role? #

While it’s not strictly required for somebody to have a knowledge of Jupyter, we think it will be an important part of this role (at least from a user’s perspective). This position is not an engineer, and won’t be expected to understand the inner-workings of Jupyter’s infrastructure. However, it will be crucial that this role understand what is possible with JupyterHub, Notebooks, Jupyter Book, etc, and develop and teach best-practices in applying these tools for research and education. They’ll need to have a deep intuition for how to use Jupyter tools, how they should be improved, and how they can be integrated together for new services (along with other tools in the open source community). More important than anything is a deep interest in this ecosystem, and a desire to learn, but having prior experience with the Jupyter stack and similar workflows will be a big benefit.

What level of technical expertise is needed for this position? #

Ideally, they should have the expertise of a “power user” of the infrastructure and usecases that we work with. We don’t expect this role to have software development or cloud infrastructure engineering expertise, but they should understand what it is like to use these tools from a user’s perspective, and have an intuition about how to improve the workflows. They should be able to communicate with and collaborate with engineers effectively, so understanding development workflows will be helpful, but they do not need core expertise in software development.

Is it kind of like a scientific / technical writer? #

The skills of a scientific or technical writer would certainly be relevant for this position. For example, somebody that enjoyed technical documentation or scientific communication likely has one relevant skillset for this role. However, the role will do much more than just technical writing - they will also create and execute on organizational strategy, collaborate with our team around designing and planning our work, etc.

Is scientific knowledge in a specific domain important? #

We don’t expect this person to have deep knowledge in any particular scientific field, though experience with scientific and educational workflows in general will be very beneficial. 2i2c’s goal is to build expertise in the aspects of interactive computing workflows that overlap between many research / educational communities. We hope to work with leaders from these communities to leverage their domain expertise, and to empower them to lead others. Similar to having technical expertise, the important thing is having an intuition for what it’s like to use the infrastructure, what kinds of problems our target communities are trying to solve, and how to learn more about their perspectives.

Does the role involve writing grants for the sustainability of the project? #

This role isn’t tasked specifically with identifying and writing grants, though it is likely that they will collaborate with others at 2i2c in crafting grant language or pursuing similar opportunities. 2i2c is a small organization and so we all tend to wear many hats, though we try to keep each person’s efforts focused on their core responsibilities. In this case, those responsibilities are community guidance and engagement, as well as service / product design in collaboration with our team.

What kinds of communications would this role oversee? #

This is hard to know right now and may evolve over time, but we expect this role will primarily communicate with pre-existing communities that we serve. They will also foster communication between leaders within these communities. They may interface with communities that 2i2c seeks to serve in the future (for example, in collaboration with sales and partnerships), but their focus will be on cultivating and guiding the communities we already work with.

Term for this position #

We hire all team members on one-year contracts with an annual review and the expectation to renew the contract for another year (unless we explicitly say otherwise).

Where are the communities you work with? #

Here are a few characteristics of the communities we currently work with, though we aspire to broaden this group significantly (for example, we wish to expand our focus outside of North American and Europe):

They tend to be focused in North America and in Europe (this is likely due to our pre-existing connections)
They cover a broad range of use-cases, from small- and large-scale education in single institutions, to small- and large-scale research communities that are distributed across the globe.
A common pattern is to work with “community champions” that are interested in our technology and serve as leaders to bring these workflows to their respective communities. We seek to build more connections with people like this, and cultivate our relationship with them.

Aspirationally, we hope to grow our reach to more communities outside of these countries, in order to achieve our mission of reaching a global audience. Doing so will require more sophistication in our coordination and pricing, in order to match our services and support model with communities outside of North America and Europe.

2i2c is young and without much structure. How do you plan to add more structure over time? What support will this role have? #

This is the first role of its kind, and so you’ll need to be comfortable with a relatively fluid environment. We all believe strongly in building good organizational support structures, but we are a young organization that is still developing this capacity internally. Your immediate primary support system will be the other strategic leadership of 2i2c - the Executive Director, Steering Council members (on an ad-hoc basis), and other team members. Over time, we look forward to building more formal support networks between divisions of 2i2c and our team members.

Does this person need to be on an America/Europe time zone? #

The team is currently distributed between US/Pacific and Eastern European time zones, and this also matches the majority of communities we currently work with, so it will be important for this person to have several hours overlap with at least one of those two (the more the better). In the short run, it is likely that a person within these time zones will have the least barriers to team and community collaboration. However, we do not have any strict rules about this.

In the longer term, we are committed to building distributed team practices that do not cause team members to pay large penalties for being in a particular time zone, and we look forward to finding creative solutions to this challenge.

How are you going to proceed now with the applications you’ve received? #

We will soon begin reviewing applications on a rolling basis, and will aim for a multi-step interview process that is respectful of the time of each applicant. More details to come about this, and we’ll start sending out communications about applications soon.

Product and Community Lead

Mon, 28 Feb 2022 00:00:00 +0000

We are looking for a Product and Community Lead to ensure that the communities that 2i2c serves are empowered to have the most impact with our infrastructure.

❌❌❌
This posting is closed to new applications.
See the jobs page for our open positions.
❌❌❌

About the position

Salary: $120,000 - $130,000
Location: anywhere (prefer a time zone between US/Pacific and Central European)
Deadline: We will begin reviewing applications around March 21st, and will accept them on a rolling basis until the position is filled.

Major duties

Guide and learn from our user communities.
Guide our team to build services and infrastructure for these communities
Lead strategic efforts to grow this work within 2i2c.

For more general information about 2i2c, see the links below:

Click here to Apply

Position summary #

This role will guide and empower the communities that we serve, learn from them, and bring their perspective to guide our service and product development. It is similar to a mixture of product management and community and developer advocacy in a tech firm, but adjusted for research, education, and open source contexts. It is also similar to a Research Applications Manager, but with a focus on using and developing infrastructure.

The skills required are a combination of communication, teaching, learning, service design and delivery, and technical acumen. The person that fills this role should feel comfortable learning and sharing ideas, empowering and guiding others, and communicating clearly and collaboratively with a variety of stakeholders including end-users and engineers.

This is a leadership role for a strategy-minded practitioner. 2i2c is a young organization, and this role will have a large degree of autonomy and flexibility. We have defined the starting point, but we seek someone who can bring a strategic eye to this position. Over time we hope that the role will grow to define and lead this style of work within 2i2c more broadly.

What you’ll do #

This role is a combination of connecting, guiding, leading, learning, communicating, and empowering stakeholders in the communities we serve, as well as the 2i2c engineering team. Here are some key focus areas with core responsibilities under each:

Guiding and learning from communities we serve #

Our users are often not “power-users” with Jupyter, open source workflows, or cloud-native workflows. This role should work with users of these communities to guide them in using our infrastructure for maximal impact. Below are a few example responsibilities:

Understand the goals and needs of the communities we serve, as well as the major pain points and problems that they have. This understanding may not be directly communicated and will be gained through active observation. For example:

Create and engage in spaces for sharing information with users. For example, online forums and live community discussions.
Engage in community-specific spaces. This role may monitor and participate in community spaces in either research or education (e.g., the Pangeo forum, the Jupyter forum, or forums for education communities) to track relevant conversation and provide guidance as-needed.

Guide communities and their leaders for the use-cases that 2i2c wishes to enable, and how our infrastructure (Jupyter, JupyterHub, open source tools, etc) can be used to have the most impact. For example:

Develop user-facing materials (documentation, workshops, talks, etc) that demonstrate the basic use-cases that we support, and the best ways that the infrastructure can be used to accomplish community goals. For example “Teaching with Jupyter” or “An Introduction to Scalable Computing with Dask.”
Provide one-on-one or group guidance to our user communities (particularly leaders in those communities) with the goal of transferring knowledge that they can then share within their peers.

Foster deeper external relationships and engagements with key communities of practice and partners that are important for 2i2c’s strategy, such as the Pangeo Project (which is a key stakeholder for this role).

Engage with potential communities and stakeholders, with a focus on demonstrating the use-cases we hope to support and generating new service contracts with these communities.
Communicate externally to demonstrate impact. For example, by participating in meetings, conferences, and other events where we have an opportunity to highlight the work that 2i2c does.
Interact extensively with open source communities that underlie our infrastructure, potentially serving in leadership roles and doing significant work to support these communities. There will be a particular focus on the Jupyter and PyData ecosystems.

Guide product and service design and implementation #

This role should understand the perspectives of our users and the use-cases we wish to enable, and bring this perspective to guide the evolution of our services and infrastructure. Below are a few example responsibilities:

Represent user communities and communicate their needs to the engineering team, leadership team, and other stakeholders. For example:

Discuss and shape ideas for development in collaboration with the engineering and sustainability teams within 2i2c. This may entail writing design documents and participating in GitHub issues and Pull Requests.
Discuss and shape how to evolve our services. Beyond focused development, this role should also help shape our strategic plan for evolving our service offerings, or designing services for new use-cases.

Coordinate with and guide our team in implementation as we carry out development and service design. For example:

Participate in team planning meetings and practices. For example, prioritization and planning in GitHub Issues, or in synchronous team meetings.
Collaborate with engineers throughout the implementation of enhancements to our infrastructure. For example, providing ongoing check-ins, guidance, and feedback via GitHub issues.

Strategic leadership #

This is the first position of its kind within 2i2c, and it will have freedom to shape its strategy and role with the organization. It should oversee the evolution and growth of this kind of work within 2i2c, and develop organizational strategy for how to maximize our impact. Below are a few ways that this might occur (both independently and in partnership with others at 2i2c):

Develop a product and service culture that balances intuition, community research, and data to create delightful experiences and maximize our impact.
Define key goals and evaluation criteria for the success of our communities, and work with others at 2i2c to measure and refine these goals, communicate our impact internally, and use this experience to refine our team processes and strategy.
Develop an organizational strategy for how 2i2c should grow its service and community engagement operations over time, including making new hires, defining new roles, and defining interconnections between these roles and the broader 2i2c team.
Develop a communications plan that communicates 2i2c’c impact and positions 2i2c as a leading advocate for community-owned interactive computing infrastructure.
Collaborate around sustainability and stakeholder engagement. 2i2c aims to sustain itself through a combination of paid services, grants, and stakeholder partnerships. This role will collaborate with others at 2i2c in defining and carrying out these efforts.

Relevant Skills & Career Goals #

Below are several skills that will make somebody well-suited for this role. There is significant scope to develop new skills and grow in the role, and some flexibility in emphasizing different aspects of the role based on the applicant’s skill sets and interests.

Experience with community management and engagement, with a focus on teaching and sharing knowledge with others.
Experience with product management and guidance, with a focus on collaboration with engineering teams at both a design and an implementation level.
Experience with technical communication and documentation skills.
Experience at strategic development and building organizations or teams (particularly distributed or technology-focused ones).
Experience with data science workflows in research, education, and scholarship, with a focus on open workflows and FAIR principles.
Experience using an open source language in a research/education setting.
An interest in learning about workflows with the open source language Python, and open source workflows around it for research and education.
Experience or strong interest in cloud infrastructure and data workflows for research or education, and how this can lead to more collaboration, openness, and productivity (for example, via managed services and Analysis Ready, Cloud Optimized datasets).
Experience with distributed and complex open source communities and ability to communicate and collaborate effectively with these communities.

A note on scope and expectations #

We know that this role is very broad in scope, and that there is a lot of room for interpretation of the specific responsibilities and duties. This is somewhat intentional, and somewhat unavoidable, given that this is the first role of its kind within 2i2c. We will do everything we can to set these expectations intentionally, and to refine them as we learn more, in order to reduce this ambiguity and ensure that this role is sustainable.

New job posting: Product and Community Lead.

Tue, 22 Feb 2022 00:00:00 +0000

The 2i2c team is looking to hire a new team member! We are seeking a product and community lead with the following two goals:

Empower the communities we serve to have impact with our infrastructure.
Guide our development and service design to reflect the needs of our users.

This role will work alongside our engineering team as a partner, and will serve as a high-bandwidth interface to the communities that we work with.

You can find a link to the full job posting below, the rest of this post is a short rationale for this role, and how we hope it will fit within 2i2c’s team and strategy.

Learn more and apply

Why a new role? #

When 2i2c began a year ago, we hired a team of engineers that had experience in cloud infrastructure, Jupyter, and open source ecosystems. In that time, we’ve built out the infrastructure foundation for scalable interactive computing environments that are customizable for the community, and respects their Right to Replicate.

However, solely providing infrastructure is not enough. Working with the modern open source stack, using the cloud to its advantage, and bringing these tools into specific domains requires a lot of extra experience and expertise. We believe that 2i2c is in a good position to provide guidance and support to leaders in the communities that we serve, allowing them to get up-to-speed with the infrastructure more effectively so that they can have an impact.

Moreover, we’ve also learned that it’s crucial to develop infrastructure in collaboration with the communities that we’re serving. A team of engineers tends to focus on code and infrastructure, and having a role that focuses on connecting with communities will give them an excellent perspective on what those communities need.

We hope that this role will combine these two aspects to create a culture of learning, sharing, and guiding between 2i2c’s team and the communities that we work with.

What are similar roles? #

We tried to find similar roles in the private and non-profit sector, but couldn’t find anything that was a perfect fit. However, there were a few close matches.

This role is kind-of like a product manager - their job is to understand the communities that we work with, and to use this to help us make decisions about what to build, how to present it, and how to engage with stakeholders. They will need to help us prioritize the work that is most impactful for our mission, and help us navigate trade-offs in the evolution of our services.

This role is also kind-of like a customer success manager or a developer advocate - they will guide and teach those in the communities we serve - particularly community leaders that go on to teach others - how to use our infrastructure most-effectively.

In fact, the closest role we could find is a relatively new one: the Research Applications Manager. This is a role that has been pioneered by the Turing Institute, and is similarly described as a connector that brings together many perspectives and encourages a participatory, team-based approach to research.

However, the reality is that the person in this role will ultimately get to shape the nature of their work within 2i2c. As a young organization, there is a lot of flexibility for creativity and experimentation in bringing new skillsets into our organization. We hope that the person who fills this role will be excited about growing a culture of team-based approaches to our engineering and collaborations, and to share this culture with the communities that we serve.

What’s next? #

Effective today we are opening up applications for this position, and will begin reviewing them in 2 weeks on a rolling basis until the position is filled. For a more formal job posting, and instructions to apply, click the link below!

Learn more and apply

2i2c’s first year, part 1: exploring Jupyter services.

Tue, 25 Jan 2022 00:00:00 +0000

Now that 2021 has come to an end, this marks the end of 2i2c’s first year of operations. In this year we have grown, experimented, and accomplished a lot - we have also faced challenges and learned as a team. Our primary goal in 2021 was to build a strong foundation for 2i2c.

To reflect on our work thus far, we’re writing three blog posts that describe progress in major areas of work towards this foundation for 2i2c. These three areas are:

Creating services for use-cases - these are our first managed infrastructure offerings for communities in research and education.
Developing cloud infrastructure and tools - this is the technical backbone that makes these services possible, built entirely on open source tools.
Building an organizational foundation - this is the creation of our team structures, processes, and culture that help us carry out our mission.

This first post will focus on services that we’ve created in our first year.

Ultimately, 2i2c’s mission is to facilitate use-cases in research and education via open source development and services. Throughout 2021 we ran several pilots to learn more about the needs of communities in research and education, and how we could build sustainable services that meet these needs. Here are some highlights for each major use-case we have targeted thus far:

Educational community hubs #

A primary use-case that 2i2c seeks to enable is collaborative, distributed educational spaces for learning with data. In 2021 we ran several pilots with educational communities:

A university-wide hub for the University of Toronto. This hub is used in a variety of classes throughout the university, and is made freely available to anyone with a UofT account. We hope to repeat this model for other university-wide communities, and have learned a lot about the challenges of working with particularly large educational communities.

Several hubs for community colleges across California. In partnership with UC Berkeley and CloudBank, we’ve run several hubs for nearly a dozen small community colleges teaching the Data 8 curriculum for their students. These hubs are lightweight and offer standardized environments for their students to use, in order to lower the cost of deploying and maintaining the hubs over time.

What we learned #

The organizational context around educational use-cases is different from research communities. Compared with research groups, educucational groups have more variance in their size (classes as small as 10 people and as large as 500) and think about cost by the student, not as a lump sum. This means that our initial hub-based pricing model may not map cleanly onto educational contexts, and we need to improve the match of scalability and price to these communities.

Moreover, we’ve learned that for these communities, navigating all of the open source tools that are available for pedagogy is confusing! Everybody wants auto-grading but it’s unclear what is the “right tool for the job”. Tools like nbgitpuller have heavy use at “power universities” like UC Berkeley, but many others don’t know that it exists! We will need to invest more time into building guides and documentation that help others leverage these tools.

Research in the cloud #

In addition to educational use-cases, we ran several pilots for research communities in order to leverage cloud infrastructure for scaling their work or collaborating more effectively.

We migrated Pangeo’s cloud infrastructure to be run via 2i2c. The Pangeo Community had been operating and developing their own JupyterHub for several years, but were looking for another organization to provide more reliable/sustained operations and support for their Pangeo Cloud Service. This year we migrated the service to run off of 2i2c’s deployment infrastructure.

A scalable cloud hub for a SWOT satellite team. The MEOM research group at Grenoble is doing work with the NASA SWOT satellite project. However, the datasets generated from this project are huge, and only storable via the cloud. We’ve set up a JupyterHub to provide cloud-based access to this data, running a Pangeo-like environment.

What we learned #

Research communities tend to have more usecase-specific needs than educational ones. While introductory courses in data science tend to be similar across institutions, research needs are much more unique to the problem and team at hand. Moreover, they tend to want infrastructure that runs via institutional cloud accounts. This is possible due to the flexible nature of Jupyter and JupyterHub, but brings extra challenges in bureacracy and access permissions, given that 2i2c engineers usually are not members of these organizations already.

Additionally, many research use-cases are based around the location of the data. This is because data is the hardest thing to move from cloud to cloud. For this reason, it’s important to bring interactive sessions to the data. Jupyter’s ecosystem makes this possible, but we’d like to do more to make this easier. For example, users should be able to launch interactive sessions across many clusters or datacenters, regardless of their hub’s location. They should also have more customized control over their environments.

Distributed events and hackweeks #

Finally, we had a special use-case that is a hybrid of the previous two examples. Events and hackweeks are time-bounded, focused on learning and doing, but often with research workflows and communities. They also tend to be more globally-distributed than a traditional research or education community. See below for a few examples:

The Coastal Ocean Environment Summer School in Ghana workshop is a summer school run in Ghana to share skills and workflows with researchers across Africa. It builds on workflows in the Pangeo ecosystem, and teaches attendees how to work with cloud-native data. By using a cloud-based JupyterHub for their workshop, attendees had direct access to data and compute in a way that would have been much more difficult to set up on local infrastructure.

The PaleoHackWeek hackathons were two hackathons around paleo/climate data workflows. They brought together a distributed community and use the 2i2c hub to facilitate the use of the paleoclim package throughout the hackweek.

OpenScapes champions open practices in environmental science to help uncover data-driven solutions faster. They have several cohorts of scientific trainees learning more about adopting open and collaborative workflows, and use a hub managed by 2i2c to provide remote learning environments for their workshops.

What we learned #

Initially we assumed that event-based hubs would be similar to educational use-cases. However, in practice they are more complex. First, event organizers have ever-changing communities of users on their hubs. They often want to provide access to many new users in each event, and expect only a small subset to continue using the infrastructure after an event. Finally, one-off events also generate spikes in activity that are more intense than educational use-cases, and warrant more dedicated attention from our engineers.

Challenges that we faced #

As we piloted these use-cases, we also ran into a few challenges in designing services around our infrastructure.

Balancing standard deployments, custom deployments, and scalability. Our goal is to centralize our deployment and operations infrastructure in order to reduce the maintenance burden for each community hub. This will allow us to gain economies of scale and lower costs. However, there’s an inherent tension between scalability and customizability - in order to scale we must standardize the infrastructure we offer, but communities often want environments that are unique to their use-case.

Turning services into sustainability. We’ve learned that charging money for things does not come naturally to us. We’ve spent many years building technology and services that were offered freely to the public. This was easy to provide, but difficult to sustain. 2i2c’s goal is to offer similar services, but with a sustainability model that allows us to employ team members to do this work, and to grow in the future. Understanding how to pair the right technology, use-case, and service with a particular pricing model is an area where we must learn more.

What’s next #

Piloting all of these services taught us a lot about the similarities and differences between each use case. Towards the end of 2021, this led to 2i2c’s first collection of “service offerings” for a Managed Jupyter Service. This includes a 2-by-2 matrix of service options, and a specific price point for each. We have begun offering this service to communities, in order to learn more about the model, the pricing, and any changes that should be made. In early 2022, we hope to expand this group to more communities so that we can test this model’s ability to scale.

Our next post in this series will focus on the underlying technology that powers the services described above, stay tuned for more!

Pangeo Cloud goes live on 2i2c!

Tue, 16 Nov 2021 00:00:00 +0000

Pangeo Cloud is an experimental service providing public cloud-based data-science environments for data-intensive geoscience research. We have recently finished re-creating the Pangeo community JupyterHub hosted on GCP in the 2i2c-org/infrastructure repository. This is a huge milestone in our partnership with Pangeo to provide expertise and operations of cloud-based, vendor-agnostic Jupyter infrastructure and workflows.

For users of Pangeo Cloud, the switch should have been a smooth one! The new hub should behave nearly identically to the old one, and will be managed by 2i2c engineers moving forward, in partnership with the Pangeo community. It will be available at the same URL ( us-central1-b.gcp.pangeo.io) and there’s no need to worry about your home directories, they were synced to the new hub only a few days before the migration took place. Development and operations on this hub will all be done in the open and we invite participation and feedback from others in our infrastructure work. Please see this Discourse thread as an initial place to provide feedback.

On 22nd November 2021, the old Pangeo GCP JupyterHub will be shut down, and the project will move forward on the new 2i2c Pangeo Hub. Moving forward, we plan to collaborate together in order to find new pathways for development in the Jupyter ecosystem - we will share more ideas of things we will work on soon!

History of Pangeo Cloud Hubs #

Pangeo has pioneered a new model in using open source and cloud-agnostic infrastructure to support scientific research in the cloud.

The first Pangeo cloud JupyterHub (pangeo.pydata.org; now defuct) was deployed for the 2017 American Meteoroligical Society Meeting; since then, the Pangeo community has iterated through several different versions of prototype cloud-based hubs. This allowed for many new workflows that enabled a more open and collaborative pathway to doing world class research, and included access to datasets and computational resources that were previously unattainable. Pangeo achieved this by working in partnership with open source communities and building technology that leveraged modular open source components for their platform.

In the last several years, Pangeo have built a thriving community of practice around this infrastructure. However as the community has grown, so has the need for more reliable and dedicated operational and developmental support since parts of the Pangeo stack require dedicated expertise and attention to managed. Modern scalable cloud infrastructure is one example of this. Maintaining a complex JupyterHub with many users is a difficult task, and has required significant resources from the Pangeo Project up to this point.

The Pangeo-2i2c Partnership #

2i2c is a non-profit team that develops and operates cloud infrastructure for interactive computing workflows. We have extensive experience in Jupyter workflows in the cloud and a long history of contributions to projects in this ecosystem. We have built a cloud deployment management system that allows us to centralise and configure the deployment of many independent JupyterHubs, empowering communities to leverage the same infrastructure (and team!) for JupyterHubs running in the cloud.

Similarly to Pangeo, all of 2i2c’s core infrastructure is cloud- and vendor-agnostic, and follows a model of building open source tools and giving back to those communities. Our partnership with Pangeo began through 2i2c’s core competency in these areas and the similarity between the two project’s technical stacks.

We’ve begun a partnership whereby 2i2c will manage Pangeo’s cloud infrastructure and lead efforts to develop new features, in partnership with open source communities. We sketched out a few ideas to focus on in this kick-off thread on Discourse. This approach allows each community to focus on it’s core strengths: Pangeo will continue to grow an open community and scientific software ecosystem around geospatial analytics, and 2i2c will oversee the development and operations of the core cloud infrastructure stack that powers Pangeo’s workflows. In some areas we are still experimenting with different collaboration models to ensure that the needs of the Pangeo community are met in a way that is also sustainable for 2i2c. Over the coming weeks, you may see some conversations (and threads for feedback!) about different support and operations models that work best for the community. We are excited to use this as an opportunity to learn more about how to serve more complex and diverse communities like Pangeo.

Acknowledgements #

We are extremely grateful to the Pangeo project for giving us the opportunity to serve their community, as well as the Moore Foundation for funding this work. We look forward to a long partnership ahead! 🚀

Community update Q3 2021: A new fiscal sponsor, improving our infrastructure, nearing an alpha launch.

Sun, 10 Oct 2021 00:00:00 +0000

This is a (roughly) quarterly update for the 2i2c community, with the goal of providing transparency about what we’ve been up to, sharing what we are working on and where we have struggled, and discussing what we’re up to next. In addition, almost all of the work we do is public and discoverable across our GitHub repositories, and is tracked by GitHub issues. Here’s a list of issues we’ve closed in ~Q3.

It is amazing how quickly 4 months goes by when you’re building an organization from scratch! It seems like only a few weeks ago that we were recapping the beginning of the year in our last community update. Since then, we have been hard at work to make 2i2c’s organizational and infrastructure more robust and sustainable.

There are several major strategic areas where 2i2c aims to have impact, and we’ve split this community update along each of these major areas below. We’ll cover major highlights, challenges we’ve faced, and where we’re going next.

Highlights #

Managed JupyterHub Service #

Our Managed JupyterHub Service will be a sustainable, scalable, and participatory service to provide cloud-based DevOps around JupyterHub for communities of practice in research and education. For the past several months, we have been running individual JupyterHubs for many organizations as a pilot, in order to learn more about the challenges we’ll face, and give ourselves an opportunity to build centralized infrastructure around the service.

We focused on a few major areas for work, outlined below:

Automation across cloud providers. We wish to serve communities that run on any of the major commercial cloud providers. We can standardize some of our infrastructure through abstractions like Kubernetes, but must still create cloud-specific deployment infrastructure as well (that Kubernetes cluster has to come from somewhere first!). In the last four months we’ve worked on automating Kubernetes and JupyterHub deployments on AWS as well as Azure to complement our Google Cloud deployments. We would soon like to run more hubs on this infrastructure to test how well it scales.
Monitoring and reporting infrastructure. We have worked on the JupyterHub grafana-dashboards project to improve dashboarding around JupyterHub deployments in general, and will soon automatically deploy Grafana dashboards for our hubs so that communities have insight into what is going on in their hubs.
User environment management. We want communities to have control over the environments that are available on their hubs. We also want to encourage that our communities follow community standards for reproducible environments that can be re-used elsewhere. For this reason, we’ve improved the repo2docker GitHub action to work with more image registries, and created a 2i2c user image template repository for users to re-use for their hubs. See the User Environment docs for more information.
Support and collaboration roles. In addition to technology changes, we have developed an alpha-level support and collaboration model for the communities we serve. Most relevant for our communities is the community representative role, who acts as the main point of contact with 2i2c engineers, and leads administrators on the hub to guide its customization for the community it serves. See the user roles documentation for more information. We have also begun prototyping a FreshDesk support model and team processes around monitoring our support channels and responding to requests and incidents.

Pangeo #

We are working with the Pangeo Community to migrate the Pangeo JupyterHub deployments to utilize 2i2c’s centralized infrastructure, with the goal of 2i2c taking over the development and operation of Pangeo hubs moving forward. We have spent the last few months re-creating the Pangeo hub environment from scratch on a new cloud project controlled by Columbia University, and are nearly ready to begin migration from the “old” Pangeo hub to the new one. After this, we will focus our attention on re-creating the Pangeo BinderHub and AWS hub. Follow along with this work in this GitHub Project.

Executable Books / Jupyter Book #

We are nearing the final year of a grant from the Sloan Foundation to support development on the Executable Books Project. As such, we have begun shifting our attention to create a strategy for sustaining the project’s community beyond this grant. In the coming months we plan on prioritizing improving our documentation (both for users and developers), as well as improving the general maintainability and quality of our codebases.

JupyterHub community support #

We recently collaborated with the JupyterHub community to apply for two CZI EOSS awards. Last month, we were notified that our application to support a Community Strategic Lead was funded! This role will fund Sarah Gibson’s time to focus some of her thinking on building community structures and dynamics that are inclusive and sustainable. We’ll update with more information as this project starts moving.

Organizational foundations #

Finally, in addition to our major development and projects, we have also made a lot of progress at an organizational level.

We began a fiscal sponsorship with Code for Science and Society. This provides a new organizational and legal home for 2i2c after spending nearly a year receiving critical strategic and start-up support from our previous host, ICSI. We are excited to work with CS&S to create the business infrastructure that will power our managed JupyterHubs service.

The 2i2c team has also been improving our team planning and coordination processes, so that we can more effectively execute on our mission. As a distributed team, we have the challenge of building processes for team communication, coordination, and planning that are distributed and asynchronous.

We have improved our organization-wide documentation in order to make it easier to navigate between 2i2c’s various sources of information. We hope that this provides more transparency into what 2i2c is up to and how it is structured, and that it allows us to build more connections between our projects and the broader community. Check out the new documentation landing site at docs.2i2c.org.

What’s next #

In addition to making iterative improvements around the projects described above, we have a few major goals for the final quarter of 2021.

We wish to polish and finish the alpha-level deployment infrastructure across each of the major cloud providers. Our end goal is to be able to deploy a Kubernetes cluster and a JupyterHub on that cluster with minimal human effort. This will allow us to serve more communities with fewer human effort per community. This includes migrating JupyterHubs for key communities, such as the Pangeo project.

We wish to define and begin an alpha-level service. This means defining a few specific “products” that 2i2c can offer, as well as a pricing model for each product. Our goals will still be to learn about how this service should evolve, but we’ll have a bit more specificity about ways that others can engage with us. It will also be an opportunity to scale modestly so that we can improve our infrastructure as-needed.

We wish to define a longer-term vision for our Managed JupyterHubs Service, and create a plan for new workflows that we wish to enable via new development. We wish to use our experience in managing JupyterHubs to understand where new open source development would significantly help the communities we serve, and will shift our attention in this direction once we have finished the early stages of making our infrastructure more robust.

Stay tuned for some more updates about this service, coming soon!

Challenges we’ve faced #

Finally, we want to recognize that there are plenty of challenges along with successes when it comes to having impact! Here are a few of the unexpected challenges that we’ve faced along the way.

Developing and operating multi-cloud infrastructure is a complex process. Automating the creation and operation of Kubernetes clusters across each of the major cloud providers has proven to be a lot of work! While it has been necessary to use our pre-existing hubs to provide the opportunity to build this infrastructure, it is a challenge to both build and operate infrastructure at the same time. This has lengthened our timelines for when we expect the alpha version of the service to be ready.

Coordinating among a distributed team takes time. Each of our team members has been used to working asynchronously with open source communities for many years, and we under-estimated how complex it would be to port this workflow to a distributed team that must coordinate with each other much more closely on a daily basis. Deciding what to work on, how to work on it, and how to help one another take a lot of work when you only share a few hours awake at the same time. For this reason, we have spent a lot of extra energy in our first months as a team to work out team processes for coordination and collaboration.

How to design cloud services as a non-profit? Finally, we’ve learned that there is no clear roadmap for how to build a sustainable cloud service like the one we describe here. 2i2c is somewhere in-between a traditional SaaS company (which tends to provide access to proprietary technology) and a bespoke consultancy (which is more hands-on and custom than we are). Our best explanation for what 2i2c wishes to do is “Open source operations/dev-ops as a service”, which doesn’t quite fit into either category. This means that we have more “unknown unknowns” about what kind of service and pricing model we should develop. We hope to begin answering some of these questions in our alpha-level service launch. Stay tuned for more to come!

Get involved #

Thanks for your interest in 2i2c and the mission that it hopes to accomplish. We hope that this update has been informative and interesting, and we welcome feedback about any of the information provided. If you’d like to help with any of the challenges or efforts described above, we welcome all forms of collaboration, and are happy to chat. Please drop us a line at hello@2i2c.org or contact us about joining our Slack community. Thanks for reading!

2i2c launches next phase in partnership with CS&S

Thu, 30 Sep 2021 00:00:00 +0000

This post was originally written for the CS&S blog.

Code for Science & Society is thrilled to welcome the International Interactive Computing Collaboration (2i2c, for short) as a fiscally sponsored project! After spending a year incubating in the International Computer Science Institute, where 2i2c received critical startup support, 2i2c now joins our fiscally sponsored project program to launch their next phase. 2i2c develops and operates cloud infrastructure for interactive computing, with a focus on the Jupyter ecosystem and cloud-native workflows in research and education. They will build a cloud services model that respects a community’s Right to Replicate their infrastructure by providing transparent and customizable JupyterHub deployments on cloud infrastructure that utilize community-driven open source tools. They aim to use the resources generated from this service in order to support the communities that underlie this infrastructure. Read on for more about 2i2c’s mission and how CS&S will support their team and vision.

2i2c’s organizational mission is to develop and operate sustainable cloud services that provide interactive computing infrastructure with JupyterHub and an ecosystem of tools that support research and education. This model has been pioneered in the organizations that 2i2c’s co-founders have co-led for many years, including the Pangeo Project, the Syzygy Project, the Binder Project, and the UC Berkeley DataHub. These projects follow an “integrate, customize, and upstream” model. They integrate pre-existing open source tools, make necessary customizations to support their specific use-case, and make upstream contributions to extend the infrastructure beyond its current capabilities. This creates a virtuous cycle where tangible needs are met in research and education, while improvements are made to open source projects that benefit the broader community. 2i2c hopes to scale this model, and provide these JupyterHub-based cloud services available to the broader research and education community.

CS&S is particularly interested in pursuing the opportunity to work closely with 2i2c as their team explores how to build sustainable, ethical services that support open scholarship as well as open source communities. The model that 2i2c will develop is different in many ways from traditional grant-based development, or service-based business, because it depends on running community-led infrastructure that 2i2c contributes to, but does not control or own. Both CS&S and 2i2c believe that this model is an opportunity to build more distributed, community-led infrastructure and services, as well aligning a sustainability model with both open source communities and the scholarly community. We hope that this work will also provide experience that helps improve CS&S’s other initiatives in this space, including CS&S’s other fiscally sponsored projects and participants in the Digital Infrastructure Incubator program.

Achieving this mission will involve innovation at an infrastructure level, a business model level, and an open source community strategy level, and will be carried out over the coming years. 2i2c’s next steps are to run pilot JupyterHub infrastructure for select communities of practice in research and education, in order to better understand their needs and how these needs fit in with 2i2c’s developing sustainability model. They will also build infrastructure to deploy and customize a federation of JupyterHubs that are community-specific, and that run entirely on open source infrastructure.

If you believe that your community would benefit from a hub like this, please reach out to the 2i2c team, or join their mailing list. Stay tuned as 2i2c builds its sustainable, scalable, and community-driven platform for interactive computing in the cloud.

Pilot hubs, new collaborations, and new team members - A six month update

Tue, 25 May 2021 00:00:00 +0000

It has been about six months since 2i2c first began operations (after receiving funding from the Chan Zuckerberg Initiative). In that time we’ve made progress along several directions, and wish to use this blog post to provide updates about the ways in which 2i2c has evolved over the first months of its existence.

Below are a few major updates from the 2i2c community - as always, if you want to learn more about 2i2c, keep an eye on our blog or subscribe to the 2i2c mailing list.

Early pilot JupyterHub infrastructure #

First off - we have been making progress building out our JupyterHub deployment infrastructure for 2i2c. One of our major organizational goals is to build a sustainable service managing open source cloud infrastructure for interactive computing. This service will provide hosted, customized JupyterHubs for communities of practice in research and education. They’ll be built entirely with open source tools that are community-driven, and that respect the community’s Right to Replicate.

In order to accomplish this, 2i2c is running several pilots with partners and interested organizations, supported by our funding from CZI, as well as from the JROST rapid response fund. These pilots are meant to be learning opportunities to understand what kind of infrastructure and service it needs to build moving forward.

The documentation for our pilot hubs infrastructure contains information about our deployments and infrastructure. It is served from this 2i2c-org/infrastructure repository, a centralized location for configuring and deploying a federated network of JupyterHubs. Each JupyterHub is independent of one another, and could be spun out from the centralized repository with minimal extra work, giving hub users the ability to replicate their infrastructure, with or without 2i2c. We will continue refining the code in this repository as we learn more from our hub infrastructure pilots.

JupyterHub for geospatial analytics - A collaboration with Pangeo #

As originally announced on the Pangeo blog, 2i2c is forging a collaboration with the Pangeo project around operating and developing cloud infrastructure for large-scale geospatial analytics! This collaboration is funded through a grant from the Moore Foundation (via Pangeo investigator Ryan Abernathey).

Over the coming months, 2i2c plans to assume operation of infrastructure underlying the Pangeo project, allowing the Pangeo team to focus their efforts on their core scientific and development missions. Because Pangeo’s infrastructure is already running on a fully open source stack with JupyterHub, our first step will simply be to shift control over this infrastructure to 2i2c engineers. We don’t anticipate needing to make major changes to their infrastructure and deployments (part of the benefits of using open, modular tools).

Once this is complete, we’ll next shift our attention to some new areas of development that support use-cases in the Pangeo community (and in the scientific community more broadly). There’s a lot of progress that we imagine making - such as supporting sharing pipelines via the Pangeo Gallery or improving tools for scalable computing with Dask Gateway. We’ll provide updates as we formally begin this collaboration and hash out a plan for our next steps.

JupyterHub for education - A collaboration with CloudBank and UC Berkeley #

In addition, we’ve begun a partnership with the UC Berkeley Data Science in Undergraduate Studies program, as well as CloudBank. This collaboration aims to provide hosted JupyterHub infrastructure for community colleges across the state of California. It is an attempt at providing vendor-agnostic and open-source infrastructure to several institutions who would otherwise not be able to deploy this infrastructure on their own.

2i2c will provide the deployment and configuration architecture for this collaboration, working with Sean Morris in operating this educational infrastructure. All of the cloud infrastructure for this pilot will be funded via CloudBank. We will begin by offering environments that are modeled after the Data 8 course at UC Berkeley. This is part of an effort to build a community of practice around Data Science education using open source tools.

New team members #

We’ve also welcomed two new members to the 2i2c core team! 🎉

These individuals will both work towards 2i2c’s major projects, and collaborate together on running our 2i2c Pilot Hub infrastructure. Here’s a bit about each new team member.

Damián Avila. Damián has been a Jupyter core team member for many years now, and has done work across many different parts of the PyData stack (in particular, Jupyter, Bokeh, RISE, and Nikola). Damián will focus his efforts on supporting JupyterHub infrastructure for the Pangeo project, as well as development across the Executable Books Project
Sarah Gibson. Sarah will join 2i2c in June, after spending several years as a Research Software Engineer at the Turing Institute. She has also been involved with the Turing Way for many years. Sarah will focus her efforts on JupyterHub development and operations for the Pangeo community.

Governance and a code of conduct #

Finally, while it’s easy to get lost in technology and collaborations, 2i2c has also made important steps towards defining a stable and transparent organizational model moving forward. 2i2c now has a Steering Council and an early organizational structure. In addition, we’ve defined a one-year bootstrap strategy that we’ll use to guide our path in the first year of 2i2c’s existence.

Finally, one of the first acts of the Steering Council has been to adopt a Code of Conduct. This is a set of guidelines, and a process for resolving incidents, that makes our community more inclusive, equitable, and enjoyable for all. Creating a Code of Conduct is a crucial part of defining our organizational and community culture, and we’re excited to have some explicit guidelines to support our interactions in the future!

Keep in touch #

Now that we are improving our organizational foundation, we will try to post more frequent updates and discussions about what we are up to. We hope for 2i2c to be a model organization in participatory, collaborative, transparent operations, and we look forward to working with you all in the future on this journey.

2i2c partners with UC Berkeley and CloudBank to provide data science education hubs for community colleges in California

Fri, 01 Jan 2021 00:00:00 +0000

Data8. MIT licensed.

Data8 began as a large introductory data science class at UC Berkeley. It uses a Jupyter Book for all course materials, and uses JupyterHub magic links to distribute course content from the textbook.

2i2c is working with the Data 8 team to deploy JupyterHubs for community colleges in California that run the Data8 course, to make the infrastructure and content broadly accessible.

Giving people curricula, content, and infrastructure goes a long way to adoption. Communities want to remix content for their specific needs.

Acknowledgements #

This effort is funded by 2i2c together with UC Berkeley and CloudBank.

Open Source Infrastructure Engineer: Pangeo Project

Wed, 09 Dec 2020 00:00:00 +0000

We are looking for an Open Source Infrastructure Engineer who will help shape the future of data-intensive scientific research and make a big impact on important problems shaping society. This engineer will lead the development and operation of cloud-based infrastructure, focusing on the Pangeo Project - a community platform for big data geoscience.

❌❌❌
This posting is closed to new applications.
See the jobs page for our open positions.
❌❌❌

About the position

Salary: $110,000 - $130,000
Location: anywhere (prefer a time zone between US/Pacific and Central European)
Deadline:

Major duties

Cloud infrastructure management and operations.
Development of open source infrastructure for hosted JupyterHub service

For more general information about 2i2c, see the links below:

Click here to Apply

Who we are #

2i2c is a non-profit organization with a mission to make interactive computing more accessible, scalable, and powerful for research and education. We strive to…

Support data workflows in research and education through infrastructure for interactive computing.
Support open tools and communities that underlie this infrastructure.

2i2c is a project of the International Computer Science Institute, a 501(c)(3) not-for-profit.

What you’ll do #

You will define the overall strategy and technical approach to cloud computing usage in Pangeo, and will interface with the Pangeo community on a frequent basis. You will help deploy, customize, and operate cloud infrastructure for research and interactive computing. You’ll use the experience operating this infrastructure to identify development opportunities, with the goal of minimizing maintenance time and toil - your goal will be to spend more time developing and less time operating. You will contribute to the general development and maintenance of open source software packages for the advancement of scientific objectives, and develop applications for extracting, transforming, loading, managing, and cataloging scientific data in the cloud. You will engage and interact with open source communities surrounding the tools that you use in serving the Pangeo community, and will represent 2i2c in these engagements. You will also collaborate with scientists to support research projects, and may conduct some education and training around scientific computing.

Responsibilities #

Develops strategy and technical design for cloud computing architecture within the Pangeo project and related projects with 2i2c.
Assists with site reliability for Pangeo infrastructure, and uses experience operating this infrastructure to identify new opportunities for development.
Ensures the reliable operation of production cloud-based tools including JupyterHub / JupyterLab and Dask.
Participates in the upstream open source communities we rely on (such as JupyterHub, Dask, etc) by contributing code, documentation, etc as needed.
Develops dashboards and reports to quantify system usage and costs.
Helps to maintain and operate Pangeo Gallery, an interactive showcase for data science projects based on binder and github workflows.
Conducts education and outreach around cloud computing.
Explores emerging technologies in the cloud / DevOps space.
Travels to conferences and workshops (once COVID-19 restrictions end).
Will work with minimal supervision from leadership at 2i2c in partnership with collaborators at Columbia and the Pangeo project. Will work independently and make their own decisions about where to best allocate effort.

Requirements #

Familiarity with deploying applications on cloud infrastructure.
Experience developing tools in a general purpose programming language (eg. Python)
Experience deploying and developing with Linux container technologies, such as Docker and Kubernetes
Experience with continuous integration services (e.g. Travis CI, GitHub workflows)
Experience building and deploying backend web services.
Experience collaborating and coordinating work via online platforms, such as GitHub, GitLab, or BitBucket, and distributed revision control.
Experience working on geographically distributed open-source projects

Good-to-haves #

Experience in programming and software engineering with a track record of leadership in open, collaborative projects with broad community adoption
Experience with cloud infrastructure for data-driven workflows.
Experience with the Jupyter ecosystem of tools for interactive computing
Evidence of existing connections and relationships in the worldwide ecosystem of open source software for data-intensive research and ability to establish new ones.
Experience with common data science methods, platforms, workflows, and infrastructures; with data management systems, practices, and standards; and the capacity to gain familiarity with new related topics
Experience engaging with highly technical researchers across a variety of methodological fields, research domains, and computational platforms
Experience building and maintaining continuous deployment pipelines
Interpersonal skills to work with researchers and students. Include having skills to communicate complex information in a clear and concise manner both verbally and in writing

Our commitment to equal opportunity #

We are an equal opportunity employer and value diversity. We do not discriminate on the basis of race (including hairstyle and texture), religion (including religious grooming and dress practices), gender, gender identity, gender expression, color, national origin, pregnancy, ancestry, domestic partner status, disability, sexual orientation, age, genetic predisposition, medical condition, marital status, citizenship status, military or veteran status, or any other basis covered by applicable laws. We will provide reasonable accommodation to an employee or job applicant with a disability.

How to apply #

Please send an email to jobs+OSIE-2020@2i2c.org with the following information.

A copy of your resume.
A short statement about why you believe you’re a good fit for 2i2c, and for this position.
Examples of your work (either public or private) that you believe shows that you are a good fit.
Your preferred work location.

Salary & Benefits #

We pay competitively (at San Francisco rates) for all of its positions, regardless of your geographic location or cost of living. Salaries are based entirely on job title along with discrete levels of experience within that job title. We also offer a generous benefits package for US-based employees.

See our Salary and Benefits page for more information.

2i2c receives core support from CZI

Thu, 19 Nov 2020 00:00:00 +0000

Last week we announced the creation of 2i2c, a non-profit initiative dedicated to improving and facilitating access to infrastructure for interactive computing workflows in research and education. Today we are thrilled to announce that 2i2c has received core support from the Chan Zuckerberg Initiative. You can find CZI’s announcement here.

This funding totals around $1.4m over three years. It provides crucial core support for 2i2c as it bootstraps itself into existence. We are so thankful to CZI for this support. 🎉🙏✨

The rest of this post is a short run-down of what we’ll use this funding for, and what we hope to accomplish.

The big picture #

In recent years, several projects including Binder, Pangeo, Syzygy, and the Berkeley DataHubs have built atop the Jupyter architecture to support cloud-based infrastructure for reproducible research, large-scale scientific data analysis, national-scale infrastructure for researchers, and broad-impact educational programs based on freely available computational materials. These projects illustrate the transformative potential of the open Jupyter architecture, but they have also shown that unlocking this potential in service of scientists and educators requires continued development and resources beyond those of open source volunteers.

In order to deploy these resources at scale, manage and maintain them for large communities, and to continue developing the underlying technologies for scientific use cases, we need models to sustainably deploy and improve Jupyter technology. We also need capacity for thinking strategically and forging new partnerships to accomplish this goal. This funding will support 2i2c’s early strategic planning and partnership efforts, as well as technical development and operation of Jupyter infrastructure for research and education.

Below are two keys goals for this grant:

Goal 1: Build capacity for Jupyter in research and education #

The primary goal of this funding is to build more capacity for Jupyter’s engagement in research and education. This funding will primarily support Chris Holdgraf to build strategic partnerships and collaborations, find opportunities for Jupyter infrastructure to benefit research and education, coordinate activity in the Jupyter project that benefits these communities, and secure more funding for development, maintenance, and support for Jupyter technology.

We are grateful to CZI for this funding because strategy, leadership, and community support are often difficult to fund from grants that are focused on technical deliverables. By funding strategic growth and capacity building, CZI is helping 2i2c lay a strong foundation from which it can have a greater impact.

Goal 2: Support hosted Jupyter infrastructure for research and education #

2i2c will offer hosted interactive computing infrastructure utilizing the Jupyter ecosystem. It will both deploy and operate this infrastructure for researchers and educators, as well as perform core development to ensure that it serves these communities well. Funding from this grant will support 2i2c’s first hire - Georgiana Dolocan as an Open Source Infrastructure Engineer. Georgiana has been the JupyterHub Contributor in Residence for the past year, and we are so excited for her to join 2i2c!

Georgiana will begin by supporting several pilot hubs that are run by 2i2c for community colleges, universities, and research institutions. She will help these organizations accomplish their mission through 2i2c infrastructure, and will develop these technologies so they are stable, scalable, and serve a diverse set of needs in research and education. This will hopefully set the foundation for 2i2c to sustainably offer this hub infrastructure to a wider audience in the future.

This is the next step in Georgiana’s journey through the Jupyter ecosystem that began with an outreachy internship followed by a term as Contributor in Residence. Both of these steps were made possible thanks to Jupyter stakeholders who invest their resources, time, and mentorship to grow Jupyter’s community beyond the people that have traditionally been involved in the project. It’s also possible because of funders committing resources to broaden participation and inclusion - in particular, the Berkeley Institute for Data Science and NumFOCUS for their original support of our Outreachy interns and the CZI EOSS grant series for funding the original Contributor in Residence.

What’s next #

With this core support, 2i2c turns towards its JupyterHub pilot deployments to build early prototypes that serve research and education, and to build organizational models that sustain these hubs and their development. If you or your organization think you’d be a good fit for these pilots, please reach out to 2i2c and let us know!

Many thanks again to CZI for this support - we believe that it is an excellent investment in the Jupyter community and in open source communities more generally. We also believe it will lead to major advancements in supporting interactive computing workflows for research and education. We look forward to what the next three years will bring!

Hello World

Tue, 10 Nov 2020 00:00:00 +0000

👋 hey everyone!

We’d like to announce the creation of a new non-profit organization¹ that we call 2i2c.

2i2c stands for The International Interactive Computing Collaboration. It is a non-profit dedicated to making open tools for interactive computing more accessible and more powerful for the research and education communities.

This is a short post about why we created 2i2c, what we hope that it will do, and what we are up to next. If you’d prefer to watch a video instead of read a blog post, check out this talk about 2i2c at JupyterCon 2020:

Why create 2i2c? #

The founding team of 2i2c has spent the last several years running projects that use interactive computing for research and education, including bringing data science education to thousands of students, connecting geospatial researchers with large datasets and computational resources in the cloud, and providing federated online environment hubs to schools across Canada, to name a few.

Over time we realized that, while infrastructure for interactive computing could be a huge benefit to research and education, it also required a fair amount of expertise to configure, deploy, and develop. We wished for other organizations to enjoy the same success that we had found, but learned that for many, deploying their own infrastructure was a non-starter to adoption. Instead, many were turning to proprietary or vendor-specific tooling.

We created 2i2c so that these organizations can use entirely open-source tools without hiring and training their own dev-ops and infrastructure talent, and so that development and support of open tools for interactive computing continues to represent the interests of research and education.

Why a non-profit? #

It may sound strange to create a non-profit initiative when there are many VC-funded startups and large tech companies offering notebook services these days. However, we think that a non-profit organization is the right approach to balance the interests of all the stakeholders that we wish to serve. We hope that 2i2c will be a partner to:

Research and educational communities, who can rely on 2i2c to provide them cutting-edge infrastructure for interactive computing that is 💯 open source.
Researchers and educators who need development, who can rely on 2i2c as a collaborator that offers development and expertise in open-source infrastructure to push the cutting edge of interactive computing in the cloud.
Open source communities, who can count on 2i2c support and grow the communities that underlie the tools that we deploy.
Cloud providers, who wish to help the research and educational community via their infrastructure.
Supporters of open source who wish to support interactive computing for research and education via a non-profit dedicated to exactly this mission.

As a non-profit initiative, 2i2c is dedicated to supporting an ecosystem of tools and stakeholders across the open source community, and to ensuring that those tools are well-suited for research and education. We believe strongly in mission-driven work, and non-profit status will ensure that the work that we do is always aligned with our mission and values.

What are we going to do? #

With all of that in mind, what is 2i2c actually going to do? We are still working out the details, but here’s a rough picture:

Offer hosted interactive computing environments on cloud infrastructure. These will be entirely open source and vendor-neutral, and customizable for the communities that are using them. They’ll be offered either as a fee-for-service model and/or subsidized through grants and donations. We wish to build upon the success of JupyterHub as a gateway to computational resources and environments, learning environments, and communities of users. For more information about the vision and values of our hosted infrastructure, see the 2i2c Right to Replicate document.

Provide collaboration and development for interactive computing in research and education. Beyond providing hub infrastructure, there are many ways in which solving problems in research and education can lead to better tools, infrastructure, and workflows in the open source community. For example - how can we generalize a community’s solution to scalable computing so that it can be useful for other use-cases as well? We hope that 2i2c can be an aggregator and integrator of many perspectives in research and education, and build tools that are maximally useful across communities.

Provide core development and community support for open source projects that we use. While many organizations use Jupyter technology in their projects, it is also crucial that they give back to those tools in order to keep the ecosystem healthy. As a mission-driven non-profit, 2i2c has a core goal in not only deploying and customizing open source tools, but also providing core support for them.

Next steps #

2i2c is a young organization, but we already have a few exciting ideas to work towards in the coming months. Here’s an idea of what we’ll be up to next.

Our first step is to understand how interactive computing can best-serve the research and education communities. We know that interactive computing tools work in our specific use-cases, but how do these generalize to other domains or types of organizations? Moreover, how can we improve the open source tools to make them even more customizable for each community?

We’ll begin answering this question through several focused JupyterHub pilots aimed at different use-cases across research and education:

A “Hubs for All” pilot for education. This will focus on making standard educational environments via JupyterHub accessible to a broad range of educational institutions, in particular, traditionally under-resourced institutions such as community colleges, state colleges, and HBCUs.
Research-focused hubs for earth analytics. Research requires more complex and customized infrastructure than education, and so we are piloting hub infrastructure for a few specific research communities to understand how we can meet their needs. We will use this to better-understand how 2i2c and support a diverse research community in the future.
JupyterHub development for the Pangeo Project. Pangeo has been a collaborator of 2i2c since day one, and we love its vision for large-scale earth analytics via cloud infrastructure. We plan to work closely with Pangeo leadership to work on early development of tools aimed at facilitating scalable computing for research on Pangeo infrastructure. More information about this to come soon.

We’ll also use these pilots to develop an organizational sustainability model around this infrastructure. It takes expertise to manage and develop cloud infrastructure, and 2i2c wishes to pay market rates for its engineers. How can 2i2c offer services and development in a way that is sustainable both for itself and for other institutions? We’ll use these pilots to create a plan for both sustaining and scaling 2i2c’s ability to serve institutions and teams.

What do we need? #

As a non-profit initiative, 2i2c has a long road ahead of it. We cannot take venture capital funding, so we have to raise funds the old-fashioned way. This means that:

If you are at an organization interested in purchasing hosted JupyterHub environments from 2i2c, please send us an email .
If you are a funder or are otherwise interested in supporting 2i2c with a donation or grant, please send us an email .
If you have experience in sustaining service-based organizations such as 2i2c, and wish to offer your expertise or guidance, please send us an email .

Moreover, we’ll likely be hiring in the coming months for open source engineers, with a focus on data science, interactive computing, and the cloud. If you’re interested in working for an organization like 2i2c, please send us an email , and keep an eye on this space as we will post more information soon.

Get involved #

If you’d like to get involved with the 2i2c team and community, we recommend two pathways for doing so.

Subscribe to our mailing list. We’ll use this to periodically send updates about what 2i2c is up to.

Join the 2i2c Slack. We use Slack for team conversation, as well as for real-time conversations about tools, practices, and ideas around interactive computing for research and education.

You can also say hello to us on Twitter at @2i2c_org.

Wrapping up #

We are excited about 2i2c, and believe that it is the right kind of organization to create to support research and education, as well as open source communities in interactive computing. The road ahead is a difficult one, but we’re confident that we will hit our stride quickly. Stay tuned for more updates to come.

Acknowledgements #

Support for organizational and strategic work like this is provided by a grant from CZI.

EDIT 08-2021: We are now a fiscally-sponsored project of Code for Science and Society and ICSI is no longer our host organization. We are leaving this section here for archival purposes, and to give credit to ICSI for their help in launching 2i2c. 2i2c’s host organization is the International Computer Science Institute, a 501(c)(3) charitable organization. We thank ICSI for its collaboration and leadership in launching 2i2c! ↩︎

The Community Right to Replicate

Thu, 28 Jun 2018 00:00:00 +0000

This is part of our open practices.

The Right to Replicate gives communities the right to replicate their infrastructure in its entirety elsewhere, with or without 2i2c.

This document describes 2i2c’s commitment to a community’s “right to replicate”, and how this translates into specific infrastructure commitments from 2i2c. We make these commitments because we believe that using infrastructure that follows these principles will lead to a more fair, just, equitable world. We also believe they are the right foundation for more productive and impactful research and education.

2i2c is committed to running its own infrastructure on open-source tools and vendor-agnostic infrastructure, though it does not force users to use only open-source tools in their own environments, code, and data. Below is a table describing how the Right to Replicate fits into 2i2c hub technology.

(Definitions of MUST, MUST NOT, SHOULD, MAY, etc are defined in RFC 2119)


User Code and Data	May be Open Source	We encourage adopting and producing open source code and data, but this is up to the user. e.g., licenses for user content/code
User Environment	Should be Open Source	Strong preference for open source tools only, although in some cases user needs may override this. e.g., Python, R, PyData stack.
2i2c Infrastructure	Must be Open Source	Strong commitment to using only open source software. e.g., JupyterHub, Kubernetes, Postgresql
Cloud Provider Infrastructure	Must be Portable	See this blog post for more information.

Below we describe our commitments in our own infrastructure stack in more detail.

How 2i2c infrastructure ensures this right #

2i2c infrastructure and documentation for it MUST BE as transparent & accessible as possible, so communities can replicate our configuration without having to extract any ‘secret sauce’ from 2i2c. If they choose to, they can also inspect, audit & modify the infrastructure they are paying for and using.

To ensure the Right to Replicate to our communities, 2i2c makes the following commitments to infrastructure we build and operate:

We MUST use only open source software to run our infrastructure. By only using software that is available to everyone on the same terms, we can ensure that communities can replicate the infrastructure without having to negotiate licensing terms with proprietary software vendors. In addition, any changes we make to open source software will be made in public and/or contributed upstream, so communities continue to have access to them regardless of where their infrastructure is.
We MUST NOT directly depend on proprietary cloud vendor specific products or APIs. Instead, we use cloud-managed open source software, or hide the dependency behind a layer of abstraction. This ensures that communities can port their infrastructure to any cloud provider of their choice, or run it on their own hardware with purely open source software.

This set of commitments acts as a business continuity plan for our partner communities, ensuring 2i2c will follow best practices within the open source, open education and open research ecosystems.

[Person's name] on [Topic]

Wed, 01 Jan 1000 00:00:00 +0000

One or two sentences describing a piece of content that you’d like to reference, its main takeaway, its author, and why it’s worth reading (add a link to it and the author’s name).

Some things that stood out to us:

Quotes, images, etc from the post that you’d like to highlight. Just one or two is fine, but add as much as you like. Make sure you’re using exact quotes!

They mention ____ about ____

Pull quote

They also talk about ____

Pull quote

Read more in the original article: article title.

Acknowledgements #

Bulleted list of people and organizations to thank, with links to their spaces.

Enabling / creating / X outcome by doing Y thing

Wed, 01 Jan 1000 00:00:00 +0000

One or two sentences about what happened and who did it. Link to the appropriate people, orgs, etc!

One or two sentences describing why this is important, why it’s valuable, or what it means.

Embed any images, videos, or youtube videos that are relevant. Put images in a file in the same folder called featured.png so it shows up as a feature preview.

Learn more #

Bulleted list of URLs where readers can learn more or follow along.

Acknowledgements #

Bulleted list of people and organizations to thank, with links to their spaces.

EXTRA EXAMPLES #

Service post: blog/2025/status-page/index.md
Impact post: blog/2025/hackweek-shoutout/index.md

Incident report: Brief description of the incident

Wed, 01 Jan 1000 00:00:00 +0000

On MMMM DD, YYYY our cloud infrastructure team experienced an incident with the XXXXX community hub. [See this issue for the full report](LINK TO ISSUE IN 2i2c-org/incident-reports).

What happened #

___ thing happened.
This resulted in ___.
It happened because ___.
It was resolved by ___.

What we learned #

We need to ___.
We learned that ___.
This will happen again if ___.

Acknowledgements #

Thanks to ___ for helping us identify the problem.
Thanks to ___ for helping us implement a solution.

EXTRA EXAMPLES #

contentblog/2025/incident-ucmerced-user-throttling/index.mdindex.md

TIL: How to do XYZ thing for Y outcome

Wed, 01 Jan 1000 00:00:00 +0000

One or two sentences setting context about a common problem.

One to many sections describing something we’ve tried and what we’ve learned in solving that problem.

Embed any images, videos, or youtube videos that are relevant. Put images in a file in the same folder called featured.png so it shows up as a feature preview.

Learn more #

Bulleted list of URLs where readers can learn more or follow along.

Acknowledgements #

Bulleted list of people and organizations to thank, with links to their spaces.

EXTRA EXAMPLES #

Here’s a blog post with an example of what we’re looking for: contentblog/2025/github-action-secrets-forked-repositories/index.mdindex.md

Mon, 01 Jan 0001 00:00:00 +0000

How we are funded #

To sustain and grow our operations, 2i2c receives funding from the following sources:

Membership - Communities join 2i2c’s network to collaborate with our team and peer organizations, pool resources toward shared open source needs, and help drive the direction of the tools that research depends on. It includes managed open infrastructure via our community hub platform. See our membership page for more information.
Co-funded development projects - Members and funders invest in specific development work that addresses shared infrastructure challenges on our roadmap, with improvements flowing back upstream to the open source communities we all rely on.
Core organizational support - We raise philanthropic funding to cover core organizational costs. Our long-term goal is to fund operations entirely through the membership and co-development flywheel, and we’re actively working toward that.

Our service model describes how membership and co-funded projects work together.

Our funders and collaborators #

See our collaborators and funders page for a full list of organizations that have supported 2i2c. You can filter by Funders to see philanthropic supporters specifically.

Mon, 01 Jan 0001 00:00:00 +0000

Our commitment to open technology #

This is part of our open practices.

This page describes 2i2c’s commitment to developing and contributing to infrastructure that is open source now and into the future. More context can be found in this blog post.

Definitions of MUST, MUST NOT, SHOULD, MAY, etc are defined in RFC 2119

All engineering artifacts (code, documentation, etc) produced by 2i2c’s engineering team MUST be licensed under an open source license approved by a non-profit organization that is not 2i2c.¹
Open Source Projects originating at 2i2c, or stewarded by 2i2c, MUST NOT require a Contributor Licensing Agreement that includes Copyright Assignment to 2i2c. ²
The list of external organizations that define licenses we accept are³:
1. the Open Source Initiative
2. the Organization for Ethical Source.
Modifying (1), (2), or (3) MUST be done through a 2/3 majority vote of 2i2c staff. ⁴

These commitments ensure 2i2c’s ongoing support for open source technology and community-owned infrastructure, and constrain us from changing this commitment in a way that would harm our communities. We hope that this builds trust with our communities to rely on 2i2c as a provider and a steward of their infrastructure. See this blog post for more context

This constrains us from writing proprietary engineering code or creating proprietary products. Note that this only applies to 2i2c artifacts, and not those that are created by our member communities. ↩︎
Protects from the most common “bait and switch” licensing problem, where being the sole copyright owner of a project allows us to change the license in the future because we’ve retained ownership over all the code. ↩︎
This constrains us from creating a new non profit that rubberstamps a license that is fundamentally proprietary, while still allowing for experimentation with licenses that try to innovate on OSI. ↩︎
This sets an intentionally-high bar for modifying this policy. In 2025 we aim to re-establish our steering council along with a community advisory board that is tasked with defining policy like this. In the interrim, we choose 2/3 of the organization to be a reasonably high bar for changing this policy ↩︎

Mon, 01 Jan 0001 00:00:00 +0000

Alfred P. Sloan Foundation

Mon, 01 Jan 0001 00:00:00 +0000

The Alfred P. Sloan Foundation is a philanthropic foundation that supports research and education in science, technology, engineering, mathematics, and economics.

Grants from this funder #

Executable Books Project: Grant funding to develop tools for building beautiful, publication-quality books and documents from computational content, including Jupyter Book and MyST Markdown

Berkeley Institute for Data Science

Mon, 01 Jan 0001 00:00:00 +0000

The Berkeley Institute for Data Science is a research institute at UC Berkeley that advances data science education, research, and open source development.

Chan Zuckerberg Initiative

Mon, 01 Jan 0001 00:00:00 +0000

The Chan Zuckerberg Initiative is a philanthropic organization that supports open source software development and scientific research to advance human health and education.

BlueSky: @cziscience.bsky.social

Grants from this funder #

Core Support (2021): 2i2c receives core support from CZI - ~$1.4M over three years to establish 2i2c’s foundational operations
Extended Support (2024): Support from CZI to sustain 2i2c’s mission - ~$700K over one year for continued operations
CZI Global Communities Grant (2022): New project: Open science cloud infrastructure and training for communities in Latin America and Africa - Support for international collaborative programs

Cloudbank

Mon, 01 Jan 0001 00:00:00 +0000

CAL-ICOR is a “Browser-based Interactive Programming and Data Science Platform for Every California Student”. It gives educators and institutions a shared, scalable JupyterHub platform that removes hardware barriers, supports modern data science instruction, and expands access across the state.

From their website:

The California Interactive Computing Open Resource (Cal-ICOR) initiative is a statewide effort to expand high-quality, accessible data science education across the University of California, California State University, and California Community College systems. Led by UC Berkeley and supported by the California Education Learning Lab, Cal-ICOR builds shared infrastructure, curriculum, and instructor support that lower the barriers to offering data-enabled learning, no matter the size, resources, or technical capacity of an institution.

Our mission is simple: ensure that every student in California has access to the tools, skills, and learning environments that prepare them for data-rich careers and civic participation.

Cloudbank

Mon, 01 Jan 0001 00:00:00 +0000

Cloudbank enables and provides “anaged Services to Simplify Cloud Access for Computer Science Research and Education”.

In particular, the CloudBank Classroom project is driving a lot of collaboration with 2i2c via our shared work on JupyterHubs for education.

Code for Science and Society

Mon, 01 Jan 0001 00:00:00 +0000

Code for Science & Society is a nonprofit organization that serves as fiscal sponsor for open science projects and empowers communities to build innovative technology for the public good.

CryoCloud

Mon, 01 Jan 0001 00:00:00 +0000

CryoCloud is a collaborative cloud platform designed to accelerate discovery and enhance collaboration for NASA Cryosphere communities. CryoCloud provides cloud-based computational tools, shared resources, and educational materials to support researchers studying ice-related environments and climate systems.

Design and brand guidelines

Mon, 01 Jan 0001 00:00:00 +0000

Brand guidelines #

Our Brand Guidelines document describes 2i2c’s overall brand and visual style.

Logos #

Square logo (default) #

Logo

Download SVG | Download PDF

Logo light

Logo black

Wide logos #

Wide logo

Download SVG | Download PDF

Wide logo light

Colors #

Primary colors #

Big Blue: #1D4EF5
Pale Blue: #F2F5FC
Black: #000000

Secondary colors #

Midnight: #230344
Mauve: #B86BFC
Forest: #057761
Light Green: #0CEFAE
Magenta: #C60A76
Pink: #FF808B
Coral: #FF4E4F
Yellow: #FFDE17

Design assets #

These two links are only accessible to 2i2c team members.

Figma canvas with design assets

Google Drive folder with design assets

Development Seed

Mon, 01 Jan 0001 00:00:00 +0000

Development Seed is a data and software engineering company that specializes in using satellite imagery, machine learning, and open data.

EarthScope Consortium

Mon, 01 Jan 0001 00:00:00 +0000

EarthScope Consortium is a university-based organization that supports transformative global geophysical research and education. They operate NSF’s GAGE and SAGE Facilities, providing geophysical instrumentation support, data services, and educational resources to the scientific community.

GeoJupyter

Mon, 01 Jan 0001 00:00:00 +0000

GeoJupyter is an open and collaborative community-driven effort to reimagine geospatial interactive computing experiences for education, research, and industry.

GESIS

Mon, 01 Jan 0001 00:00:00 +0000

GESIS - Leibniz Institute for the Social Sciences is a research infrastructure organization that provides data, tools, and services for the social sciences. They also work with CESSDA.

Grants that fund this collaboration #

In cooperation with NFDI4DS, (project number: 460234259)

Give us an idea for the 2i2c blog

Mon, 01 Jan 0001 00:00:00 +0000

We use our blog to highlight the impact we’ve had. Many of these ideas come directly from member and upstream communities! We strongly encourage any of our collaborators to submit an idea for a blog post by clicking the button below.

Submit a blog idea

We want our blog posts to be short, direct, and low-effort (see our blog guide for guidance). Time-box yourself at 2-3 minutes, don’t worry if it isn’t perfect!

If you’d like to fill in the template and share it via Slack or e-mail, that’s fine too! Here’s a markdown block you can copy.

### What happened

- This happened
- This happened

### Any pull quotes?

<!-- Pull quotes are the most impactful thing we can communicate! -->

### Why is it valuable

- Because A
- Because B

### Links to learn more

- Link A
- Link B

### Media and images
<!-- (optional) Have any images we can use in the post? Drag and drop here! -->


### Acknowledgements
<!-- (optional) acknowledgements for contributors, funders, or collaborators. -->

-
-

Gordon and Betty Moore Foundation

Mon, 01 Jan 0001 00:00:00 +0000

The Gordon and Betty Moore Foundation is a private foundation that supports scientific discovery, environmental conservation, and patient care improvements.

Grants from this funder #

Pangeo Climate Data Lab (2020): $500,000 over two years for managing and developing cloud infrastructure for the Pangeo Project through Columbia University

Howard Hughes Medical Institute

Mon, 01 Jan 0001 00:00:00 +0000

The Howard Hughes Medical Institute is one of the nation’s largest private funding organizations for biological and medical research, investigating fundamental biological processes and supporting innovative research that transforms biomedical knowledge.

Grants funding this project #

Several projects with HHMI are supported by National Institute of Mental Health (NIMH), grant number RF1MH130623.

Impact

Mon, 01 Jan 0001 00:00:00 +0000

Invest in Open Infrastructure

Mon, 01 Jan 0001 00:00:00 +0000

Invest in Open Infrastructure helps funders and research institutions understand how to effectively support digital infrastructure, while JROST is a collaboration between funders committed to supporting open tools for science.

Join our mailing list

Mon, 01 Jan 0001 00:00:00 +0000

Our mailing list shares the most important information with our community, and is easier to keep up with than the large number of blog posts we share. Here’s what to expect:

Summaries of our contributions and impact over the past month.
Announcements about the most important information from 2i2c.
Announcements from the open source and open science communities.
Guidance for how you can help our open science and open source network.

To sign up, subscribe below:

Jupyter Book

Mon, 01 Jan 0001 00:00:00 +0000

Jupyter Book is an open source project for building beautiful, publication-quality books and documents from computational material. It allows users to create interactive books from Jupyter notebooks, Markdown files, and other computational content, supporting rich formatting and cross-references.

JupyterHub

Mon, 01 Jan 0001 00:00:00 +0000

JupyterHub is a multi-user server that manages and spawns multiple instances of single-user Jupyter notebook servers. It enables organizations to provide managed Jupyter environments to groups of users, supporting authentication, resource management, and scalable deployment on cloud and on-premise infrastructure.

NASA VEDA

Mon, 01 Jan 0001 00:00:00 +0000

NASA VEDA (Visualization, Exploration, and Data Analysis) is NASA’s cloud-based data visualization and analysis platform that makes Earth science data more accessible and usable for researchers, policymakers, and the public.

2i2c provides interactive computing infrastructure for VEDA, enabling users to explore and analyze NASA’s vast earth science datasets through JupyterHub environments in the cloud.

NumFOCUS

Mon, 01 Jan 0001 00:00:00 +0000

NumFOCUS is a nonprofit organization that serves as a fiscal sponsor for open source scientific computing tools in Python, R, and Julia.

Openscapes

Mon, 01 Jan 0001 00:00:00 +0000

Openscapes is an approach and a movement that helps researchers and those supporting research find each other and feel empowered to conduct data-intensive science. They champion open practices in environmental and Earth science to help uncover data-driven solutions faster.

Our Founding Team

Mon, 01 Jan 0001 00:00:00 +0000

Our member communities

Mon, 01 Jan 0001 00:00:00 +0000

This is a list of organizations with communities currently in our member network, and a resource for community members to quickly find and access their hub URL¹.

Member organizations support 2i2c’s impact and our commitment to open practices with membership fees. Each member gets one or more community hubs run by our team. Our collaborators page lists members that have contributed additional resources for Directed and Foundational open source contributions.

Learn about membership

Albany High School

Berkeley City College

Borough of Manhattan Community College, CUNY

Cal Poly Humboldt

Carnegie Mellon University

Chabot College

Chaffey College

Chicago State University

City College SF

College of San Mateo

College of the Redwoods

CSU Maritime

Diablo Valley College

East Los Angeles College

East Tennessee State University

El Camino College

Ephemeral Interactive Computing for NASA Communities

Foothill College

Fresno City College

George Washington University

Golden West College

HHMI

High Schools Experimental

Jupyter Health

Kean University

Laney College

London Interdisciplinary School

Long Beach City College

Los Angeles City College

Los Angeles Harbor College

Los Angeles Valley College

Mendocino College

Michigan Technological University

MiraCosta College

Moreno Valley College

NOAA Fisheries Openscapes

Oakland City University

Pasadena City College

San Jose Community College

San Jose State University

Santa Barbara City College

Santa Barbara City College Dev

Santa Rosa Junior College

Santiago Canyon College

University of California, Merced

University of California, Santa Cruz

University of Chicago

University of Maryland

University of North Dakota

University of Virginia

West Los Angeles College

This is automatically generated using our community hub configuration data in the 2i2c infrastructure repository. Clicking each logo will take you to the community hub for each community. ↩︎

Our organization

Mon, 01 Jan 0001 00:00:00 +0000

Pangeo

Mon, 01 Jan 0001 00:00:00 +0000

Pangeo is a community platform for Big Data geoscience. It promotes open, reproducible, and scalable science by building tools and infrastructure for working with large datasets in the geosciences, including support for climate data analysis on cloud platforms.

Project Jupyter

Mon, 01 Jan 0001 00:00:00 +0000

Project Jupyter is an open source project that develops interactive computing tools including Jupyter notebooks, JupyterLab, and JupyterHub. The project supports interactive data science and scientific computing across multiple programming languages, providing a foundation for reproducible research and education.

Project Pythia

Mon, 01 Jan 0001 00:00:00 +0000

Project Pythia is an educational initiative that provides open access training resources to help geoscientists learn cloud computing and open science tools.

Grants that fund this project #

NSF award 2324302

STRUDEL

Mon, 01 Jan 0001 00:00:00 +0000

STRUDEL is an open source project creating and stewarding resources to enable more usable scientific software experiences.

It is 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.

STRUDEL 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.

The Catalyst Project

Mon, 01 Jan 0001 00:00:00 +0000

The Catalyst Project is a collaborative initiative focused on advancing scientific computing and cloud infrastructure for research communities. They work to accelerate the adoption of cloud-native scientific computing tools and practices.

Grants funding this project #

A $1.5M award from CZI funded this project ( Zenodo entry).

The Navigation Fund

Mon, 01 Jan 0001 00:00:00 +0000

The Navigation Fund focuses on supporting organizations that are building critical infrastructure for the future of research and education, particularly those working to create sustainable models for open source and open science initiatives.

Grants from this funder #

The Navigation Fund awarded 2i2c approximately $1.5 million over 2 years in 2024 to identify and build a scalable sustainability model for the organization. This strategic investment enables 2i2c to develop comprehensive sustainability strategies and establish long-term financial resilience.

2i2c

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 #

Introducing Jupyter Book 2 at FOSDEM 2026

Learn more #

Acknowledgements #

Better sharing UX with nbgitpuller and contextual error handling

TL;DR #

What is nbgitpuller? #

How does nbgitpuller work? #

When it goes wrong #

Merge conflicts #

Error UX (old) #

Error UX (new) #

Learn more #

Acknowledgements #

New Jupyter Book / MyST stack release (Jan 2026)

Where we contributed #

Acknowledgements #

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 #

Enabling CloudBank to safely manage their own cluster infrastructure

Learn more #

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 #

Improving our community hub reliability and stability in Q4 2025

What we accomplished #

We improved infrastructure reliability for our communities #

We became more efficient, responsive, and focused #

The improvements we made #

Infrastructure improvements #

Process improvements #

Looking forward #

Learn More #

Faster reporting of user home directory sizes

Using jupyterhub-home-nfs for near-instant disk usage metrics #

Try it out #

Coming next #

Acknowledgements #

Supporting NASA Openscapes Champions with Cloud Infrastructure

Adding User Group Insights to Cloud Cost Dashboards with Grafana

Learn more #

Acknowledgements #

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 #

Creating a re-usable redirect generator for Jupyter Book 1 migrations

Learn more #

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 #

Using `jupyterhub-home-nfs` for near-instant disk usage metrics #

The `pull_request_target` workflow #