I think what has happened here is that one guy is talking about the fence while the others are talking about the hole in the fence (figuratively speaking). In other words -- "a spec" does not mean the same thing to Linus than it does to others. That is perfectly normal -- actually it is impossible for different people to understand a concept in an absolutely same way. It is so because different words have different associations in different minds and that's a fact.
However, both sides are right! For Linus, it seems, a spec is a general outline of the program that is made before any actual coding is done and Linus obviously knows that people often think spec has to remain unchanged ever since. Linus insists that You cannot write good software if it is based ONLY on such initial theoretical assumptions and models unless the theoretist is a real genius (can foresee all possible problems). Let's assume most people are not geniuses. So, if You have a project and You have initial spec, then desperate clinging to Your initial spec during realisation phase (coding etc) will ultimately take You to a situation where You do not want to be: everything works as it should but it doesn't serve it's intended purpose or even worse -- nothing neither works nor fits together because the creator of the initial spec didn't had a clue what it was all about. So, what Linus says, is that if You think that for building good software all You need is an initial spec, then You are living in a dreamworld.
What Linus left unsaid was, that a good spec always evolves during implementation (coding etc).
I do not believe that any programmer is capable of writing software without an initial spec -- having an understanding of the goal, it's subgoals and the way leading there. It doesn't matter, if this spec is in the form of paper, file or thought, it is always there.
What the opponents of Linus are talking about is knowledge about the inner workings and standards for input and output of the program. It is self-evident that no-one can tell with 100% certainty what will software be like before goals are reached and development has been ceased. In that sence, a spec in essence is linkage of initial theoretical assumptions with the results of implementation. For Open Source Community, the availability of such knowledge is crucial. I will not talk about business collaboration, since successful businessmen have already recognised the value of intellectual capital and the need to accumulate it -- as of that business world is way ahead of OSC.
I think Linus might be worried about his own work and might be reluctant to share the real essence of his work with the public -- to keep the rabbit in the hat, so to speak. I think it's up to Linus, whether he wants to show how his mind works or not -- his contributions are big enough. In general, a person who does not create specs for his or her own work, should not waste time writing Open Source Software. It is a burden for other developers in the OSC.
Slashdot Mirror
I think what has happened here is that one guy is talking about the fence while the others are talking about the hole in the fence (figuratively speaking). In other words -- "a spec" does not mean the same thing to Linus than it does to others. That is perfectly normal -- actually it is impossible for different people to understand a concept in an absolutely same way. It is so because different words have different associations in different minds and that's a fact.
However, both sides are right! For Linus, it seems, a spec is a general outline of the program that is made before any actual coding is done and Linus obviously knows that people often think spec has to remain unchanged ever since. Linus insists that You cannot write good software if it is based ONLY on such initial theoretical assumptions and models unless the theoretist is a real genius (can foresee all possible problems). Let's assume most people are not geniuses. So, if You have a project and You have initial spec, then desperate clinging to Your initial spec during realisation phase (coding etc) will ultimately take You to a situation where You do not want to be: everything works as it should but it doesn't serve it's intended purpose or even worse -- nothing neither works nor fits together because the creator of the initial spec didn't had a clue what it was all about. So, what Linus says, is that if You think that for building good software all You need is an initial spec, then You are living in a dreamworld.
What Linus left unsaid was, that a good spec always evolves during implementation (coding etc).
I do not believe that any programmer is capable of writing software without an initial spec -- having an understanding of the goal, it's subgoals and the way leading there. It doesn't matter, if this spec is in the form of paper, file or thought, it is always there.
What the opponents of Linus are talking about is knowledge about the inner workings and standards for input and output of the program. It is self-evident that no-one can tell with 100% certainty what will software be like before goals are reached and development has been ceased. In that sence, a spec in essence is linkage of initial theoretical assumptions with the results of implementation. For Open Source Community, the availability of such knowledge is crucial. I will not talk about business collaboration, since successful businessmen have already recognised the value of intellectual capital and the need to accumulate it -- as of that business world is way ahead of OSC.
I think Linus might be worried about his own work and might be reluctant to share the real essence of his work with the public -- to keep the rabbit in the hat, so to speak. I think it's up to Linus, whether he wants to show how his mind works or not -- his contributions are big enough. In general, a person who does not create specs for his or her own work, should not waste time writing Open Source Software. It is a burden for other developers in the OSC.