Open Source Archetypes: A Framework For Purposeful Open Source. 2018. Mozilla Foundation, Open Tech Strategies.

[anakinsbrna]

This paper describes open source archetypes which could be a useful framework for us. At the end of there are practical questions suggested to ask about a project. While reading, I was wondering:

Which archetype our individual projects/ products would correspond:

What are our individual projects / open source pieces?

• Home Assistant
• ESPHome
• Music Assistant
• Open Protocols
• Voice
• …

Other Practical Questions to Ask About a Project as presented in the paper:

1. How many separable open source pieces are there?
2. Who is expected to participate in the project, and why?
3. How is the code expected to be deployed?
4. How is the project managed and governed?
5. What is the project's business model or sustainability model?
6. Which open source license does it use?
7. Does technical architecture match social structure?

---

---

My notes:

Benefits of Open Source

• Lead a standardization effort in a particular area
• Improve product quality
• Amplify or expand developer base
• Increase size or quality of developer hiring pool
• Improve internal developer morale and retention
• Improve internal collaboration within the organization
• Establish a basis for product reputation
• Establish a basis for organizational brand and credibility
• Improve market acceptance by eliminating customers' and partners' exposure to risk inherent in proprietary approaches
• Stop someone else from establishing early dominance in an area
• Engage with users
• Provide a framework for collaborating with partners
• Provide transparency to customers and partners
• Increase insights into partners' (or competitors') strategy and goals

---

Archetypes

B2B Open Source (Android, Chromium)

• Aims at ubiquity, spurring OEM adoption by partners and competitors across the industry
• Google does not derive much direct revenue from Android — its popularity creates opportunities; Android users default to Google services
• Strategy for gaining marketshare as a revenue opportunity
• Works best run by large companies with market pressure, multiple distribution channels, and considerable financial resources
• Community: Lead company does not put much emphasis on nurturing or welcoming contributors unless they are important organizational partners
• Typically driven by corporate business strategy and figures into executive-level decisions

Multi-Vendor Infrastructure (Kubernetes, OpenStack)

• Provides facilities to a wide array of other businesses; addresses business needs rather than individuals
• Open to relatively lightweight participation
• Difference from B2B: contributors often continue to participate after switching employers, indicating that multiple organizations use the software as infrastructure
• Individuals are more likely to contribute than in B2B, though motivation is still more often organizational/professional than individual
• Community: Welcoming but formal — often difficult for individuals to enter; requires a high level of resources

Note on B2B and Multi-Vendor Infrastructure: The largest advantage of open source in both archetypes is standardization enabling reconfiguration and customization, which drives adoption at scale. This dynamic would be difficult to achieve with proprietary approaches.

Rocket Ship to Mars (Meteor, Signal)

• Small full-time core teams with well-articulated focus and goals
• Often led by charismatic founders
• Strategy rooted in transparency and instilling confidence among developers and users
• Tend not to play well with others — highly committed to roadmap, not focused on nurturing a community
• Goal is not to create an ecosystem of plug-and-play modules but a core product marketable as a standalone service
• Biggest challenge: detecting and taking advantage of organizational collaboration opportunities
• After launch, it is important to set public expectations accurately — clear messaging helps people decide whether they want to follow and participate
• Community: Difficult to enter, focused on core group

Controlled Ecosystem (WordPress, Drupal)

• Diverse community motivations with a shared understanding that the founder or some credible entity will act as a "benevolent dictator"
• Requires experienced open source community management on the part of project leaders
• Works best when supporting out-of-core innovation and customization (e.g., via a plugin system)
• Core functionality structured as plugins that determine end-user experience; core project can eventually become infrastructure
• Community: Welcoming, often with structures designed to promote participation

Wide Open (Rust, Apache HTTPD)

• Actively welcomes contributions from any source at all levels
• Values investing in contributors relatively highly — core team is willing to pay a high opportunity cost in terms of code not written or bugs not fixed to encourage or onboard new contributors
• Good archetype for projects that aim to serve the same technical purpose over a long period where stability and reliability matter more than rapid development
• Especially effective when a significant percentage of the user base is technically oriented
• Most contributors are only lightly involved, making occasional small-scale contributions; only few participate with higher intensity
• Typically settles on multi-party governance in a roughly democratic form — contributors expect to climb the influence ladder by investing time and making quality contributions
• Possible for a single organization to retain significant influence (typically by investing more developer time), but it must be careful not to demotivate others
• Simply declaring a project "wide open" is not enough — works best when visibly influenceable by input from multiple sources
• Community: Very welcoming, with formalized systems
• Benefits: Enables large-scale collaboration; community can become self-sustaining and allows the sponsoring organization flexibility in deciding how involved it wants to stay

