The following are major considerations in how we think about open source communities. For policies related to funding, see Funding for open source.
Upstream first¶
Whenever possible, we should improve our own infrastructure via upstream contributions to communities where we are not the sole stakeholder. We should prioritize key communities and upstream communities that align with our values. We know this will take extra effort from us - doing things on your own is faster, but doing them together with open source communities leads to a healthier and more sustainable ecosystem.
Upstream work can’t be done on nights and weekends¶
Doing work in upstream open source communities is central to our work, and is treated as “on the clock”. Our sustainability strategy should aim to make these upstream contributions a realistic and sustainable part of our daily activities. However, be mindful of the time you’re spending in upstream spaces, and talk to other team members to make sure you aren’t putting too much burden on them.
A good balance to shoot for is:
80%: Focus on 2i2c’s mission, with an “upstream first” mentality. You can take whatever time you need to make upstream changes that serve 2i2c’s interests in an inclusive way.
20%: Upstream-driven contributions. The work you do in upstream communities does not need to be driven by 2i2c’s interests or strategy, though these communities should be related in some way to our work. Spend your time in the way you want to have the most impact.
Center the community’s strategy and mission¶
We wear multiple hats when working with upstream communities. While 2i2c’s mission and strategy aim to support open communities, they are still independent entities with their own goals. We should recognize these differences between 2i2c and upstream communities, and be a model for how to balance the two in a healthy way. Our upstream contributions should center the needs of upstream communities over those of our own. For example, spend extra time “chopping wood and carrying water” like issue triage, bug fixes, or release maintenance. Be aware of potential conflicts of interests with your 2i2c hat on, and hold yourself (and others) accountable for acting in a community’s best interests.
Decisions should be made with the community, not us alone¶
When we do work in upstream communities, we should represent and advocate for 2i2c’s needs, but we should do so in partnership with other community members and leaders. Do not make unilateral decisions without getting consent from others, and invite active participation and collaboration. For example:
Open issues to ask for input and objections for any major new efforts.
Invite reviews of pull requests from non-2i2c team members and make sure others are on board with our proposals before taking action.
Put extra effort into documentation to ensure that we share context with others in the community.
Represent our communities, not just 2i2c¶
When we advocate for 2i2c’s needs in GitHub issues, forums, etc, root your arguments in the communities we serve, not just “2i2c” as an organization. This makes it clear that our job is to represent the network of research and education communities that we support. It is a small but impactful way to frame our needs, and brings our mission into focus for those that don’t have context on 2i2c.
For example, instead of saying “2i2c wants ____”, try saying:
“Our communities would benefit from ____”
“One of our communities (community X) would like ____ because...”
Don’t plant flags¶
We are in a privileged position to have both connections to established universities and funding bodies, as well as several team members with leadership roles in open source communities. We should use this position to make it easier for those outside of 2i2c to gain leadership roles and contribute to open source.
We recognize that 2i2c is not the same thing as any open source community, and we should avoid overpowering community dynamics just because we have access to resources. Our goal is to contribute and support, not to dominate.
Make more than just technical contributions¶
We prioritize work that builds a healthy, inclusive culture in upstream communities, not just getting in technical improvements that we need for our infrastructure. Look for leverage points to make a community healthier overall, not just for 2i2c’s technical interests.
Give attribution to others¶
Large open source communities (e.g., Jupyter) have a large platform, and can boost the visibility of any stakeholder inside of it. We often have the ability to use this platform to tell others about our work (e.g., presentations, blog posts, etc). Remember that open source is a team effort that requires many kinds of contributions, and credit should not only go to the organization that made a technical change.
While we should not hesitate to recognize 2i2c’s contributions, be generous in giving attribution to others as well. Focus on the community and its accomplishments first, and note 2i2c’s contributions as a secondary fact in collaboration with others.