The CVS cop-out and the stranded user

One of my biggest pet peeves with open source software is what I call the CVS cop-out. It works like this: I criticize (accurately) some shortcoming of an open source application either in an article or in conversation, and someone responds with, “That’s not true! That feature was fixed in CVS four weeks ago!”

Or words to that effect. As if that makes the bug that I want to talk about a non-issue. As if it is inaccurate to discuss a bug in the shipping version of an app just because there’s a fix in beta, alpha, CVS, or patched on the developer’s mailing list. It is a developer-centric perspective, unhelpful to the user.

You really have to have blinders on to think that a patch in the revision control system marks the end of the issue. The majority of Linux and open source users get their software in pre-compiled binaries, and not from CVS, SVN, or any of the alternatives.

Furthermore, although I’m not sure how you could accurately measure this, I am willing to bet that the majority of Linux users consistently run the version of each app that is supplied by their distro. Even in a rapid-release-cycle distro, in many cases the distro’s version is one or more point-releases behind the latest revision of the app (due to the testing and integration required). To the mass market, “four weeks ago in CVS” might as well be a year in the future.

For example …

Obviously this is more of a problem for apps that (a) have a small team of developers, and (b) are integrated into a lot of other projects. Mozilla Firefox, for example, is so self-contained and so well-funded that it almost never suffers this dilemma.

At the complete other end of the spectrum is a kind of app that we all love to hate, the audio player. The task of the audio player is so complex that almost all of them rely on a mountain of I/O and processing libraries to support the dozens of sound formats, metadata, synchronization and modification, effects, and management that we all expect.

But that level of complexity just about guarantees that when a bug hits Rhythmbox and robs it of its ability to play *.m4b files (to make up an example), the mass market won’t see *.m4b playback in Rhythmbox again for six or more months.

Unfortunately, there appear to be no easy solution to this particular problem. To take the Rhythmbox example, Rhythmbox is directly dependent on more than 50 other packages — and GStreamer, from which it draws most of its media support, is just as complex. No CVS patch upstream can filter down through the vetting process fast enough to please the stranded *.m4b fan.

But certainly it is better to publicly maintain a downloadable, alpha-and-beta-testable “development” branch than it is to leave users out in the cold. Between the two alternatives, giving the mass market access to unstable code with recent fixes is surely preferable to the CVS cop-out.

What justification is there for ignoring the long-standing tradition of “release early, release often?” Too many bug reports? Users are the lifeblood of an open source project, and bug reports are the white blood cells. Even when there are dupes, they’re a good thing.

I bring up the CVS cop-out not because I have an answer for it, but to air it out. Sometimes, giving a problem a name helps to foster discussion that leads to resolution. You may think it is a stupid name — and feel free to — but the social problem won’t go away.