Firms can improve success rate by learning from open source software development

Open source methods can be used by corporate IT teams

Open source methods can be used by corporate IT teams

Open source projects have resulted in some of today's most innovative products. Many of the practices and staffing models used in open source development could be adopted by corporate IT.

In corporate software development, less than a third of projects finish on time, on budget and within scope. Furthermore, the overall percentage of functionality delivered is barely more than half.

So what is being done? Top-down process improvement initiatives have been implemented in many IT organisations, but they have not won developers' hearts and minds.

Agile development processes have gained a considerable following - especially among developers - but sceptics still doubt their scalability.

The open source development model, in contrast, has been proven to work on large-scale projects and has enticed hundreds of thousands of volunteers to work on projects for free.

Learn from open source

Open source software has moved from the margins to the mainstream - 46% of firms surveyed by Forrester currently use open source, and another 14% plan to use it within the next 12 months.

Open source projects - including Apache, Linux, MySQL and Tomcat - have achieved success and won worldwide renown for their development models. Many of their processes are suitable for corporate environments and can improve developers' productivity and quality. For example, open source projects have demonstrated how agile techniques, such as formal user involvement and continuous integration, work for large-scale developments.

There are at least three areas in which open source can benefit corporate IT: getting end-users involved; team communication and staffing models.

Involve users in development

Linux creator Linus Torvalds observed that a large user base can be even more valuable than a large developer base. And Eric Raymond, who has written books on the Linux development model, said, "Given enough eyeballs, all bugs are shallow."

Not only do open source users specify requirements, but they also participate in design reviews, testing and implementation of new systems. IT organisations should look for ways to involve end-users in as many stages of development as possible.

This can be achieved in several ways. IT managers can make source code and other artefacts, such as requirements documents, issues lists and project schedules, available to internal customers - especially those with technical savvy. This will allow customers to identify issues earlier in the project lifecycle and feel a greater sense of ownership.

You can also recruit beta testers. Select from your most involved end-users those who are willing and able to use beta versions of your application. This can work for development organisations of all levels: IBM and Microsoft involve beta testers through the Microsoft Developer Network and IBM's Alphaworks. Corporate IT departments can follow suit on a smaller scale.

In terms of team communication, open source projects rely heavily on tools as modes of communication. For instance, open source projects are more likely to build and use automated communications archives. Mailing list archives are the most commonly used method, although wikis - web-based collaborative writing tools - are growing in popularity.

Corporate IT departments must strive to capture and store various team communication - from e-mail to instant messaging to virtual conferences - to improve team co-ordination. Scalable collaborative development environments such as Collabnet's Sourcecast and VA Software's Sourceforge can also help.

This approach can make documentation less of a chore by automatically documenting parts of the development process, therefore freeing team members for more valuable tasks.

Although team communications systems will not do away with documentation altogether - development teams will still have to create artefacts such as requirements documents, design models and test plans - these tools will cut down on the amount of documentation the team must explicitly create. It can also create a valuable information asset.

Archiving as much of the development process as possible protects a team's knowledge base, which is susceptible to depletion in the event of employee departures. Even sick days are less problematic at firms that use this strategy. Automatically logging development activities on the system is an excellent way to capture and transfer knowledge among team members.

Firms should also increase the visibility of the project information to people who are not team members to improve co-ordination and increase productivity. Increased transparency can also improve the accountability and performance of individual employees by providing a documented workflow and a basis for feedback.

Leading development organisations know that disclosure improves business relationships and will communicate select information about project progress to customers.

Flexibility and functionality

Open source projects typically consist of a few core developers, a larger number of non-core developers (contributors) and a vast pool of users. More than 50% of open source developers participate in two or more projects and another 10% participate in 10 or more. Developers benefit from the broader exposure that results from involvement in multiple projects and they are generally more engaged and satisfied than their peers.

Ten years ago, a Fortune 100 company's IT department launched an innovative staffing process: mentors worked with developers to determine where developers' talents and interests lay, and then negotiated to put them on the most appropriate projects.

The upshot was that the retention rate grew at a time when client/server developers were in great demand and were being wooed by many other firms.

Developers preferred this bottom-up staffing process because it gave them some control over their fate. Managers ended up leading teams of people who were more likely to be excited about their work.

It is important to communicate to programmers that they are the core developers on their primary teams, but that they should function as contributors on other teams. Cross-staffing exposes developers to new methods, and when they are on multiple teams, it is more likely that they will be asked to do the work they can do best, instead of what work is available.

In open source communities, the most dedicated and accomplished members of a project are entrusted with the job of committing new or enhanced code to the code repository. Corporate IT departments should transform this from an administrative role to one of coveted leadership by endowing it with additional responsibilities and clout, similar to those of the open source committer.

The code committer can also be responsible for enforcing peer code review and for maintaining the modularity of the system, even when the pressure is on.

Firms that allow developers to choose which other projects to work on must revise developer goals to reflect this. Managers must reward developers based on how much code they contribute to other projects and how much of that code is accepted.

The success of this strategy depends on developers understanding that they are expected, not just encouraged, to contribute to more than one project. All levels of management must be on board for this strategy to succeed.

Many of the principles of open source development match those of agile development processes, such as Extreme Programming and Scrum. And although adoption of Agile development processes is increasing, there are still many who doubt they are practical for large projects. In fact, open source projects have demonstrated that Agile techniques can work on a large-scale distributed basis.

l Liz Barnett is vice-president and research leader at Forrester. This article was written in conjunction with Carey E Schwaber

Read more on Business applications