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, 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.
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 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 http://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.
Licensing: Varies, sometimes missing, often incoherent.
Community standards: Community is dormant to non-existent.
Component coupling: Depends on the project, but in practice often standalone spaghetti.
Main benefits: Doesn’t cost anything to run.
Typical governance: None.