how-to-use.ltx

\hypertarget{how-to}{}
\unnumberedsection{How to Use This Document}\label{how-to}

The archetypes presented here (listed in section \fullref{archetypes},
p. \pageref{archetypes}) are not business strategies in themselves;
rather, they are consequences of business strategy decisions.

For any project that Mozilla starts, acquires, or revives, the
question of how to run it must start with the question of what Mozilla
is trying to accomplish with it in the first place.  Once there is a
clear understanding of the project's goals, it becomes possible to
discuss what kind of an open source project it should be.

We therefore suggest that this report be used as follows:

\begin{enumerate}

  \item First articulate to all stakeholders the purpose of the project:
    what aspects of Mozilla's mission will it serve, and, from a
    product perspective, how will it do so?  Why has Mozilla
    undertaken this project?  These objectives should be based upon a
    shared understanding of the market ecosystem.

  \item Review the array of potential benefits that being open source
    can bring, as described in \fullref{goals} (p. \pageref{goals}).
    Which ones, if any, resonate with your project's purpose and needs?
    Note that no project should seek (or be expected to obtain) all of
    the possible benefits.  The point of the review is to stimulate thought
    about which benefits are most important for this particular
    project --- and for which you should therefore optimize.

  \item Based on an understanding of project's purpose and the particular
    open source benefits you want to generate, find the archetype that
    seems like the best fit (see \fullref{archetypes}).

  \item Use your chosen archetype to help drive a discussion within the project
    team and, as merited, with key external stakeholders.  Review the
    questions in \fullref{practical-questions}
    (p. \pageref{practical-questions}) to help determine if the
    archetype seems suitable, or if not, why not.  The answers generated
    through this discussion will help the team make informed decisions
    about the open source project's licensing, governance and
    co-development models, and general management.

\end{enumerate}

The set of archetypes in section \fullref{archetypes} is deliberately
coarse-grained and simplified.  It is not important that a given
project exactly match every aspect of a particular archetype; some
projects may even incorporate elements from different
archetypes\footnote{For example, Open Stack is listed as an example
  for both the ``Wide Open'' and ``Multi-Vendor Infrastructure''
  archetypes because it exhibits characteristics of both: significant
  project-wide investment in welcoming individual contributors and
  giving them influence, but still with the majority of overall
  development activity funded by organizations that have a sustained
  business interest in the project's success.}, though in general we
expect most projects will fit best with one archetype.  Once that
archetype is identified, governance, licensing, process, and
infrastructure decisions can be made in light of it, with some
adjustments for the project's specific circumstances.

Once you are familiar with the archetypes, the questions in
\fullref{practical-questions} may be useful to consider, along with
the analysis exercises in \fullref{goals} (p. \pageref{goals}) and
\fullref{ecosystem-mapping} (p. \pageref{ecosystem-mapping}).