mailing lists, the Quality Teams Project would seem like a potentially
worthwhile venture in the Open Source tradition. In fact, the project should
be seen as a new approach to problem normally solved with social contracts.
Debian's social contract,
for example, describes in one document the principles and aims that frame the
ways in which individuals participate in the community. The Quality Teams
Project lacks a formal document of the same kind, but in seeking to refine
the modes of participation in a project as large as KDE through more
practical means, it has the same effect, and it is in this new approach that
the Quality Teams Project finds radical new ground.
People participate in free software projects for reasons that fall into four broad categories: productive, social, political, and spiritual. The Quality Teams Project enhances each of these areas for participants.
To begin with the productive aspect, more people participating in the development of code tends to lead to better code, and the more good people you have contributing, the better the project is. The Quality Team Project provides an easier way to become involved in the KDE Project, including developing KDE's codebase. Through working in a Quality Team, an individual can get to know a particular application and its developers well, and learn key skills such as using a concurrent versioning system, using KDE's Bugzilla, preparing and applying patches, and more. Rather than having to jump straight into writing C++ code, participants can move into a coding position in easy steps, and no doubt have a much greater chance of contributing well-written, appropriate, and worthwhile code eventually. The most immediate and obvious advantage of the Quality Teams Project is that by making the barriers lower, it will mean more programmers working on KDE.
Prior to the launch of the Quality Teams Project, you could contribute to KDE through coding, creating artwork, writing documentation, and giving money. The only way to make your voice heard on KDE's development, however, was to subscribe to heavy-use mailing lists or to use the Bugzilla.
Now, in addition to the traditional ways to contribute, people can provide support to users, promote KDE through press work and journalism, and perform user interface work, testing, and looking after individual applications. Quality Team members will act as a kind of gateway between developers and the public. The Quality Team will insulate developers from deluges of simple and often repetitive requests, while bringing better-quality user feedback to the KDE Project. This should lead to not only better KDE applications, but ones more representative of the needs and abilities of all KDE users.
The second aspect of participation in free software projects is social -- of obvious importance in any community. Free software most clearly distinguishes itself from proprietary software in its approach to community.
Today society clearly divides work and leisure, distinguishing between time spent socialising and time spent working. This is perhaps seen most strongly in the cubicles and hierarchical "vertical" management structures of large proprietary software companies.
In the free software world, by contrast, work and play, coding and talking, can all take place at any time, sustaining and complementing one another. Anyone who frequents developers' haunts on the Internet is familiar with the very social nature of projects. Anent KDE specifically, some of the highest figures in the project talk with first-time posters on mailing lists.
While the KDE project is already a very social organization, the new Quality Teams will facilitate and direct discussions in a way that is more conducive things being achieved based on those discussions. For example, rather than idly pondering the user interface of an application on the developers' mailing list, and occasionally reading users' thoughts on sites like the dot, developers and the public will be able to feed thoughts into the Quality Team, which will direct the discussion and ensure that the outcome is a series of recommendations or a conclusive end.
The orthogonal nature of the framework makes the impact of this clearer. This flowchart illustrates that Quality Teams will discuss issues with users and developers, and will relay these discussions with each group on to the other. In doing so they will not only organise developers and users into more meaningful and useful discussions, but they will also teach users how to do so, and avoid splitting the project into two channels of discussion, developers and users, with little interaction.
Another facet of the social benefits of the Quality Team Project is the democratisation of the social side of the KDE Project. As I have already hinted, not everyone can participate in discussions about KDE, nor in discussions that KDE developers have on other subjects. (Discussions aren't forcibly limited to work.) But by setting up Quality Teams, KDE is opening the door for more people to take part in discussions without needing in-depth knowledge of coding. Quality Teams will take users' vague ideas, analyse them, and submit coherent suggestions backed by hard data, all while communicating to the community what is happening.
the argument by default. This approach, common among free software projects, works well in general, but runs into problems when the question is not so much about making something work, but deciding how something should work.
Nowhere is this felt more keenly than in the current KDE Usability Project, which for the moment revolves around a very noisy mailing list. With usability issues, the best implementation isn't simply a matter of a working one, so although many people submit designs and suggestions, from graphical mock-ups to working UI files, it can be difficult to decide what works best. The mantra of "who codes wins" still seems to hold, since it is generally the word of the developers that is final, but the process breeds tension between the participants.
Quality Teams will mediate discussion between developers and the public. They won't represent any kind of authority, but they will help to focus discussions and make them more accessible to newcomers. There is a lot of potential for people to feel ignored when they rely on developers to follow all discussions about their applications, and so the principle of openness is prone to becoming undermined by time constraints.
On a more theoretical level, Quality Teams will empower users. According to Stephen Lukes (in Power: A Radical View, 1974), we can exercise three kinds of power in any political system: the power to directly implement change, the power to affect the agenda, and the power to affect the frameworks by which the agenda is decided and implemented. At present, and in any vaguely anarchistic meritocracy such as free software development, developers exercise the first level of power, and the second and third levels are acquired on an ad hoc basis by the most respected developers. This may work well if code in itself is all that matters, but the Quality Team Project opens the new possibility that everyone else can matter. By giving users a gateway to developers, Quality Teams provide the first two levels of power to some extent to all users who wish to take them, rather like a political representative (e.g. MP or congressman), and do so without denying the role of merit in the decisionmaking process.
The Quality Teams Project has the potential to introduce a formal democratic element that to date has existed informally, insofar as developers take time out from coding to read community forums. Of course by discussing an idea you have no guarantee that a developer will implement it, and quite rightly so since it requires someone devote some free time and energy, but Quality Teams will at least formalise the process and improve the chances of vague ideas turning into code.
The spiritual aspect of free software communities and participants is often overlooked or ignored. The fact that if hackers didn't enjoy coding, they wouldn't do it, suggests that there is a very basic personal dimension to free software that enriches a person. The use of the term 'spiritual' may seem at odds with many hackers' scientific atheistic outlook, but it simply describes those aspects of oneself that cannot be summed up in productive, social, or political terms.
So why are Quality Teams spiritually interesting? Because they open up the potential for spiritual fulfilment in a new group of people. Working on a Free Software project can feel frustrating, tiring, and even at times like hard work, but it is all the same an enriching experience, exposing you to new practices and people and making you learn and develop aspects of your personality and skill base.
If you're somebody who has used KDE and who has always wanted to contribute to the project rather than just participate in social discussions, then consider joining the Quality Teams program. Whether you want to become a developer, facilitate discussions between developers and the public, write documentation, develop a career in the media or as a journalist, or simply do odd jobs as they are required, there is now something for you in the KDE Project.
Copyright 2004 Tom Chance