The problem with long-term production support of things

February 13, 2012

In FreeBSD and release engineering, Nathan Willis summarizes one of John Kozubik's suggestions for FreeBSD release engineering:

[...] Second, the project should focus on just one production release at a time, and commit to a definite support schedule (Kozubik suggests five years as a production release, followed by five years as a "legacy" release). [...]

My reaction is that this is completely infeasible in any open source project that developers will actually want to work on. As I mentioned, this will be a Rorschach test for what you consider supporting a production release to mean; I'm basing my opinion on my views.

To understand the problem, let's start with the implication of only having a production release. The problem here is that developers want to fix things, and they can only be pacified so long by developing new features. Sooner or later they want to improve or reform or clean up something that already exists, and then the release manager has to stand in the way saying 'no'.

Well, no problem; you'll branch off a development version from the production release. Except now you have two problems. First, you've got to provide new hardware support for the production release, but the development release is going to increasingly diverge from it; over time you tend towards having to develop two different drivers for new hardware, one for the old environment of the production release and one for CURRENT, the development version.

Second, developers generally don't want to wait years before their code is released (sometimes this is phrased differently, from a more technical angle). It's not very motivational to work on something knowing that the next production release is three years away and most people won't see your effort until then. Developers are going to want more frequent releases, perhaps much more frequent. If you don't provide them actual releases, I think you are going to wind up with the old Debian unstable situation all over again (if you don't lose developers).

(Also, note what this does to people who want to pay to have features developed. Those people are not very interested in waiting years before the features appear in the next production release, but they are probably also not very interested in running CURRENT. What you're likely to get is a fragmentation of your production release into multiple releases that are something like 'production, plus some of CURRENT that's proven stable and important, plus important feature X that we needed enough to pay for'. And you run the risk that people will only fund driver development for production and leave you to forward port their drivers to CURRENT.)

If you accelerate your release schedule (say to one production release every two and a half years) but keep the support periods the same, you multiply your effort; now you've got to backport things to multiple production releases, not just one release. Such backporting is drudge work and not very attractive to most developers. You've basically traded one demotivation for developers (slow appearance of code in production) for another (much more backporting work).

(Many developers will probably be okay with that, because as far as they're concerned backporting stuff is somebody else's problem; they only work on CURRENT.)

By the way, much of this is not theoretical. Linux kernel development used to be split into a stable (2.x for even x) and development (2.x for odd x) series of kernels. It didn't work very well, with all sorts of issues and failures, and has been solidly abandoned in favour of a rolling evolution where the Linux kernel hackers have declared that it is someone else's problem to do long term stable releases.

(See also Open source projects and programs versus products.)

Sidebar: the other problem with ten years of support

Unless you take a very narrow view of what an operating system is, a modern OS is made up of far too many components for one team to support. FreeBSD, your favorite Linux distribution, and even Solaris are actually aggregations of software; not just the base kernel, libraries, and utilities, but also the C compiler, environments like Perl and Python, and higher level systems like Apache and Samba and BIND.

The original developers of all of those pieces that you're aggregating together are extremely unlikely to agree to provide ten years of security fixes and major bug fixes for any release of their software. Probably they're not going to agree to even five years. This means that as time goes on, you will be increasingly called on to do all the work of maintaining that software yourself. Just as with backporting fixes to your own components, this is drudge work with all that that implies.

(It's also difficult, because you didn't write the software in the first place.)

Written on 13 February 2012.
« Some things about changing from old X fonts to modern TrueType fonts
A downside of automation »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Feb 13 22:18:10 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.