The Disaster of “Rolling Release”

I’ve always enjoyed exploring. Every time I’ve moved from one residence to another, I’ve always wandered around my new neighborhood, simply to see what was there. It’s the same with computer technology. I love poking around operating systems. Lately, one aspect of this has gotten tiring in every Open Source operating system: Rolling Release. The phrase refers to the sometimes feverish effort to add new features, long before the old ones even work properly. Thus, every day sees sometimes radical changes in various projects, new features and new bloat.

This is the ancient schizophrenia between creativity and usefulness. Not everything in life has to be useful to be necessary. Decoration for no other purpose is fine, and differing tastes are seldom a simple matter of refinement and morality. The original meaning of “character” is the quality of being distinguished from others in the same category, applied primarily to inscribed letters of any given alphabet. Since God knows each of us individually and more intimately than we could know ourselves, we do best to discover what He has made in us, not conforming ourselves to the artificial constraints of someone else’s character. However, individuality does not justify destroying or harming others. So, a gal can pierce all her facial features if she likes, and I’ll support her choice no matter how repulsive I find it. But she can’t expect me to gaze upon her “beauty,” much less want to kiss her. If she also wants to interact with me, she’ll have to make some sacrifices. That’s what civilization is all about: Having a set of cultural expectations which make it possible for humans to live in close proximity without killing each other.

It applies to computer stuff, too. Purity in researching the limits of software on hardware has its place, because no one can predict how crazy ideas might serve a useful purpose later. At the same time, there has to be some useful product, something which meets the drab requirements of folks who use computers only as a tool. We can’t all worship at the shrine of the electronic data gods. Some of us have other things in life we must do to fulfill our perception of our purpose. We don’t do things to serve the computer, but use the computer to serve our needs. For those of us to whom our computer is our number one tool, we still want to get work done. Most of the time, that work is done best when we have pretty much the same tools for an extended period of time. Minor improvements are fine, but constant changes in almost every feature don’t work out well. Too much work time is absorbed in exploring all the new and wondrous changes.

It seems most coders are buried up to their eyebrows in one or two projects. They know this one project really well, and most do a really fine job of designing and adding new features to just the one project. But they are all doing this on just about every project. It’s been long admitted squashing bugs is not glamorous, not half so interesting as creating new code. It requires discipline, sometimes externally imposed, sort of like the necessity of laws to back up the customs of civilization. You can have too much law and too much enforcement, but you can also have too little; the same goes with management and government. The people toiling away on their favored projects don’t seem to notice that’s what is happening on all the projects. A Linux distribution (“distro”) is usually an effort to build a fairly single-source collection of packages which blend together as a whole. The idea is to guide the selection and tweaking of various packages according to some guiding philosophy. Get enough of those packages together, and you could easily have a completely mismatched set of moving targets. It can be quite challenging to coordinate all those packages so they tend to work well together at any given point when a new user installs what you have on hand in your distro repository.

So big is the task, many distros do it poorly, and quite a few seem to make no effort at all. That many individual packages tie themselves to a particular toolkit, or a particular desktop project, can reduce the chaos. Each toolkit/desktop tends to follow some set of rules which make it possible to build just about any package in a fairly broad window within the on-going development of the underlying toolkit. Too often, they don’t bother. The package developer(s) may try to justify that there simply must be this or that feature based on some new addition to the underlying framework. That’s the standard myopia; that it might break every other package attached to the framework is not their concern. Some toolkits/desktops are worse than others in permitting this sort of chaotic nonsense. Equally bad is simply dropping some feature because it’s a hassle to design it into the next major reworking of the project. Users get jerked around, and all too many projects pay no attention at all to that factor; some even cop an attitude about it.

The Linux evangelists are stuck with this big albatross around their necks. There is already a pretty strong division between coders and users, and precious few people who take an interest in mediating between the two. The field is wide open, currently dominated by the business-suit guys and gals because they must have it to make any money selling Linux. The larger community keeps them at arms length, to some degree, because they lack the purity of purpose. We end up with a few highly commercialized Linux distros because these folks simply can’t trust some elements in the wider community to pay much attention to their needs. We end up with an apparent conflict, and in the middle of all this the Linux advocates bemoan one or the other side, and there hasn’t been too many intelligent answers why we can’t get the rest of the world to adopt Linux.

The driving force behind adoption in terms of numbers is business and government. Bill Gates didn’t get to be a millionaire by chasing hobbyists first. He offered something which could be sold as fairly standardized, but in some way better than what somebody else offered. Once it became a must-have for business and government, it could be sold to the general public. The free-wheeling coding community does not appeal much to the suits. Rolling release to them is anathema. Incremental improvement is fine, but bug-fixing and security come first, all within a long release and upgrade cycle. There is a cost to keeping obsolete computer stuff around, but there is also a cost in terms of time and effort to adopt something new. If what’s new offers a competitive edge, it will be adopted. If it makes the artifacts of information incompatible with partners, it will not be adopted until there’s a momentum for all of them to change at once. Poking fun at all the examples of organizations violating sound principles, hiring brainless IT people, etc., does nothing to improve matters.

I like to pretend I’m somewhat of a technology writer, mostly because I’m trying to encourage folks who work and play on computers to learn more. For me, the people come first; they are the reason we bother with computers at all. The path to making the world a better place to live is through helping people. If our work does not help them, we are just pursuing a hobby. If we want more people to enjoy our work, it has to be useful to them. Rolling release reflects the purist hobby mindset. It won’t sell to the wider user base. All the more so when your work offers ill-considered new features, bloat, and never bothers to fix old bugs. Windows XP came out in 2001, buggy as anything MS has produced, and it took some five years before third-party efforts made it worth using, as defined by mass consumer adoption (I’m convinced Win2K is still better). If what we offer is no less buggy, why should consumers bother to switch? Both KDE and GNOME projects continue to outrun usefulness on the consumer level because developers keep introducing new bugs without nearly enough quality control in fixing old ones. If we never bother to offer something really good, even if it’s not all new and shiny, industry and government won’t buy it, and it will never become the standard.

When advocates approach me about trying their favorite Linux distro or other Open Source OS, my first question these days is: Does it adhere to rolling release? If it does, I don’t have time for it any more. We have huge problems getting web standards adopted, or finding work-arounds for proprietary offerings on websites. That’s a symptom of the underlying, damnable idiocy of pushing out the next new release before bothering to fix the old. This lack of stability means there is no standard, de facto or conceptual. It also means we don’t have anything to offer the average consumer, because we have nothing to offer the institutional users. By the time we put it in our hands, it has changed three times before it gets to theirs. Only a small slice of any given population of living humans can adapt to that. Stop whining about the lack of adoption, about the corruption of corporate-grade Linux distros, if you can’t offer anything they recognize as better.