arch-rocket-ship-to-mars.ltx

\hypertarget{archetype:rocket-ship-to-mars}{}
\subsection{Rocket Ship To Mars}\label{archetype:rocket-ship-to-mars}

{\bf Examples:} \emph{Meteor, Signal}

{\bf 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 \emph{transparency} and
providing \emph{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''\footnote{See
  https://signal.org/blog/license-update/, where Moxie Marlinspike
  writes ``We like the GPL for the quality control that it provides.
  If someone publicly says that they're using our software, we want to
  see if they've made any modifications, and whether they're using it
  correctly.''}.)  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 \emph{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.

\begin{itemize}
\item {\bf Licensing}: Usually non-copyleft, but may be copyleft under
  certain circumstances.
\item {\bf Community standards}: Difficult to enter; focused on the
  core group.
\item {\bf Component coupling}: Tight, in order to ship one core
  product.
\item {\bf Main benefits}: Achieves a quick, focused effect on a
  specific area; if successful, can co-opt competition.
\item {\bf Typical governance}: Maintainer-led by the founding
  group.
\end{itemize}