If you're also a professional developer at your day job, then you may have tried to bring some of those great practices to work with you. If you have, then these excuses will sound very familiar: "We have a business to run." "Those ideas might work in a perfect world, but we need to concentrate on our code." "It would be great to do the project like that, but we just don't have time." It would be frustrating to contribute to a successful open source software project as a hobby, only to work on a challenged one professionally.

When people talk about the benefits of open source software, one of the first things to come up is "more eyeballs": when there are more people carefully looking at the code, it leads to better software. Open source projects rely heavily on open discussion of every aspect of the project: what features will (and won't!) be written, the best way to implement those features, how to keep the design flexible and maintainable for later additions, and how to address problems when they come up. When there are disputes, they are resolved often democratically and always in an open manner--and, generally, anyone can take part in the discussion, regardless of how many years of experience they have or their role on the project. And the most successful open source projects always seem to be the ones that adhere most closely to these ideas.

The GIMP project makes an excellent case study. The developer site lays out guidelines for every aspect of software development. It describes how the project is managed and who coordinates it. The site describes how developers use CVS, submit patches, and create documentation. There is a process for defect reporting, triage, repair, and verification. There are standards for building, packaging, testing, and releasing new versions. There are mailing lists for announcements, developers, users, documentation, and even for the website itself. There are tutorials and FAQs to help new developers get oriented and learn how the GIMP team works. Everything that happens on the GIMP project is planned and agreed upon by the team. And any new developers can go back and see exactly which decisions were made, who made them, and why. And the developers really do their best to observe these rules. No wonder GIMP is widely seen as one of the most successful and popular open source projects.

But the GIMP project is not alone in this. The vast majority of visible and successful open source projects are run in the same way. Some, like GnuCash, have all of this information on a wiki. Others, like KDE, drive their developer documentation from a Subversion repository. What they all have in common is extensive documentation and written policies on every aspect of how a developer is expected to interact with the rest of the team--and strong support from the entire team for maintaining and enforcing those policies. Almost every successful open source project has a similar website, and a similar commitment from the team.

Yet it is rare to find a corporate environment where the project team has anything approaching the level of planning, documentation, or review found in successful open source projects. For some reason, as soon as a budget and a deadline are involved, all of the lessons we've learned over the years and applied successfully to open source projects seem to fly out the window. Discussions of what features are in and out of scope never seem to take place. When a corporate developer tries to bring people together to discuss the design of the software or to make plans for how code is added or maintained, he's met with groans about "yet another meeting." What's worse, when a developer actually manages to get everyone on the team to agree to do design or code reviews, their managers often tell them to be careful "not to spend too much time" on it, implying that any activity other than writing code is somehow "frivolous" or "over-engineering." After all, they're "only" programmers, and their opinions only matter on issues directly related to the construction of the software. The direction that the software is taking should be "dictated by the business," and the programmers should just stick to writing code.

However, it's well known that corporate projects routinely fail to produce quality software. or even any results at all! Many important studies have repeatedly reported that fact, such as the Standish Group's annual CHAOS Report (which as recently as 2004 has shown [PDF] that less than one-third of corporate projects are considered successful).

Yet many large-scale open source projects succeed, and under much more difficult conditions: no budget, a widely geographically distributed team, and a completely volunteer workforce in which people take on only the roles and responsibilities that they feel like taking on, and put in only as much time as they want to devote. So how do open source project teams ensure success under conditions that would cause all but the most disciplined corporate project teams to immediately self-destruct? In our book, Applied Software Project Management (O'Reilly 2005; see our companion website), we introduce five basic principles that should be applied to every software development project. These principles, if adhered to, will help lead to success on any project, open source or proprietary. These principles are:

• Tell the truth all the time
• Trust the team
• Review everything, test everything
• All developers are created equal
• The fastest way through the project is to do it right

Each of these principles is important, and each of them is routinely ignored in corporate environments--to the detriment of project success. There are chronic behaviors that routinely occur on corporate projects, which violate these principles. On the other hand, by employing time-tested and accepted practices or means of collaboration, successful open source projects are very good at putting these principles into practice.

Far more here : http://www.onlamp.com/pub/a/onlamp/2006/02/27/what-corp-projects-learn-from-open-source.html