A concept for the Quality Team

OK, I'm at aKademy, and am enjoying it a lot. I particular enjoyed the talk by Tom Chance on KDE Quality Teams, and Matthais Ettrich's talk on Qt API design. It would be good to see the rest of Matthais' talk - perhaps it could be re-run during the coding marathon.

Tom's talk, and some of Eirik's keynote tied into an article I read on the flight from Tokyo to Frankfurt, catching up some magazines I had gotten behind on because of work. The article was by Brian Fitzgerald "A Critical Look at Open Source", in the July 2004 issue of IEEE Computer (pp 92-94). He had a lot of good points, but the main things I thought were that talented programmers are the "scarce resource" of F/OSS, so successful projects are really determined by their ability to attract the "code gods" - the most talented and most highly motivated programmers. I really liked the term "code gods", and I'm going to keep using it in this blog entry, to excess.

Lots of projects fail, or are essentially in limbo, because they don't have enough talented and motivated coders. In some ways, I see software as not being a product at a given time, but an evolutionary process. If that process stops, the product dies.

Big projects, like KDE, need more than just a few of the "code gods". In the same way that each professional cycling team has a star (or two) supported by the "domestiques" (sp?), we need to ensure that there are enough people to do low level bug fixes, writing and updating documentation for both applications and libraries, producing icons and graphics and doing translations. I think we need to develop a formal program to produce those "domestiques". Obviously more "code gods" (or documentation gods, or theme gods) would be fantastic as well, but it is difficult to see whether some structured program could really help - maybe targeted recruitment would be worth a try.

There doesn't seem to be a shortage of people who have some interest in helping out with KDE. However a raw volunteer is, fundamentally, a net negative to the project. They simply can't produce the output required, and they are a distraction to the productive members of the project.

I think that the KDE Quality Team goal should be to be a producer / trainer of KDE developers - not at the "code god" level, but to at least the "minimally productive" level. The type of program I see is that the Quality Team put together some kind of training program using on-line resources (or paper-only books, if required) that a prospective developer works through. This would not be a simple list of tasks, but exercises that they receive feedback on, and can get assistance with. As the developer gains proficiency, it should be possible to get them working on real projects (or JJ: type bugs). Depending on the skills and ambition of the developer, we might be able to provide some kind of mentoring program.

Even if people aren't all that good at programming, there is still a lot of value that they can add. Assigning a team member to each application (and probably only to one application) would help enormously. The application "owner" (or "caretaker") would triage all the bug reports and wishes for that application, ensure that the documentation got updated when required, and write the "WhatsThis" entries.

We obviously need the training materials, and we need people to "administer" the training. How do we motivate developers to provide detailed tutorials? Can the Quality Team administer (including providing assistance) those tutorials as a training program? There a number of lesser issues too - how do we keep the tutorials current, and what should they be current against (eg HEAD, the stable branch, etc). Now some of the tutorials obviously exist, but I'm keenly aware of how hard it is to write a good tutorial (and since I'm a newbie, I'm a lot closer to the starting level than most KDE developers). Maybe some of the video and audio from talks given at aKademy could become useful source material.

Perhaps one approach would be to try to run the "developer training" through some kind of formal training institution - maybe a vocational training school. That would probably require payment though, and finding a suitable institution with competent, experienced Qt/KDE developers as instructors probably won't be easy. Also, the institution may want large fees, which is a huge problem for prospective developers without the means to pay.

The converse might be easier - perhaps we can attract students, maybe even providing worthwhile individual or group projects that can be of value to the students (for credit, and "real world" experience) and also of value to the KDE project (partly for the code, but mostly to encourage longer term participation).

We also need to make sure that the KDE project remains open to participation by large number of prospective developers. Applications need to be architected in a way that doesn't require the whole application to be understood in order to add some value. Also, for the really huge "grunt work" tasks, we need to make them readily parallelisable, so that we can have a lot of developers each implementing a small part - an updated metadata system might be a good example, where we will need to support hundreds of file formats, and even the code gods aren't fast enough.

We also need to be careful of how this might be organised. Organisational structures are a problem for F/OSS projects, in that people are often attracted to projects with informal, merit-based recognition. So we need to moderate the structural parts, and I'd probably prefer not to see "Level 1 - complete, Level 2 - not yet competent" style training outcomes. Some kind of recognition, both during training and during the first few months of development experience, is probably a good idea, but I'm finding it difficult to see what form that recognition should take.