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.
[Laughter]
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.

Linus Torvalds schools Lennart Poettering on the importance of users

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.

Source.

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.

Conclusion

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.