arch-bathwater.ltx

\hypertarget{archetype:bathwater}{}
\subsection{Bathwater}\label{archetype:bathwater}

{\bf Characteristics:} This is code dumped over the wall.  It is
purely about distribution, not about any particular mode of
production.  Think of it as the ground state of open source projects:
someone publishes code under a free license but invests no followup
effort into building open source dynamics.

Typically, the published code is not the organization's prized
technology.  In some cases it is a one-off publication and thus likely
to become quickly outdated.  In other cases, there may be a public
repository, but that repository is not where development occurs ---
instead it is just a container for periodic snapshots of particular
release points.  Sometimes there is not even a public repository, and
the only thing published is a release tarball or a sequence of them.

Code gets dumped this way quite often\footnote{Although numerous,
  Bathwater code bases tend not to be famous, because they don't get
  much usage unless they attract an open source maintenance community
  --- at which point they transform into one of the other archetypes.
  One recognizable example of Bathwater code is
  \otsurl{https://github.com/Conservatory/healthcare.gov-2013-10-01},
  which was essentially a one-time dump of the front end web code for
  the original \otsurl{HealthCare.gov} site developed by the
  U.S. government.  (Although technically in the public domain, that
  code could in principle have been adopted by anyone and the
  resulting fork placed under an open source license.  As is often the
  case with Bathwater code, that uptake did not happen.)}, and
``throwing code over the wall'' has a bad reputation among open source
practitioners.  Merely publishing code under an open source license is
unlikely to generate any of the beneficial effects that come from
truly investing in open source.  When those benefits don't
materialize, developers sometimes take it as evidence that open source
``doesn't work''.

Although experienced open source professionals look down on Bathwater
projects, they do have some uses.  First, they work as an initial
foray into open source.  For inexperienced firms testing the waters,
there are few benefits from open sourcing this way but also few risks.
They can claim to be doing open source, send signals that they are
open to more open source engagement, and perhaps that positions them
to do a more complete job the next time around.

Second, even for firms experienced in open source, Bathwater is a
reasonable final state for an abandoned initiative.  When an
organization is ready to stop devoting any resources to a project,
explicitly putting the code into Bathwater mode, and giving the world
permission to take it up, can be a final attempt to give the project a
chance at impact and serve the existing user base.

Bathwater treats the code like a forkable resource.  Users of
Bathwater projects don't expect anything from upstream, because there
is no upstream anymore, but they can can consider their involvement as
a greenfield opportunity.  If they are willing to invest in the code,
they can choose any one of the other archetypes and start building
toward it.

\begin{itemize}
\item {\bf Licensing}: Varies, sometimes missing, often incoherent.
\item {\bf Community standards}: Community is dormant to non-existent.
\item {\bf Component coupling}: Depends on the project, but in
  practice often standalone spaghetti.
\item {\bf Main benefits}: Doesn't cost anything to run.
\item {\bf Typical governance}: None.
\end{itemize}