"Open source" is a broad term that encompasses many different types of projects. There is a wide range of open source approaches, and sometimes it helps to think through how your open source approach matches your goals, resources, and environment.
We often see "open source project" used as a catch-all term to describe very different projects that share only the fact that their source code is distributed under an open source license. We don't have a common vocabulary to discuss open source development in ways that take account of important differences between various types of open source project.
This report is a first step in providing that common vocabulary. OTS prepared the first edition for Mozilla in the first half of 2018; we are currently working on a second edition with Mozilla. The report catalogs a number of open source archetypes we have observed through watching many projects over a couple of decades. We have found these archetypes to be a useful resource when crafting strategy, weighing tradeoffs, and committing support to open source endeavors.
We hope it is useful to you as you design open source initiatives, weigh tradeoffs in strategy, and pick metrics to track success. The archetypes we list are useful comparison points for anybody trying to maximize the benefits of their open source investment.
The boundaries between these archetypes are fuzzy. One shouldn't expect a real-world project to fit perfectly into exactly one archetype. The archetypes are not a taxonomy: a project may fit multiple archetypes at once, and we had heated discussions on how to characterize some projects. Many successful projects change archetypes over their lifecycle.
This report is version 1, with version 2 currently under development. We have been collecting notes for an update, and we welcome input. We know many people will read this and have views worth adding to the conversation; please share those views with us.
There are two main ways to contribute to this report. First, there are
the usual mechanisms available through GitHub. Please file issues,
send pull requests, and review pending contributions. The same
distributed collaboration mechanisms we use to build software can be
used to edit a text document. The second way to contribute is to send
us feedback and suggestions via email to archetypes {_AT_} opentechstrategies.com. That email will influence our thinking but
won't make it into the public discussion unless it results in us
filing a ticket or making a change to the document on GitHub.
This report is written in
LaTeX, and uses the OTS
Doctools system
to generate the PDF output. Once you have the ots-doctools
infrastructure installed properly, running make should just work, if
you're on a Unix-like system that has GNU Make. We don't have
experience building this on Windows, but if you do, please let us know
how it goes and how we can improve these instructions.
This document was originally authored by Karl Fogel, James Vasile, and Cecilia Donnelly of Open Tech Strategies as a work-for-hire under contract to Mozilla Corporation. It is Copyright 2018 Mozilla Foundation and Open Tech Strategies and licensed to you under CC-BY-SA. To provide attribution, please link to this repository.
Open Tech Strategies performs ongoing maintenance of this document and repository, with the support and participation of Mozilla. Mozilla reviews drafts, but does not exercise editorial control over this repository.
Mozilla publishes a graphically enhanced PDF version of this document for public distribution (see Patrick Finch's post announcing it). This LaTeX is the source for that PDF's content, and is the master text for purposes of ongoing maintenance. When version 2 comes out, it will likely be similarly graphically enhanced, but in the meantime anyone can build intermediate working PDFs from this repository.