This work builds on the Mozilla Open Source Archetypes’, adjusting the archetypes in a few key ways:
Note: Currently, we’ve opted to omit licensing from this framework as we continue to develop it for our uses at CZI. We would welcome community contributions to this document to include suggested licensing for each archetype.
| Multi-institutional collaboration Projects with multiple formal host institutions; often larger in scale |
Controlled ecosystem Core + plug-in model |
Scientific Platform Hosted applications with a single canonical instance |
Rocket Ship to Moon Prototypes with rapid iteration by the founder |
Rocket Ship to Alpha Centauri More mature projects still owned by the founder |
Scientific Library / Pipeline More mature specialized projects where any expert can contribute |
Wide Open Democratic projects open to anyone |
Bathwater “Might as well” make it open (abandoned rocket ships) |
||
|---|---|---|---|---|---|---|---|---|---|
| Most relevant strategic considerations Starting Point A |
Primary strategic goal(s) of your project What is your motivation for being open source? |
Find well-resourced partners working on shared goals to decrease fragmentation and improve project sustainability. | Create a sustainable and more standardized ecosystem in which the founding organization retains strong influence. | Democratizing access to analysis tools / data (often via a centralized GUI), which may have a standard setting effect for a field. | Fast and focused development to test a scientific or technological hypothesis | Fast and focused development of a high-confidence solution to a high-priority problem. Founders retain strong influence. | Pool development efforts to solve shared core problems & standardize analysis. Open to anyone with domain expertise. | Large-scale collaboration; community can become self-sustaining | Unmaintained projects open sourced for the sake of experimenting in the open: maybe someone else will find this useful. |
| Starting Point A | Most important OSS practices Practices to focus on to set your project up for success |
- Consensus building & governance |
- Contributor community - Consensus building & governance - User friendliness |
- User friendliness - Start thinking about sustainability - this is a high risk archetype long-term |
- Minimum SOPs |
- Start thinking about sustainability - this is a high risk archetype long-term - User friendliness |
- Contributor community management - Consensus building and governance - User friendliness - Sustainability |
- Contributor community management - Consensus building and governance - User friendliness - Sustainability |
Minimum SOPs |
| Starting Point A | Main risks / drawbacks of this approach | -Sometimes off-putting to individual contributors who are outside the organizations |
- Balancing priorities between the core vs plug-ins - Must be willing to compromise to avoid forks - Complex power dynamics |
- Low “bus factor” is a concern for long-term sustainability - Resource intensive as execution is usually all in-house and users are often non-coding - Tightly coupled frontend and backend make it harder to contribute and / or adapt for adjacent use cases. |
- Everything depends on success of original vision - Missing out on partnership opportunities, making competition more likely |
- Everything depends on success of original vision - Missing out on partnership opportunities, making competition more likely - Low “bus factor” is a concern for long-term sustainability |
- Standard setting relies on broad adoption - High barriers to entry; relatively small developer pool - In rapidly evolving fields, requires a lot of maintenance to keep up with changing best practices |
- Founders must be willing to share decision making with the community - Significant effort required to maintain onboarding paths & manage all participants |
- Expectation management is critical |
| Control & resourcing Starting Point B |
Typical founder type | Organizations | Organizations | Organizations | Organizations or individuals | Organizations or individuals | Organizations or individuals | Organizations or individuals | Organizations or individuals |
| Starting Point B | Typical governance: who makes decisions? E.g., community developer-driven vs in-house product vision driven |
Committee of organizational representatives | Founding organization is a benevolent dictator, with significant willingness to compromise to avoid forks | Development team and leadership of single host institution | Development team and leadership of single host organization / lab | Development team and leadership of single host organization / lab | Core developer-driven: small group of expert core contributors | Group-based; consensus / democratic | N/A |
| Starting Point B | Typical contributor type: who executes? E.g., in-house teams, external developers, partner organizations, etc |
- Mostly in-house teams at the partner institutions |
- Core: developer team from single organization - Plug-ins: wide open community |
- Developer team from single organization, possibly in collaboration with experts from the relevant field |
- Close-knit developer team from single organization / lab |
- Close-knit developer team from single organization / lab - Collaboration only available from trusted partners who share a very specific vision |
- Developers with (access to) expertise in the relevant field |
- Open to anyone |
N/A |
| Development model | Development speed | Usually moderate, but depends on needs of partner institutions | Core: gets slower over time as the ecosystem stabilizes. Plug-ins: depends on size of the contributor pool and breadth of problems |
Moderate and ongoing, depending on user needs and pace of scientific advancement | Fast; escape velocity | Faster than scientific library because of lower communication and process overhead | Moderate and ongoing, adapting to user needs and pace of scientific advancement. May get slower over time as the underlying scientific methodology and the library stabilize. | Slow-medium; some process overhead | N/A |
| User community engagement E.g., do users become developers? |
Welcoming but formal; difficult for individuals who are outside the organizations to contribute | Focused on developer support for plug ins | Service-oriented for end users. Minimal contributor community. | Focused on acquiring and learning from a core group of early adopters. | Service-oriented, focused on building out user community. | Users are (usually) experts and may become contributors; building consensus and incorporating their input is key. | Variable. Users may become contributors. | N/A | |
| What does success look like? | Markers of success What should we measure? | - Partners contributing at equal and high levels - Longevity of contribution by committers - Variety of organizations contributing |
- Stability of the core - Quality of plug-ins (code and functionality) - Number of end users |
- Adoption and use of tool by intended audience |
- Speed of development - Achieving original technical goals and testing hypothesis |
- Speed of development - Increasing user base, becoming community standard |
- Adoption by users in intended domain (perhaps even dominant adoption) - Attracts contributors with strong expertise - High quality of code |
- Growth in number of contributors - Efficiency of contribution - Diversity of voices in decision making |
- Forks |
| Examples External and internal (CZI) | - Galaxy Acquire |
- QIIME2, napari |
- Nextstrain (web), UCSC Genome Browser, Genbank - CZID (web), cellxgene, napari hub |
- Nextflu (pipelines - early days) |
- Nextstrain (pipelines - matured) - Shasta |
- Vispy, scanpy - napari |
- scipy |
- Most “gradware” - Galago, Ontology UI, prototype napari plugins |