introduction.ltx

\hypertarget{introduction}{}
\unnumberedsection{Introduction}\label{introduction}

Producing open source software is part of the core culture at Mozilla,
and has been since the organization's founding.  It is one of
Mozilla's greatest strengths and is a key element of Mozilla's
identity both internally and in the world at large.

By ``open source'', we mean software released publicly under a license
that is both a free software license according to the
FSF\footnote{\otsurl{https://fsf.org}} and an open source license
according to the
OSI\footnote{\otsurl{https://opensource.org}}\footnote{This definition
  excludes the Creative Commons Attribution (CC-BY) license, the
  Attribution-ShareAlike (CC-BY-SA) license, and the CC-Zero (CC0)
  public domain dedication.  Although they are open source in spirit,
  for various technical reasons they are not good choices for software
  source code.  CC-BY and CC-BY-SA are sometimes appropriate for
  documentation and other non-code assets, as mentioned in section
  \fullref{per-project-questions} (p. \pageref{per-project-questions}), 
  and we consider a project where the
  source code is released under an open source software license and
  the documentation under one of these CC licenses to be an open
  source project overall.  For more discussion of CC0 and how the
  public domain is not automatically like an open source license, see
  \otsurl{https://opensource.org/faq\#cc-zero} and
  \otsurl{https://opensource.org/faq\#public-domain}.}.  But this
definition really only describes a mode of software
\emph{distribution}; it does not imply any particular mode of
\emph{production}.  While open source distribution is built into
Mozilla's identity and underpins the organization's mission, just
saying ``open source'' actually provides little guidance as to how
Mozilla should manage its projects or its relations with partner
organizations, developers, and users in order to gain strategic market
advantages.

The purpose of this report is to make it easier for Mozillians to talk
productively about open source choices, goals, and tradeoffs.  These
discussions may be had internally, with organizational partners, with
contributor communities, and in some cases with users and with media
organizations.  Mozilla needs to be able to decide what type of open
source project a given project should be in order to best further
Mozilla's mission, and the answer may be different for different
projects.

The report provides a set of {\bf open source project archetypes} as a
common starting point for discussions and decision-making: a
conceptual framework that Mozillians can use to talk about the goals
and methods appropriate for a given project.  The framework is not
intended to resolve differences nor to rank archetypes and projects
from worst to best.  Instead, we submit these archetypes as a shared
vocabulary and an already-mapped territory that can help Mozilla
understand a range of open source approaches and the potential
benefits of each one.

The purpose of this report is \emph{not} to provide a single, shared
understanding of open source methodology to be agreed on and adopted
across Mozilla.  There is no need to unify around just one
understanding, and attempting to do so would be harmful, given the
diversity of products and communities Mozilla works with.  Indeed, the
Mozilla Way might be a willingness to explore many approaches to open
source.