No project is more important than its users

Let’s begin by looking at some quotes from ELCE 2011 kernel panel:

Linus Torvalds:

The biggest thing any program can do is not the technical details of the program itself; it’s how useful the program is to users.

So any time any program (like the kernel or any other project), breaks the user experience, to me, that’s the absolute worst failure that a software project can make.

No project is more important than the users of the project.

Alan Cox:

If you want to understand the importance of not suddenly changing your users’ experience.
I would go and take a look at GNOME 3.0.
Irrespective of whether it is a good user interface design or not.
It’s a demonstrattion of why you don’t suddenly change everything on people who rely on what you were doing.

If you look at it from the point of view of the people producing the hardware and technology. Then there’s always a pressure from them to get every new feature and every new thing enabled.

But if you talk to the users of these systems, most of them are primarily concerned that what used to work continues to work and in the same way.

You can see the whole video to get a sense of how important it is for Linux developers not to break user experience. Also, how to don’t break the API while still moving forward, and not increasing code complexity. Or breaking API without users noticing.

This should be common sense, but some people don’t agree and there are various arguments I have heard over the years.

Developers vs. Users

According to some people, it doesn’t matter what the users want, only what developers want, because at the end of the day, it’s the developers that will implement it. This mentality even lead to the term Free Software User Entitlement Syndrome; the idea that somehow users have a say in what happens in the project is dismissed with passion by some people.

This kind of thinking ignores a very basic fact; there’s no such thing as a user/developer divide. We were not branded at the moment of birth; “you shall be a developer”. No, developers were mere users at some point in time. Maybe they were not so good at programming when they started, but they eventually learned all the tricks. Or maybe they already were good programmers, but didn’t want to contribute right away until they saw the software was actually useful, saw an area of opportunity, and had enough time.

Moreover, there are all kinds of developers; the ones that contribute only one patch, the ones that contribute a series of patches they did in one weekend, the ones that contribute sporadically, the ones that contribute often (but are not part of the core team), and the core team. There is no natural division either; it’s a continuum, and people often move back and forth in it as time and motivation permits.

In fact, this continuum of developers follows a power law distribution, also referred to as the long tail. It is hard to see in the following image, but the total area from the right (yellow) is the same as the left (green), that’s why the term long tail is used to point out that one should not dismiss certain people that might be labeled as outsiders, or not part of the “core”:

Here is a graph of all the contributors to the git project ordered by the number of commits, which is plotted on the y axis:

It’s not easy to see, but there’s a long tail there. Here it’s plotted in logarithmic scale, and with a graph of a pareto function:

This means that 70% of the people contributing to git have only provided less than 6 patches, and 37% only one patch. Sure, one patch might not look like a lot, but as Clay Shirky points out; what if it’s a patch for a buffer overflow? what if it’s the difference between a malevolent hacker being able to exploit your system or not? Traditional companies can’t make use of people like Zack Brown who contribute only one patch to the project, but open source organizations can, so lets make use of them.

And lets not forget that this continuum is not static; people often move up (and down) in the ladder. Good projects would exploit this long tail by not dividing groups of developers, and making things easy for newcomers. Junio C Hamano, the maintainer of git, points out:

During the entire history leading to 1.6.6, 710 authors contributed code
and documentation. The changes since 1.6.5 were made by 99 authors, among
which 17 are the new contributors to the project.


And of course, this long tail graph doesn’t even take into account the thousands of users, many which are potential contributors. Plus you have people like Ingo Molnar, who is a very active Linux kernel developer, but has only committed 6 patches to the git project, does that mean he is not a “developer”?

Lets get rid of this idea that there is a division between users and developers; in open source projects, this division just exists in people’s imagination.

Lack of resources

As Linus and other developers pointed out in the video above, you can find ways to provide both the old, and the new behavior. Often this is not difficult at all, but requires some imagination.

Unfortunately, some people disagree and just drop features without any way to use the previous behavior and they rationalize the decision using the “lack of resources” card. Sometimes they don’t even try it, but sometimes it’s true that it’s difficult to implement something while keeping the old behavior. However, something being difficult is not an excuse not to do it; it might take more time, but it’s still doable.

This is the point that is often ignored; they don’t want to spend more time.

But there’s another important point; perhaps the lack of developers is due to the amount of features dropped. Think about it. As I explained, all developers were users at some point, and dropping features means dropping users (current and potential), which inevitably means dropping potential developers. The harder you try to keep you users (through keeping features), the more confidence these users would have that they will be using your project in the future, and the more they will see contributing as an investment.

This is one of the reasons Linux is so popular (as I explained in another post; it’s the most important software project in history) everybody that has been using it for years knows (s)he will still be using it in the years to come, as they are not going to suddenly break everything. It’s a contract between users and developers that builds trust. With this trust it’s easy to gather more and more users, and thus, more and more developers.

