Off the Beat: Bruce Byfield's Blog

When a non-developer criticizes free software, sooner or later a developer will respond with, "I'm looking forward to seeing your code," or something similar. It's a reflex response, but one with increasingly less validity today.

Fifteen years ago, such a response made sense. Non-programmers were a minority in free and open source software (FOSS), so expecting someone to reinforce their criticism with code seemed reasonable. The chances were that the person making the criticism could reply to the challenge. They might not get their code accepted if they had annoyed too many people in the project or lacked connections -- those being the limits of the FOSS meritocracy -- but they could submit code if they chose to write it.

Today, however, projects include documentation writers, marketers, bug-testers, and a whole lot of other people who would be lucky to write a "Hello, World" script without help. Consequently, the invitation to write code is no longer another way of saying, "Put up or shut up." Today, it's a put-down that implies, "You're not a member of the inner circle of developers, so your criticism can be ignored." Once a reasonable expectation, as the FOSS community has grown, it has become an easy way to dismiss outside criticism on no other basis except its source.

Working with users

To some extent, I can't blame developers from falling back on this defense. It's time-honored, and was once a reasonable response.

More to the point, few events are more irritating than expending your best effort, only to have someone wander by and suggest that you should have done something differently. Where, you might reasonably wonder, were these people when you were planning the project and asking for feedback?

Nor does it help that many newcomers to FOSS haven't realized that they're in a different relationship with the writers of their software. Equating project members with a commercial developer, some newcomers seem to believe that verbal aggression is the only way to attract attention. They haven't learned that mail forums and bug reports can be a way to influence development.

And if that isn't enough, often non-developer's requests for features are inarticulate. They know what they would like to see in an application, but they often understand too little to make any concrete suggestions. For these reasons, some developers are fond of claiming, "Users don't know what they want," but that's a half-truth -- it's just that you may need to coax more explanation from them before their demands make sense. Developers who only want to code may well decide that the effort to process outside criticism is simply not their business.

How a sense of entitlement grows

Fifteen years ago, they may have been right. Today, however, dismissing criticism with the usual put-down is increasingly questionable.

For one thing, a dismissal is unlikely to silence anyone. People on the Internet assume they have a right to express their opinions, regardless of how well or poorly informed they are. Telling them otherwise is only likely to make a large proportion of them angry. Hoping to silence them with a put-down is as likely to succeed as commanding the tide to ebb, as King Canute demonstrated to his flattering courtiers.

For another, there is at least one category of people whose job is to criticize. They're called journalists, and their existence is one of the many indications that FOSS has grown beyond anyone's immediate personal connections. Not that journalists should go uncorrected when they say something ignorant or are too unrelentingly negative, but, as Robin "roblimo" at Newsforge used to tell me, you can't expect them to be fan-boys and stay away from controversial topics.

The fact that few developers seem to understand is that many non-developers today have just a strong a sense of ownership of the code as they do. They have, after all, usually made a deliberate choice to move away from Windows or OS X. And, although they may start using FOSS because of the free downloads, many eventually adopt its values as their own.
This sense of ownership is an unforeseen consequence of free software licenses. In making code belong to no one, licenses like the GNU General Public License paradoxically makes users feel that the code does belong to them. They don't have to read long end user license agreements that limit their rights they have in the software. They don't have to authenticate the software to begin using it, or accept a company making changes to their hard drives without informing them. 

Technically, this relationship to the software may not be ownership. It's not even the moral right that people feel they have from contributing to the code. But the point is that it feels remarkably similar to both. And once users feel they own the software, from there it is only a small step to assuming that they have a right to have a voice in its future -- and never mind that they have made no contributions to the code.

Whether this sense of ownership is valid or not is beside the point. Short of changing to a non-copyleft license -- which project developers are unlikely to do for their own reasons -- the feeling is so widespread that today it can only be lived with.

Unfortunately, the sense is new enough that projects are still learning to take it into account. But it explains, I suspect, the user revolts in KDE, GNOME, and Ubuntu.
When the last major changes in these projects happened, FOSS was still very much a community of developers. By the time KDE 4.0 was released five years ago, that had changed -- and, without stopping to think about the matter, thousands of non-developers assumed they had as much right in the code as those who actually developed it. Many of them complained long and bitterly when changes were made without much effort to consult them -- then, when their complaints seemed to be ignored, they retreated to desktop environments like Mate, whose developers actually listened to them.

Few developers may have articulated the situation exactly the way I have. All the same, an awareness that average users need to be listened to is growing. For example, Aaron Seigo tells me that in the last few years KDE has become more cautious about introducing major changes, field testing them in side projects and waiting a few releases for the code to stablize before adding the changes to the core code. Other projects seem to have adapted similar policies, although possibly without articulating them.

In the present situation, such policies only seem sensible. But I would suggest they should opening up discussion -- not shutting it down with what has become a cheap and outdated put-down.

Comments