Community building is a difficult thing to do. I've been involved in two developing communities over the past months. SAKAI and Open Solaris and they are both fascinating. I have managed many large scale development projects with huge numbers of developers both on site and in distributed environments. I am a big supporter of community development and have used it for many years on my development projects. Having been involved in these high profile projects and a few on Java.Net have helped me refine the development process I'll use on my next project.
I believe there is a place for open source, community source and bespoke purpose-built software where they seek to solve different problems. More thoughts on this later.
I have been blown away by the success of Open Solaris. In only 2 days there is a massive community and growing very quickly. The guys have done a great job in putting the right tools in place to support virtual collaboration.
The coolest thing about the Open Solaris community is the Sun Studio 10 compiler to build the OS. It rocks and is blazing fast.
I can't wait to see how this evolves...build your own OS and then build your own eLearning apps....now that's choice.
I'm off on a much needed vacation now but when I come back I'll be setting up SAKAI and Moodle on Open Solaris.
Stay tuned for build instructions appearing on www.sun.com/edu

I remember my toughest assignment at University was having to write an essay on defining the meaning of quality. At the time it was in the context of the US car manufacturing industry and their adoption of the Japanese 'Total Quality' techniques which have now evolved into the Six Sigma quality improvement approach pioneered at Motorola now adopted at most organizations including Sun.

Study: Few bugs in MySQL database | CNET News.com

What is a bug anyway?

In a services contract for a bespoke software system it is a mismatch between requirements and the delivered software. More often than not it's a mismatch between expectations and the delivered software because the requirements were so poorly documented or the functional domain was not clear to the team. You could say unexpected outcomes are bugs. This might be true of uncaught exceptions. Generally, poorly written code that leads to memory leaks, race conditions or is just plain ugly is also called buggy.

If the software is not delivered to contract as is the case for open source then how do you measure it's quality? I don't know the environment that the MySQL software was tested and am not familiar with the company that performed the tests. Did the team develop a tight test harness to verify the documented functional requirements for the RDBMS? My guess is yes - to a level but there was more automated code profiling and checking for code cleanliness and security holes.

Don't get me wrong, I think MySQL is an excellent piece of engineering but I object to the often touted claim that open source software has a higher 'quality' than commercial products simply because there are more eyes reviewing it. Quality is ensured by a structured process of managing expected outcomes to delivery and that requires more than releasing your code for review. I agree that more eyes is a good thing not just to catch 'bad or ugly code' but also to get as many possible unique solutions to a problem is mostly a good thing - too many chefs and all that. Any good architect encourages peer review on their project, open source and commercial.

The only bug free software in the world is our old friend Hello World. Its functional design and expected outcome is well documented in every programming 101 book in history. With my expectations set I am assured Hello World is of excellent quality.

Of course someone could claim they expected "Hello World!" instead of "Hello World". Doh!!! My perfect software is riddled with bugs and 100% failure rate !!