Open-source as health check

An idea that Stephen and I have been bouncing around. Using an open-source methodology for internal software projects as a useful gauge on whether or not your software project can be considered "healthy".

Even if there's no business interest in actually "open-sourcing" a codebase, adopting an open-source model can be worth considering: a healthy open-source project improves transparency, accountability, and the maintainability of a codebase. Outside of the codebase, it can also improved code goverance on your team and developer motivation and moral.

So how is a healthy open-source project achieved?Certainly not without it's own share of process.

"If everyone owns it, no one owns it"

The first fallacy to dispel is that open-source means that everyone is an owner. A successful open-source model requires at the very least a core maintainer.

A software maintainer is responsible for read/write/admin permissions, reviewing and merging pull requests, responding to discussions and issues, providing direction and clarity on scope.

Developers contributing to the project via "pull requests" provide new functionality, bugfixes, increase version support, increase test-coverage, improve the usefulness of abstractions and implementations -- the list goes on -- but the work items themselves should correlate somewhat to defined needs articulated by the maintainer.

Active developers are promoted into the fold, and become core contributors, able to commit directly to the project. The majority of the development work is committed by core contributors who have earned the trust of the maintainer, based on their pull requests.

If a developer puts effort into submitting a pull request and it is not reviewed and acted on in a timely manner (either with approval or feedback), they are likely not going to submit again.

Developers who don't feel agency to move software forward, will quickly repurpose their efforts elsewhere. This can result in forked codebases, which over time can continue to diverge, becoming quite different from the original upstream, perhaps languishing or perhaps even superceding the original.

Without an experienced and active maintainer, projects suffer. A diffusion of ownership will happen in the development team, in which developers become adverse to taking on responsibility to the devolving codebase.

The lack of clearly defined ownership in the open-source model (which promotes agency and quality in the "maintained" scenario), in this case enables a classic case of "tragedy of the commons".

Developers working with their own self-interest will commit single-purpose features, rather than useful abstractions. Hacks will arise, as will duplication. Discussion will not be captured, and commits will be in fits and starts.

A healthy open-source project is in constant flux. Conversations are captured as issues and resolve as bugs, improvements and new features. Versions are bumped at a regular cadence, and the Semantic Versioning convention is respected to avoid introducing breaking changes in patch and minor releases. A

If it's open-source yet there's no maintainer, your team is likely doing it wrong. If everyone has write access, it's likely being done wrong. If it takes weeks to get feedback on a pull request, it's time to invest a cycle and get it back on track.