How open source projects start, grow and flourish

While there are plenty of models for traditional businesses, if you start to look at open source the picture gets cloudy, fast.

A team at Mozilla went on an internal mission to clarify what successful models looked like and ended up with a 37-page report titled “Open source archetypes: A framework for purposeful open source.” Published as a booklet, available online and CC-licensed, it dissects topics including benefits, the basics of licensing and practical questions to ask about open-source projects.

Archetypes are at the heart of the document. The team (unnamed to reflect the collaborative nature of the initiative) states that while projects can change from one archetype to another — either through deliberate and guided transformation, or a gradual and incremental evolution —they wanted to chart how open-source projects begin and evolve.

The report breaks it down into 10 of them, offering examples as well as pros and cons: Business-to-business, multi-vendor infrastructure, rocket ship to mars, controlled ecosystem, wide open, mass market, specialty library, trusted vendor, upstream dependency and bathwater.

Clearly these cover a lot of ground, here are some examples of the less self-explanatory types:

Rocket ship to mars

Examples: Meteor, Signal
These feature a small full-time core team completely focused on a well-articulated and highly specific goal. Their open source strategy is often rooted in a commitment to transparency and providing insurance…they want to instill confidence among developers and users to promote adoption. This is a frequent type for a starting point for projects that transition, for example, to B2B.

Wide open

Examples: Rust (present day), Apache HTTPD
These projects actively welcome contributions from any source and tend to get contributions at all levels: from individual developers providing one-off bug fixes to sustained organizational contributors. The authors say this is a good model for projects that aim to serve the same technical purpose over a long period of time and for which stability and reliability are more important than rapid development of the code base or fast adoption of field-specific innovations.

Bathwater

No examples provided
Described as “code dumped over the wall,” purely about distribution, not about any particular mode of production. “Think of it as the ground state of open source projects: someone publishes code under free license but invests no follow up” to build an open-source community. “Code gets dumped this way quite often and ‘throwing code over the wall’ has a bad reputation among open-source practitioners.” Despite this, the report authors note it can be useful – as an initial foray into open source for companies, for more experienced companies it can be a “reasonable state” for an abandoned initiative and because it leaves forkable code, anyone can try to move it to another archetype.

Download the report or check out the full chart below: