ecosystem-mapping.ltx

\hypertarget{ecosystem-mapping}{}
\unnumberedsection{Ecosystem Mapping}\label{ecosystem-mapping}

\otsfirstterm{Ecosystem mapping} is a technique for building a shared
understanding of how an open source project's stakeholders affect the
project.

The best way to make an ecosystem map is to hand-draw it on a large
piece of paper or on a whiteboard, as a group exercise.  An ecosystem
map should be lightweight, messy, and quick, and ideally redone
regularly because a healthy ecosystem is never static.  We recommend
starting with \emph{who} and going from there to \emph{what},
examining at least these elements:

\begin{itemize}
  \item \textbf{Users} \textit{(a.k.a. ``end users'')}
  \item \textbf{Contributors}
  \item \textbf{Service Providers} \& \textbf{Support Providers}
  \item \textbf{Partner Organizations} \textit{(e.g., co-investors or funders)}
  \item \textbf{Instances} \textit{(i.e., production deployments)}
  \item \textbf{Competing or Adjacent Projects} \textit{(open source and proprietary)}
\end{itemize}


Figure~\ref{fig:example-ecosystem-map} shows a simplified real-life
example.  It is based on an actual map drawn for the Arches Project
(\otsurl{archesproject.org})\footnote{Some background will help:
  Arches is an open source platform for managing cultural heritage
  data, started by two sponsors, the Getty Conservation Institute and
  the World Monuments Fund.  It quickly grew to involve a number of
  different participants.  Some of them are cultural heritage
  organizations (e.g., Historic England) that both contribute to
  Arches development and deploy instances of Arches themselves.
  Others are commercial service providers who deploy Arches on behalf
  of customers.  Still others represent deployments (and thus
  indirectly those deployments' users) by influencing the project
  through feedback in the project's forums and participation in user
  workshops, conferences, etc, more than through direct code
  contribution.  Full disclosure: the Getty Conservation Institute is
  an OTS client, and we have advised the Arches project since its
  inception.}.  The version shown here is deliberately reduced to just
a few entities so it will fit on a page; the real map is much larger
and more complex.

% See ../../../examples/example-ecosystem-map-README.txt for how to
% update this ecosystem map.
\begin{figure}[htb]
\begin{center}
\includegraphics[scale=0.7]{images/example-ecosystem-map.png}
\caption{\em Example ecosystem map: a simplified and abridged
  representation of the Arches Project ecosystem.}
\title{fish}
\label{fig:example-ecosystem-map}
\end{center}
\end{figure}

Depending on the needs of your project and its archetype, you can
tweak how you draw the map:

\begin{itemize}

  \item You can use shapes of varying sizes to differentiate between
    larger and smaller organizations (which could mean larger or
    smaller in absolute terms, or in terms of the entity's degree of
    involvement in the project).

  \item The key categorizations (``Contributor'',
  ``Instance/Deployment'', etc) may be different for your project.
  The ones offered here are just suggestions, though they are ones we
  have found work decently well across many projects.

  \item You might draw lines of communication or cooperation between
  different nodes, and those lines could use different styles or
  colors to represent different types of connections.

  Seeing the relationships and dependencies between different entities
  in the ecosystem can be just as important as categorizing the
  entities.  When depicting major vendors and significant clients, for
  example, you could draw lines to indicate who is servicing which
  vendors in which markets and niches.  (We didn't include such lines
  here only because it would have cluttered up the example diagram too
  much.)

  \item This example map happens to show geographic regions, because
  they were important for that particular project, but not all
  ecosystem maps need do so.  Other groupings might be more useful for
  other purposes --- for example grouping by application domain, or
  linguistically rather than geographically.
\end{itemize}

\subsection{How to Use an Ecosystem Map}\label{using-an-ecosystem-map}

Sketch the diagram as a whole first, being as inclusive as possible,
and then step back and look for patterns.  As with drawing the map in
the first place, this interpretation step is best done as a group
exercise.

For example, if you notice that entities of a particular type -- say,
small companies, or entities located in a particular geographic region
-- offer service and support but are \emph{not} contributors, that
raises the question of whether the project could do more to help them
participate.  If there are many such entities and they share a
linguistic background, that could signal that the project should
consider investing in translating its documentation into that
language, or even hiring developers who know that
language.\footnote{It might also be a good idea to look to see if
  those entities have already created their own language-specific
  forum in which they discuss the open source project --- in other
  words, your open source project may have grown without your knowing
  it yet.  In such cases, the value of investing in some bilingual
  developers or translators to help bring the two groups closer
  together is greater.  OTS's report ``OpenDRI and GeoNode: A Case
  Study On Institutional Investments In Open Source''
  (\otsurl{https://opendri.org/wp-content/uploads/2017/03/OpenDRI-and-GeoNode-a-Case-Study-on-Institutional-Investments-in-Open-Source.pdf})
  talks more about the importance of inter-lingual connection in open
  source (p. 37).}

An ecosystem map is usually tuned to a specific purpose.  For example,
the map in Figure~\ref{fig:example-ecosystem-map} was drawn mainly to
help understand \emph{who} the participants in that ecosystem are and
what their motivations are.  By contrast, the map shown in
Figure~\ref{fig:tor-ecosystem-map} (p. \pageref{fig:tor-ecosystem-map})
was drawn more to clarify the flow
of information within the Tor project.  It does not list external
collaborators or deployments individually, nor does it show geographical
regions.  Its value lies in giving collaborators an overview of all
the interest groups around the Tor project and how they relate to one
another, by showing which ones are ``nearer'' and ``farther'' from
each other in terms of communications and concerns.  It's a
quick way to help answer the question ``Have we thought of
every type of participant who might care about what we're proposing?''

It is not unusual to make several different maps of the same ecosystem
in an afternoon, each map emphasizing a different view.  Don't try to
cram everything onto one map: the result will be too confusing to look
at.  Just make several maps.  In a fast-moving project, the terrain
will shift often; ecosystem maps should be made quickly and used
immediately.

\subsection{Ecosystem Maps and Archetypes}\label{ecosystem-maps-and-archetypes}

Ecosystem maps help a project fully realize all the benefits available
from its archetype(s), mainly by making ambient knowledge explicit and
thus usable.

For example, in a Multi-Vendor Infrastructure project, there might be
a set of organizations known to be using the software (known by their
activity in the project's discussion forums) but who are not
well-represented among the project's contributors.  An ecosystem map
can reveal patterns about those organizations.  They may have things
in common --- geographically, linguistically, or technically --- that
the project can take advantage of to become more inclusive.

On the other hand, in a Trusted Vendor or Upstream Dependency project,
an ecosystem map might reveal cluster of users that can be solicited
for input about the project's feature roadmap.  Depending on the size
and nature of the project, some of those users may be small vendors
selling commercial support for the software.  You might vaguely know
of one or two such vendors, someone else on your team might know of
another, and so on.  When you get together and draw a single ecosystem
map, that knowledge gets combined and made actionable.  Suddenly you
see all the vendors, or most of them anyway, and have the ability to
make a coordinated plan for working with them.

Ecosystem maps are especially useful during archetype transitions (see
section \fullref{transitions}, p. \pageref{transitions}), planned or
otherwise.  In fact, the exercise of drawing an ecosystem map is
sometimes what first makes your team aware that the project's
archetype is changing.  If you've been trying to run a Wide Open
project, say, but your ecosystem map makes it clear that your
organization (or perhaps some other organization) wields decisive
influence and is structurally positioned to continue to do so, you may
decide that Controlled Ecosystem is a better fit for the reality of
the project --- and being able to acknowledge that openly as soon as
possible is usually a good thing for all participants.

\begin{figure}[htb]
\begin{center}
\includegraphics[scale=0.3]{images/tor-ecosystem-map.jpg}
\caption{\em Sample ecosystem map for the Tor project.}
\label{fig:tor-ecosystem-map}
\end{center}
\end{figure}

\newpage