Rocket Ship To Mars Archetype
Characteristics: “Rocket Ship To Mars” projects are characterized by a small full-time core team that is wholly focused on a well-articulated and highly specific goal. They are often led by charismatic founders and enjoy a funding runway sufficient for bootstrapping. Their open source strategy is often rooted in a commitment to transparency and providing insurance: they want to instill confidence among developers and users in order to promote adoption, and being open source is one ingredient in doing that.
Rocket Ships To Mars tend toward non-copyleft licensing when their goal is broad adoption by the tech industry at large, but may use copyleft licensing when aiming for deployment and usage scenarios where there is no particular advantages to non-copyleft. (For example, Signal notes that their use of the GPL-3.0 license is primarily for “quality control”8 .) In any event, Rocket Ships To Mars tend not to play well with others. Every ounce of fuel goes to thrusters, which leads little energy left over for the hard work of nurturing a contributor community.
Rocket Ships To Mars typically do not invest a lot of effort in encouraging broad contributorship, not so much because they wouldn’t welcome contributions as because it is hard to find contributors who share the project’s intensity and specificity of vision, and who are sufficiently aligned with the founders to take the time to make their contributions fit in. These projects are also usually trying to reach a convincing alpha release as quickly as possible, so the tradeoff between roadmap speed and contributor development looks different for them than for other types of projects.
Similarly, the components of such projects are generally tightly coupled: their goal is not to create an ecosystem of plug-and-play modules, but to create one core product that can be marketed as a standalone service.
The biggest challenge for Rocket Ship To Mars projects is usually to detect and take advantage of the right organizational collaboration opportunities. Some strategic partnerships are worth sacrificing momentum for, especially when they could affect the project’s direction early on.
Part of the purpose of specifying this archetype is to help Mozilla give itself permission to run projects like this when appropriate. There are times when Mozilla may want to press forward to some goal and not stop (at least for a while) to deal with other participants. At the very least, the people advocating for this should have a model to point to, and the people arguing against it should have a clear idea of what it is they’re arguing against. When a Rocket Ship To Mars project is launched, it is important to set public expectations accurately. Some observers will be interested in going to Mars, and some will not be, but at least when there is clear messaging each observer can make an informed decision about how much to invest in following the project or in aligning themselves with it sufficiently to be able to participate on Mozilla’s terms.
Examples: Meteor, Signal
Licensing: Usually non-copyleft, but may be copyleft under certain circumstances.
Community standards: Difficult to enter; focused on the core group.
Component coupling: Tight, in order to ship one core product.
Main benefits: Achieves a quick, focused effect on a specific area; if successful, can co-opt competition.
Typical governance: Maintainer-led by the founding group.
@quaid @jcanovasi @evanleibovitch Please add feedback and insights in the comment area below.