arch-upstream-dependency.ltx

\hypertarget{archetype:upstream-dependency}{}
\subsection{Upstream Dependency}\label{archetype:upstream-dependency}

{\bf Examples:} \emph{OpenSSL, WebKit, and just about every small
  JavaScript library on GitHub}

{\bf Characteristics:} Intended as a building block for other
software, so the user base is made up of developers, and adoption
means third-party integration of your software into their products.
When small, this archetype often overlaps with
\fullref{archetype:houseplant}.

% James said: I believe these are relatively likely to be forked /
% abandoned, but that may not be relevant here.
% 
% Karl responds: I think it would be relevant, because likelihood of
% forking/abandonment is probably important to Mozilla.  If something
% about this model makes either of those outcomes more likely, that's
% something we should point out.  But, the more I thought about it,
% the more I felt like this is only true for the smaller projects (you
% know, the six-line JavaScript modules on GitHub), not the larger
% ones.  So I couldn't think of anything to say confidently about
% likelihood of forking or abandonment.

For smaller or more specialized libraries, this is a bit like Wide
Open, but the experience for maintainers and contributors is
qualitatively different.  When a significant portion of the user base
is able to participate technically, a lot of attention and investment
may be needed from each serious participant just to take part in
discussions, even when the number of parties in a discussion is small.
Relative to Wide Open, there are fewer one-off or lightweight
contributors and more ongoing, engaged contributors.

The degree of the software's specialization does not necessarily
dictate how much investment it receives.  Upstream Dependency projects
attract technical investment based on two factors: their
replaceability (it's easier to duplicate or find an alternative for a
six-line JavaScript library than it is to do so for, say, all of
OpenSSL), and which downstream projects depend on them.

Therefore understanding who is using the project, and how, is key to
knowing what goals the project can serve for Mozilla.  An Upstream
Dependency project can be quite influential thanks to its role in
downstream dependees, even if only a small minority of developers in
those dependees are familiar with it.

% Comment from an early reviewer: ``... The example of Webkit is one
% that resonates at Mozilla of course: as a result of temporary
% equilibrium of Apple and Google both deploying Webkit, the mobile
% web stopped being standards compliant, and became Webkit compliant,
% giving us a huge headache for web compat as we rolled out mobile
% products.  The ability for projects to be upstream dependencies and
% to command huge network effects as a result is a very important part
% of how we need to consider open source.  I believe that this
% archetype could/should become more important to us (although perhaps
% this may merge with "Wide Open", if the assumption about the
% business objective of "Wide Open" is to maximize adoption
% downstream).''

\begin{itemize}
\item {\bf Licensing}: Typically non-copyleft.
\item {\bf Community standards}: Welcoming, and specifically amenable
  to one-time contributions.
\item {\bf Component coupling}: Standalone, decoupled from one another
  and the downstream projects that pull them in.
\item {\bf Main benefits}: Connections to many downstream dependee
  projects offers insight into market and usage trends, and
  can provide openings to potential partners.
\item {\bf Typical governance}: Informal, maintainer-led,
  committer groups.
\end{itemize}