|This article brought to you by LWN subscribers|
Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.
Free software is always progressing—at least by someone's definition of "progress". Over the last few years, or more, we have seen huge controversies erupt around changes that were being made to desktop environments, system software, and other parts of the free software stack. The controversies themselves are not that surprising, as people are often resistant to change (and some proposed changes are not necessarily good ones), but the tone and manner of the complaints is sometimes rather eye-opening. It often sounds like some believe that the developers of these projects set out to ruin people's lives with their changes. Somehow that doesn't seem likely, and starting a discussion from that standpoint seems rather unlikely to change anyone's mind.
It is unquestionably frustrating and maddening to upgrade a package or distribution and find that things no longer work they way they once did; that workflows or other habits are now "obsolete". But, presumably, the upgrade was done for a reason, typically to get new features and fixes. With upgrades come dangers, of course. Sometimes those dangers are from new bugs or incompatibilities, but other times the danger is that something that once "worked" no longer does.
This is a problem that is in no way restricted to the free software world. One could easily argue that the problem is far worse for proprietary systems, as upgrades are sometimes forced, which is pretty uncommon for free software. Distributions do reach their end of life, but there are plenty of alternatives to consider when that happens. Somehow, choices like Windows Mint or Mac OS X "Wheezy" don't seem to be in the cards. Nor does installing an alternative desktop environment, display server, init system, kernel, or audio subsystem. For the most part, you get what the proprietary vendors give you and you like it—or not.
It could also be argued that the free software approach (to the extent there is a single "approach") does not lead to desktop dominance. That has, of course, been argued ad nauseam here and elsewhere. But the fact of the matter is that hackers and projects are making their own decisions, freely, based on their interests and understanding of the problems they are solving. No one has set out to annoy anyone. That may be a side effect of the changes that are being made, but it certainly isn't the intent.
If you peer into the development mailing lists or talk to the proponents of these kinds of changes, they clearly see them as improvements. It's a little hard to imagine that folks would spend significant amounts of their time making the code worse. Opinions will differ on the changes, of course, and making one's opinion known is a time-honored tradition in free software (not to mention the internet and human society in general). But the vehement, sometimes demanding, tone that those complaints take is counter-productive. Part of what seems to be lacking is a certain of level of respect for the projects and the people behind them.
A much more effective way to make one's opinion known is through engagement. Unlike the proprietary world, we in the free software world can directly engage with the developers, describe the problems that we see, and try to change the direction of the project in a way that is more suitable for our needs. Most free software projects discuss planned changes well in advance of their implementation and give users lots of opportunities to try out early versions. But engaging the project is best done with well-reasoned, specific descriptions of problems, missing features, and so on—not endless streams of "Project XYZ sucks!" messages to mailing lists or comment threads.
Beyond just offering suggestions and/or complaints, though, we can also pitch in and fix the problems that we see. Given the large number of vocal opponents of various changes (and proposed changes) that we have seen, there should be a ready supply of developers and others to continue maintaining older code bases, or to work on getting features added to fill in gaps. Even when a project moves on from an earlier version (a la GNOME 3 or KDE 4), it's not like the old code disappears. We have seen some efforts (like the Trinity desktop environment for KDE 3 and MATE for GNOME 2) but, despite all the complaints, a big community has not sprung up around either.
Part of the problem is that the intersection between those who are vocally unhappy and those with the time and skills needed to help is probably fairly small. Free software thrives where people participate, but folks tend to want to work on things that scratch their own itch. If there aren't enough participants with the "right" itches, few of the complaints will actually get solved.
Another related problem is that there seems to be an increasing sense of entitlement from some within our communities. The huge base of free software that we use today has been given as, essentially, a gift, from tens of thousands of contributors worldwide. Just like "those who write the code get to choose the license", "those who work on the project get to set its direction". Users are, of course, an important piece of the puzzle, but frothing, name-calling, endless complaining does not rise to the level of a contribution.
It may well be that some or all of the problems that people see in various projects (GNOME 3, KDE 4, Wayland, systemd, the Journal, grub2, ...) are serious and will drive users away from the projects or the distributions that adopt them. But there's really only one way to find out. If users vote with their feet and move elsewhere, one suspects the projects will follow along behind.
None of this is meant to downplay the importance of users making their problems known, but there is a point at which the repetitive, often content-free, complaints don't serve any purpose—other than venting perhaps. These projects have most certainly heard most of the complaints by now, sometimes an enormous number of times. Have they seen constructive attempts to address those problems in even a small fraction of that volume? That, unfortunately, seems unlikely.
In the end, though, people eventually either get used to the changes or find some alternative that suits them better. Sometimes that alternative involves a fork of the existing code and it is not unheard of that the fork eventually rejoins or takes over from the original project. The EGCS/GCC split comes to mind, for example, and we may be seeing something like that play out again with LibreOffice and Apache OpenOffice. It's also worth remembering that GNOME 2 was originally met with a lot of unhappiness, perhaps even from some of the same folks that are now complaining that GNOME 3 "took away" things they were used to in GNOME 2. Over time, these things have a way of working out, but in the meantime, it's worth at least thinking about whether that venom-filled post is really going to be very effective.
Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds