I agree, fully, that there areplenty of cheapskates who'd rather get something for nothing, but I still maintain that the design cycle for most open-source code is upside down.

Often enough, I've had to remind people that the documentation should be complete, accepted, blessed, with Holy Water sprinkled upon it, before the first software weenie is allowed to sit down at his computer. Without that firm and "absolutely etched in stone" documentation ... documentation that clearly states what, exactly, the project's work product is supposed to do, how it's to do it, and how large and slow it's allowed to be ... there's nothing from which to derive requirements, which means there's nothing to guide the programmer, and, ultimately, against which he can test his work. The coder is the one who does the bulk of the tedious work, but he's not necessarily the one who makes the decisions about the previous features. He's the one who makes it happen, though. It never made a bit of difference to me what his hairstyle or footwear were, since he goes off into his own corner and does his work there.

Too often half the code is written before requirements analysis is performed.

Documentation is, of course, a major stumbling block. People have to be able to read and write in order to produce clear, precise spec's, and coders, who you'd think could do that pretty well, seldom want to mess with it.

I remember when we were whittling on LINUX i/o code in order to provide a few terminal server ports for ISDN for our ISP, there were some old bits of code that clearly had code for version 14.-something, but still bore the comments from v.0.9-something. That was frustrating!

If turning LINUX into a product superior to what Windows has become is the goal of the LINUX open-source community, I'd suggest they reinvert their design/development sequence.

RE