Who is that code for?

Free software development projects put a lot of thought and energy into what they are trying to create. Some projects also put effort into communicating their goals clearly to the world. Arguably fewer projects ponder the question of who their users are. But a project's vision of who it is developing for deeply influences the code it produces and the way it manages its releases. Some high-profile projects have been the target of extensive criticism storms recently; arguably the real problem in these incidents has been confusion over who the target users are. In particular, when groups find that they are not seen as users by a project that they had thought was keeping their interests in mind, they tend to get upset.

The recent examples are fairly obvious. Consider the firestorm which has resulted from the Firefox 5 release, the quick abandonment of Firefox 4, and the prospect of the same thing happening again in the near future with Firefox 6. For individual desktop users, this release scheme may work just fine, depending on how many extensions break (your editor reports with dread that this update broke Firemacs - and, thus, Emacs keybindings - in the browser). If, instead, you run a corporate network where software must go through an extended approval cycle prior to deployment, losing support for a major release constitutes a big setback. For "enterprises" with this type of policy, Firefox is increasingly unsuitable; it is thus not surprising that a lot of complaints have come from that direction.

The response from Firefox developers has been clear: the Firefox project is not targeting enterprise users. Firefox is successful because it was adopted by individuals, not their employers, and the plan is to continue to target those individuals. This view can be seen in the draft vision statement under consideration by the project now:

Making life easier for corporate information technology managers does not really figure into this plan. One can argue - as many have - that this approach can only serve to cement the role of Internet Explorer in corporate settings, but that is the choice the Firefox developers have made.

The other recent, high-profile misunderstanding with regard to target users is the GNOME project, and the GNOME 3 release in particular. There can be no doubt that some users are upset by the changes brought by GNOME 3 and GNOME Shell, even if there is disagreement over how large that group is. GNOME developer Bastien Nocera recently made it clear that at least some of those people are not in the GNOME project's target audience:

The project has made numerous other decisions which implement that same view of its user community. In this case, many of the affected users felt that, once upon a time, they were somebody that the GNOME project cared about. If GNOME has ever truly targeted users who care about their terminal emulator, it has since seen greener grass elsewhere and left those users behind. Those users have made their feelings known; at this point, the best thing to do is almost certainly to wish GNOME success with the users it is targeting and, if GNOME is no longer a suitable working environment, move on to something else that is.

The community is full of examples of how a view of the users affects the way the code is managed. Consider PostgreSQL; this is a project which does see "enterprise" users as interesting. PostgreSQL developers also assume that their users care a lot about their data. The results include a highly conservative, review-intensive patch merging policy and a five-year support policy. PostgreSQL 8.2, released in late 2006, will continue to be supported through the end of this year. The wait for new features may be longer than one might like, but rapid feature development is usually not at the top of the "must have" list for users of database management systems.

For a completely different view, see OpenBSD, which only grudgingly admits the existence of a user base outside of its development community at all. OpenBSD leader Theo de Raadt put it clearly a while back:

This position evidently works for this particular project, though it does lead to occasional misunderstandings when users forget their place.

Other examples abound. Git and Mercurial are similar tools with different views of their users - a difference especially felt, it seems, by Windows users. Fedora and Red Hat Enterprise Linux share a common ancestor and a lot of code, but they are developed for different people. Prior to the early 2.6.x days, the kernel community (mostly) saw itself developing directly for end users; the even/odd development process was a direct result of that perception. Current kernels are developed (mainly) for distributors, with an associated focus on frequent stable releases and rapid merging of features. Pulseaudio targets different users than JACK. And so on.

It is a rare project that can be all things to all people; projects which try often do not succeed. A clear idea of who the users are can do a lot to focus a project's activity, attract like-minded developers, and increase adoption. So projects need a good idea of who they are developing for; they also need to communicate that vision clearly. If a project does not prioritize the needs of specific users, it is best if those users understand that before they invest a lot of time into the software. Users, in turn, should pay attention: just as we would not expect a video editor to do source code highlighting, we should not fault a project which is clearly targeting a specific group of users for not meeting the needs of others. We are a large and rich community; if one project does not meet a specific set of needs, there are probably several others with a different and more suitable focus.

---

to post comments