On Mon, 2004-11-08 at 14:15 +0000, Martin Michlmayr wrote: > * Thomas Schorpp <t.schorpp@gmx.de> [2004-11-05 19:05]: > > What I could do for (with) You is to start with QA Process Assessments > > to determine capability leaks. Such data and scores could be used then > > to optimize the debian-qa processes in steps of years. > > Free software works by people simply doing things and contributing > them to the community. If other people are interested, it will be > picked up. While I agree with Martin that this is the status quo in many cases, I think it's worth pointing out that this is actually not a property of free software or an open source development model. Is it the least-effort solution? Yes. Is it common in the free software community? Yes. But is it the only solution that has been employed to produce free software? No. And this is often the source of major confusion. Some time ago, it was suggested by a large company that, for example, the production of the Linux kernel was totally unstructured. I hear people explain open source development models in words such as "there is no structure" or "it's completely ad-hoc". Nothing could be further from the truth, and in the Linux case, OSDL took it upon themselves to show why. Sure, there are many projects that start off by someone creating a Sourceforge account and committing some code to CVS. Perhaps there is even a release or two, and perhaps someone sends a patch. However, most such projects die. "They lack critical mass" is the usual explanation in open source lingo. I would say that the person who created the project didn't know what they were doing. I think Thomas' point -- as I have understood it -- can be generalized to cover something that I've been observing ever since discovering the on-line community and later the free software community. There is a lot of technical skill to implement things, and there is some skill in writing good documentation, but there is not very much skill to do anything else, such as knowing how to do your project so it doesn't die and you will have wasted your efforts. Let's pick a few pieces of software semi-randomly and look at them more closely: the Linux kernel, the Evolution email client, and the GNU coreutils -- you can add your favourite free software program, there will be some exceptions, but the following is true for most. They are all relatively well written pieces of software -- they work, they have large user bases... and they were all implemented based on a design that was already available, and they were not much more than a copy from the start. They have certainly grown to become more than the design they built upon, but it was still relatively easy to jump in and start writing code. Just get a POSIX book and you'll know what to implement in a UNIX-like operating system. Or get a copy of MS Outlook and take some screenshots, and you have a prototype for an email/calendar app. You can start tinkering right away. It is much, much harder to start out with a blank sheet of paper and a vague idea. But why is it harder? Or perhaps we should ask "why is it harder in the free software community?" And the answer is that once you have drawn the first sketchy lines on your paper, and you'd like to get some feedback, there is really no one competent enough in the free software community to make any kind of constructive comment about it. There are only programmers who instantly see what is already obvious: that piece of paper is not detailed enough to implement an application with. They want the POSIX book. This goes for self-criticism as well, and most people would never even dare to present their sheet of sketches to the community. In a way, it's ironic that most free software developers see themselves as very creative when they write code, and yet they fail to see that the same creativity would be required much, much earlier, in a stage of program development when it is impossible to write any code at all -- because you just have the sheet of paper to work with. In a way, things have been turned upside down: the creative process is killed at birth because it is not known how to handle it. This is the culture that Debian is part of. It is largely a copycat culture -- and one that is very good at just that, with few exceptions. I believe I'm not alone when it comes to the desire to develop this culture to go from copycat to inventive. In fact, when reading most discussions and outright flamewars on Debian mailing lists and those of other free software projects, it constantly strikes me that the source of many of these arguments is the lack of knowledge. The lack of knowledge is in both the people who propose new ideas, and in the ones that tear them apart by saying they aren't well defined. In other words, the lack of knowledge is part of this culture. I might even say that it goes deeper than simple lack of knowledge -- it is lack of perception, the inability to receive the input that the knowledge could work with, were the latter not missing. You can observe this on mailing lists as well. Quoting out of context, people tend to attack the details of each other's messages, instead of doing what is required for the discussion to reach new insight: reading, understanding, evaluating, and commenting on the whole, and trying to interpret it and present your own understanding for further feedback. Asking instead of telling. Is there anybody out there that would like to improve on these things? To develop the perception and the knowledge of this culture, so that we could expand our abilities from the art of programming to cover also the arts of process design, interaction and user interface design, and human communications. Rhetoric question. > I suggest you do a QA process assessments of Debian and > write up your findings in a way Debian people will be able to > understand. Based on this document, we can discuss further steps. In light of the above discussion, I would say that I understand Thomas' reply very well when he says that "I can do it only with participation of Your team, never alone". As I've said to Thomas in previous emails, it may not be possible to write such a document right now. "Debian people" will not understand it, unless you write it on a level that is not useful for anyone. Instead, new insight is required for the "Debian people". In a way, this completes the circle. In order for anything to happen on this front, some individuals must become interested enough to start widening their perception on their own, and then coming back to teach the rest of the Debian community what they have learned. If this doesn't happen, people have just been scratching their own itch, and we will have gone nowhere. If it does happen, the Debian community sure has some very valuable participants, who in turn value the community even more. -- Fabian Fagerholm <fabbe@paniq.net>
Attachment:
signature.asc
Description: This is a digitally signed message part