Mass Market (Firefox, LibreOffice, MediaWiki)

• Similar to Wide Open but with a protective layer around the contribution intake process — too many users and too many opinions
• Like B2B, tends to drive down the price of directly competitive products (e.g., LibreOffice vs. Microsoft Office)
• Less likely than B2B to affect complementary products — aimed at individuals rather than intermediary organizations
• Opportunities from economies of scale: good translation coverage, A/B testing and user surveys, ability to influence web standards, thought leadership in a broader political sense
• With developer-oriented software, it usually pays to listen to the most vocal customers; Mass Market projects oriented toward non-technical users should be guided more by explicit user research
• Community: Fully open but relatively brusque for the majority of users; users-helping-users pattern; the development team can often seem distant or unresponsive

Specialty Library (libssl, libmp4)

• Provides base functionality for a set of functions whose implementation requires specialized knowledge
• Hardly any competing libraries
• Can power standardization and increase adoption of formal and informal standards
• High coding standards; little developer outreach, no hand-holding of new developers

Trusted Vendor (MongoDB, Hypothes.is, Coral)

• Project direction steered by a central party (usually the founding organization)
• Encourages an active commercial ecosystem, requiring occasional restraint or non-competitive behavior on the part of the primary maintainer
• Guiding principle: "nobody can build everything" — customers want a complete solution from a vendor, but switching costs are high; open source is the antidote to vendor lock-in
  • Enables competition among vendors
  • Tends toward open standards
  • Strong enough to shift customer preferences
  • "Wide open" characteristics serve as signaling mechanisms — even if customers never take direct advantage of collaboration, they reassure
• Can jump-start third-party vendor and integrator ecosystems, potentially shifting the project toward something more like Multi-Vendor Infrastructure — though the primary maintainer retains more control over project direction than in that archetype
• Requires commitment about what the maintaining organization will and won't do with its control — both in terms of technical roadmap and in terms of allowing or encouraging other vendors to flourish
• Must avoid exclusive or monopoly powers and avoid competitive privileges that usually come with being a project's prime mover
• Community: Users and contributors have input to roadmap but do not contribute directly

Upstream Dependency

• Intended as a building block for other software; user base is made up of developers
• Adoption = third-party integration of the software into their products
• For smaller or more specialized libraries, similar to Wide Open — but quality of maintainers and contributors differs
• Attracting technical investment depends on two factors: replaceability, and which downstream projects depend on them
• Much contributor attention and investment is simply being part of discussions
• Community: Welcoming, specifically for one-time contributions
• Benefits: Connections to downstream projects offer insights into market and usage trends

Bathwater

• Code "dumped over the wall" — purely about distribution, not production
• Ground state of open source: publishing code under a free license with no investment in building open source dynamics
• Public repository is often not for active development — just a container for periodic release snapshots
• Has a bad reputation among open source practitioners
• Benefits: Unlikely to generate typical open source beneficial effects, but can serve as: an initial foray for inexperienced organizations (low risk, sends signals of openness); or a reasonable final state for an abandoned initiative — explicitly putting code into Bathwater mode and giving the world permission to take it up
• Code is treated like a forkable resource — users don't expect anything and can treat it as a greenfield opportunity
• Community: Dormant to non-existent

---

Evolution Between Archetypes

Projects can and often do change archetypes — either deliberately or through guided transformation.

Examples:

• Firefox: Rocket Ship to Mars → closer to Mass Market
• WordPress: Trusted Vendor → Controlled Ecosystem (not natural; occurred with the acquiescence and likely encouragement of primary commercial backer Automattic)

Most common transitions:

• Rocket Ship to Mars → another archetype (natural progression from small, focused, unified core team to broader involvement)
• B2B → Upstream Dependency

Key principle: Always be alert to the possibility of transformation. At strategic points in a project's lifecycle, ask whether a purposeful transformation might be called for — and whether there might be bottom-up pressure pushing the project toward a particular new archetype.

---