Microsoft attracted a lot of negative attention by claiming that open-source software violates 235 of its patents. Of course, there's no way to know how many patents Microsoft is violating because their source code is a well-kept secret.
For open-source applications, the source code is available for anyone to review, comment on and even modify. For Microsoft, the source code is proprietary. We can only see the end result.
The headline-grabbing statement seems to be a reaction to the increasing success of open source - to the point where Microsoft is worried. Developers of open-source software are doing something right. Let's examine their approach and see how we can apply the lessons learned to the typical IT department.
Open-source teams tend to be decentralized with a minimal hierarchy. This enables fast decision-making. Multiple levels of approval are not needed to get things done.
This level of autonomy can be difficult to accept but the productivity gains make it worthwhile. Let your teams define their own structure and reward system. Define clear guidelines and success parameters then let them go.
Open-source teams value intellectual contributions. The people that make the most valued contributions are the ones with the most influence and control. No one just goes along for the ride.
This approach follows the agile principle that results matter more than anything else. People who complain and criticize carry no weight with the team unless they can offer a better idea and help others implement it. Forget rank and job title. Only results matter.
Open-source teams collaborate. They use forums, email, instant messaging, and other tools to stay in contact and share information. They don't write lengthy documents as a means of sharing information.
Resist the corporate call to generate extensive paperwork. Offer the minimal level of documentation that corporate watchdogs require. If they want more, offer them software artifacts instead such as source code, use cases, architecture drawings, etc. Avoid creating new documents just for outside review.
Transparency is important to open-source developers. Source code and documentation are readily available for anyone to review. Ideas aren't hidden or protected. They're shared.
Provide access to all project documents including source code to any employee that wants it. Don't hold back. Withholding any information will only invite closer scrutiny and criticism.
Open-source developers have some latitude in selecting what they want to work on. This allows people to do what they like. If a particular project doesn't offer them something interesting, they select another. This energizes them and makes them more productive.
Corporate teams rarely have such latitude. Be sensitive to what your people like to do and want to learn. Offer as much flexibility as you can. The increase in productivity can be amazing.
Open-source teams actively involve end users throughout the development cycle. Early and frequent feedback provides a self-correcting mechanism for the team. Many small corrections are easier to manage and integrate than a few major ones near the end of the project.
Work directly with the user community. Don't rely on marketing or some other group to act as a liaison. First hand feedback is always the best.
Peer review is one of the stalwarts of open-source development. Team members look forward to having their work reviewed by their peers. This is one of the key ways that they learn from each other and develop their skills.
Peer review must be an assessment by other developers not professional reviewers who no longer write software. The team must respect the reviewer for this to work.
The open-source focus is on continuous improvement by incremental, not monumental, change. Small, frequent changes allow for rapid development and feedback cycles. Both quality and productivity improve.
Keep project timelines short. If many new features are being demanded, group them into a series of short projects or iterations. Insist on user feedback after each iteration.
Time is not rigidly controlled on open-source projects. Quality and stability are valued more than getting the next major release done by a predefined date. This works because there are multiple mini-releases of the software along the way. The major defects are corrected and many people install the application before the final release is delivered.
Open-source developers embrace reuse. They don't like to re-invent the wheel. They are more interested in solving new problems.
By openly sharing source code within your company, you can promote internal reuse. Quality will improve and developers will find pride in having their work used by others.
Many of these precepts are difficult for larger firms to accept. When software quality deteriorates and user complaints increase, there is a tendency to introduce additional management controls and reviews. While these steps can be effective in dealing with quality, they almost always reduce productivity and increase costs.
Corporate structures that include project management offices, quality review boards, or system architecture committees are prone to slow and costly software development projects. The concept of review and discussion is a good one. An approach that requires extensive documentation is not.
Energize your teams by challenging them to produce results not documents. Give your teams the tools they need to be successful. And most importantly, get out of their way and let them succeed.
Vin D'Amico is Founder and President of DAMICON, your ADJUNCT CIO. He helps companies avoid the subtle mistakes that cause missed deadlines, lost opportunities and fragile results. He shows them agile approaches that slash risk and cut development time so they get to market 25-50% faster. He helps them carry that momentum into the sales cycle using white papers and case studies that accelerate the selling process.
This article appeared in Vin's monthly Virtual Business column for the IndUS Business Journal in June 2007.
To learn more about how DAMICON can help your business, please take a look at our service programs.
This column appears monthly in the IndUS Business Journal.