Tragedy of the commons in software

Resources that are shared in software seem to inevitably end up disorganized and there is unfortunately no easy solution.

A few instances of this I have seen include:

• Shared libraries
• Shared revision control repositories
• Shared database
• Shared folders
• Shared log files
• Shared settings
• Shared wiki

When different projects are using the same shared resource they often have different needs, goals, rules and cadences. The resources themselves usually don't provide a way to split up the resource cleanly and one project ends up spilling over into another one. Two simple examples would be in a source code repository while one group might name their branches release/minor_release another group might follow build/* and in a shared library one project might declare static objects that eat up ram harming another group that need to have a minimal memory footprint.

The inevitable cleaning up of the shared resource grows to become a monumental and bureaucratic task. Even what seems like a simple task of who maintains/owns something can be a large task and it is not uncommon that it is found to be a former developer that is no longer with the project (and by the way it is no longer used).

Because the resource is shared by many different users it already takes up a decent amount of "stuff" (ram, hd space, bandwidth, etc). An admin team is put in charge of making sure more "stuff" is added when needed and the users inevitably take advantage of this. Users inevitably make optimal choices such as deciding to check in a Visual Studio install ISO’s into the revision control system (deep within the source too). From their perspective they don't feel the pain that everyone else might suddenly be burdened with.

Some projects run very lean and clean. They have very strict rules about how things should work and be stored, but there are many more that don't and as time marches on and new projects are added they end up having cruft all over the place and dependencies across what should have been the project divides. This abuse of the shared resource ends up hurting all of the projects. Rules are put in place and even if there is a good reason they are difficult to change.

What seems inevitable is that slowly projects start using a different new resource and in the process the old shared resource gets less attention and is unlikely to ever recover as more and more becomes unmaintained. Sadly it is often not a big thing, but many small problems that users put up with until one day they realize that abandoning everything will give them a significant boost.

Acknowledge that this is a problem is the first step. Having a steward who is there to not only keep the resource running, but to own it is important. Someone whose job it is to rapidly respond to problems, anticipate new ones before users start to leave, and publicly expose costs. The steward's job includes occasionally striking down long held rules about the resource when they are found to be harmful. They might even be the one that causes all the projects pain by forcing a migration for the good of the group. It is only through these actions that the shared resource can maintain its viability in the long run.