This also applies the other way; not only about not dropping features, but adding unpopular ones. It is possible to add features not everybody will use, and still keep them isolated from the main experience–although this requires time, and resources.

Imagine a developer that uses project X, which works pretty well from him, but he wants to add a feature. He might be reluctant to do so because a) there’s no guarantee that they will not drop it in the future, and b) they might reject it right away because they don’t want it in their main experience. Until there is a project like Linux that incorporates all the needs of all the people, this developer would have to either fork project X, or stay in apathy.

So, don’t drop any feature, and incorporate all the features; it’s difficult, but this this is the only sure way of being as successful as Linux, and avoid forks.

Users don’t know what they want

While there is some truth to this claim, it’s a very crude oversimplification of reality. For example, users didn’t know they wanted a touch screen before the iPhone, that is true, but after that, they knew they wanted it, and if you were say Nokia, you couldn’t say “oh, users don’t know what they want” and stay with non-touch interfaces; sometimes they do know. Plus, what they definitely know is what they don’t want; like an application that crashes constantly.

This argument is often used as a rationalization when features are removed and users complain. Some developers bring this argument in a patronized way, implying that they know better. Sometimes they do know better, but this should not be used as an excuse to stop listening the complaints.


So, there you have it, it’s really simple; try really hard not to break your user’s experience, because unlike what some people like to think; it’s the users that make a project successful. The user-base is from where all the contributors come from, and the publicity. If you do break user experience, try to do it in a way that can be reverted if your users complain, or even better, provide both an old and new way of doing things; eventually the new way would be as good as the old, and everybody would move eventually.

Appreciate your users, listen to them, and never threat them as expendable, or even worst; a nuisance. Basic stuff that many big projects forget.


7 thoughts on “No project is more important than its users

  1. Pingback: Chris Oliver » Change Should Be Progressive

  2. Problem is that users want different things, thus there isn’t a singular user experience to be broken. There are always going to be some people who prefers classic (Gnome 2.x style) UIs and think that anything newer than that is “stupid eye-candy”, others who complain about changes just because they’re used to doing things the old ways etc.

    Personally I really like what the Gnome 3 team is trying to achieve. IMHO there has been great progress in the field of user interaction and I think it’s awesome that some people are bringing that to Linux based OS:es. I really doubt that we would ever get to the (constantly moving) next generation desktop experience if we only take tiny steps out of fear of people complaining, and instead only polish what we have.

    I skipped Gnome 3.0 entirely and I definitely agree that 3.2 has a bit to go, but I can live with the devs throwing out the old stuff to make room for the new so to say. I doubt making a gradual transition from Gnome 2 to 3 would have been easy, and might have resulted in an unholy cluttered mess of mixed concepts and ideas. I’m sure they’ll gradually add things that people feel are lacking once they’ve figured out how to make them fit in.

    From just reading the article (can’t watch video now) I can’t figure out what the author want Gnome to be, other than that he seems somewhat unhappy with what they’ve done. But generally speaking I think the anti-gnome-3 crowd get an unproportionate amount of space in Linux media and forums, maybe because people who are happy see little reason to write long blog posts about it 🙂

  3. +Tetsuo Panyagua Your argument resides on an invalid premise; that it’s impossible to change from A to B without breaking A (A = GNOME 2, B = GNOME 3). As I said in the post; it’s always possible to do B, but without through A to the trash; first make B optional, then make B the default, then remove A (but make it easy to restore if needed). That’s what Linux kernel developers do, and GNOME developers didn’t even try.

    That is the problem; breaking user-experience unnecessarily.

  4. Hm, you seem to make the assumption that there is a desire for a particular project to grow. This is not always the case. E.g. I picked up development of the rtmpdump project after it was kicked off sourceforge. I did it for my own personal reasons; I sought a home for it (with the mplayer project) to allow other people to benefit from my bug fixes in the code, simply so the code would not be lost. Aside from that, I don’t care whether other users adopt it or not. I would prefer that RTMP die its well-deserved death and the rtmpdump project disappear into obscurity. User requests are just a nuisance there; when the code does what I need it to do it’s good enough. (Particularly for rtmpdump, feedback from Windows users is almost universally a waste of time. They seem to be, as a class, incapable of reading documentation.)

    This project is only useful today because I’ve invested the time to make it so. The track record shows that no one else with the ability has had the interest. (E.g., looking at the lag time between when users clamor for new protocol support, and when I’m finally bothered enough and bored enough to implement it and commit it to the public repo.)

    The user community is irrelevant; if all of the current rtmpdump users quit using it tomorrow it wouldn’t affect the project one whit. The tool would still do what I wanted it to do, which is all it ever needed to accomplish.

  5. @hyc If your project is so irrelevant that it doesn’t matter if it exists or not, then I don’t see what’s the point of discussing about it. I’m talking about projects that are supposed to be important enough that their long life is desirable.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s