oss-archetypes

Archetypes

This work builds on the Mozilla Open Source Archetypes’, adjusting the archetypes in a few key ways:

• Tailored for research software: The project archetypes have been adapted to reflect the nuances of research software, such as the role of domain expertise and the structure of research groups
• Action-oriented: While understanding and common language is important, we wanted to ensure that this framework was also something you could put into practice through tailored guidelines.

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	Galaxy	QIIME2	UCSC Genome Browser	most early stage projects	Seurat	IQ-TREE	bokeh	Most “gradware”

This site is open source. Improve this page.