Organization | 2i2c

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.

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.

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.

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!

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.

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. ↩︎

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. ↩︎

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.

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.

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.

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.

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.

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.

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. ↩︎

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.

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.

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!

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.

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.

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.

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.

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.

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.

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.

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!

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 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! ↩︎

Organization | 2i2c

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 #

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 #

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 #

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

Strengthening the foundations of Jupyter #

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

What Makes CZI’s Approach Different? #

Thank You, CZI #

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

Learn more #

Acknowledgements #

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

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

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

Two key objectives #

Four pilot activities #

Review Pull Requests from non-maintainers #

KPIs #

Issue Triage office hours #

KPIs #

Sponsoring and Mentoring new Maintainers #

KPI #

Increase bus factor and diversity of people making releases #

KPIs #

Criteria for upstream projects to support #

How we’ll implement this #

Who is responsible #

How we’ll fund this work #

Next step: Learning in public #

Acknowledgements #

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

Acknowledgments #

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

Everybody has an open source hat and a stakeholder hat #

Directed Contributions benefit the stakeholder you represent #

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

Foundational Contributions support a healthy open source community #

We plan Foundational Contributions alongside our engineering roadmap #

What’s next #

Product and team highlights from Q2 2025

Group-level resource monitoring #

Improve creating and sharing custom environments #

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

A better onboarding experience for our communities #

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

Another update coming in Q3 #

Acknowledgements #

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

Delivery and Enablement #

How we did #

Product and Services #

How we did #

Business Development #

How we did #

Concluding thoughts #

Acknowledgements #

Our Product and Service goals for Q2 2025

Give administrators more control #

Improve creating and sharing custom environments #

Out-of-the-box Jupyter Book support #

A better onboarding experience for our communities #

Improve and formalize the services we deliver to our communities #

Another update coming in Q3 #

Acknowledgements #

Our product highlights from Q2 2025

User storage quotas #

Automated backups for GCP hubs #