Version 2

    Here's my thoughts upon what we did in terms of development practice that helped make this project so popular so quickly.

     

    • rapid release schedule

     

    Regular file releases (even a few days from one version to the next) were the best way to keep the project bug-free and our users confident that the project was/is active. Having working software "out there", in actual use, is the best way to discover which functionality the users really need.

     

    • regression tests

     

    I guess the whole Java community appreciates the importance of automated unit tests by now. A comprehensive test suite was central to the maintainability and stability of this project, as it went through massive changes in functionality and design. The mentality should be that if theres no test for a feature, then we have absolutely no idea whether that feature works or not.

     

    • do one thing well

     

    Be the best at something. Let other projects worry about all the other things which you can't be the best at.

     

    • avoid over-design

     

    Aiming for too much abstraction and flexibility at an early stage is a great way to waste time that could be better spent solving actual problems that your actual users are facing. Do the simplest thing that can possibly work. Don't try to solve problems that your users don't care about. And it DOES NOT matter if your implementation is inelegant, at least initially. What matters is delivering useful functionality in a timely manner.

     

    • a central vision

     

    Its got to be a pretty damn big project before you need a committee to make decisions. Most projects are better off with one or two open minded people guiding the project and maintaining a single coherent vision. That way the project can focus upon doing one thing well. I suspect that scope creep sinks more open source projects than any other danger.

     

    • documentation

     

    There's no such thing as an undocumented feature. If your users don't know about a feature, its a nonfeature. Get rid of it; it's just complicating the sourcecode.

     

    • avoid standardsism

     

    Good standards can provide interoperability and portability. Bad standards can stifle innovation. "supports XXX standard" is not a real user requirement, particulary if XXX was designed by a committee of "experts" who, throughout the entire process, never once ate their own dogfood. De facto standards are usually a much better fit to user requirements than a priori ones. Standards are only useful if they are adopted industry-wide.

     

    • up and running in ten minutes or less!

     

    Prospective users don't have time to spend half an hour installing, configuring, troubleshooting a piece of software the first time they download it. Our aim is that new users can have the demo running in five minutes (assuming sufficient knowledge of JDBC) and their own simple Hello World style application going inside of an hour.

     

    • developer responsiveness

     

    When users have problems, which they inevitably will, the development team must be responsive and helpful. Users let you know about holes in your documentation. Users find the subtle bugs that your test suite misses. And besides, the project is a waste of time without them.

     

    Incidently, heres a funny thing about bugs: users don't mind discovering bugs in new features, as long as they are fixed quickly. "Responsiveness" means bugfixes should be ready in under a week. 24 hours is a good target for the average response time between a bug report and the CVS fix.

     

    • Professional Open Source

     

    Without an income from their work, developers would not be able to do all the things listed here. Not many business models have emerged to allow open source developers to make a living from their software, one of them is JBoss Inc's Professional Open Source. In addition to supporting developers, it allows business users to get what they need in critical projects: development support, production support, and professional training. A successful open source project needs full-time developers and commercial backing.

     

    • easily update-able wiki pages.....