Taciturn

Distributions spawned from the need for an easy way to install a GNU system. Over the years they've come to be much more — perhaps most recognisably as a tool for simplifying system administration, but I think a much overlooked function of a distro is that it provides a stable branch for thousands of projects that otherwise would not have one. A stable branch that receives backported bug fixes and a period of feature freeze before being considered "released" to end users. This way small projects with only one or two core developers can concentrate on development of any kind and allow the distribution to cherry pick bug fixes for its stable release.

The difficult thing about maintaining a stable branch is knowing what to put in and what to leave out. It is an especially difficult job for a developer-maintainer to do. They are likely to be more keen on getting new code into users' hands. On the other hand, a distribution maintainer has the job of providing a solid piece of software and can more easily make decisions about what changes to pull and what to leave for a future release in the context of that distribution.

When I look at many of the well known projects such as Apache httpd, Linux, KDE, Gnome, GCC, glibc — they all have internally maintained stable branches. I think that attention to solid releases shows in the projects' reputations. In particular, the person in charge of stable releases is often not the person in charge of development releases.

Even with the availability of distributions as a stable branch, I'd like to see more projects maintaining their own stable branches or feature freezes. Make use of that three- or four-digit version number you've got! Having a separate stable maintainer is not necessary, only an advantage. There are always people interested in running the latest code for the latest features (and bugs). When things don't work, they'll let you know, and from that you can determine what to put in a stable release.

Of course I've just made a number of assertions about what good software engineering practice is when my experience in the field could aptly be described as "short". I'll be trying out some ideas in the future with "Stallone". First I have to make a release, though.