Learning open source lessons of software reuse
Software reuse is the Holy Grail of software development. But we continue to hear of corporate-sponsored software reuse programs that have not delivered on their promises.
Perhaps the problem is that available tools are not robust enough to categorize, catalogue and search for software. The problem could be that software reuse is perceived as having a technology solution, and it does not get management support. Or perhaps the problem is a lack of financial incentives. Whatever the cause, the promises of reuse have not been kept, even though we know in our hearts that software reuse must be possible.
The open source phenomenon, on the other hand, has been successful. Code is written, reused and enhanced by thousands of software professionals using the Internet, without management support, without a tool linking all software objects together, and often without financial rewards. Perhaps there is a lesson to be learned by corporate reuse programs from the open source model.
The Apache HTTP Server Project is an example of the open source model producing an enviable success. Apache is the most popular Web server on the Internet. It boasts a 57 per cent penetration of Web servers, according to a May 1999 survey by Netcraft (www.netcraft.com/survey). Apache is a collection of software nurtured by a core team of developers, and the credit for writing, documenting and enhancing it is spread across hundreds of developers. It is stable, feature rich, popular (more popular than all its competitors combined), and it is free.
Another successful example is the Comprehensive Perl Archive Network. The CPAN archive contains about 600MB of source code and documentation, and is mirrored at 100 sites worldwide. Thousands of developers work together so they can exploit this massive library of useful Perl material. CPAN’s rules are simple. If something exists, use it. If something is close to what you need, contact the original author and work together to enhance it. If it doesn’t exist, write it and add it to the archive. The archive undergoes a de facto peer-review process every time someone reuses the software in it. Improvements or suggestions are fed back to the original authors. The end result is a library of well-written, well-documented and powerful software, which other developers actively reuse.
If we examine the factors that contribute to the success of Apache and CPAN, perhaps we can apply them on a corporate software reuse project. The following is an initial list of six lessons to consider:
1. The project must have a developer community that is interested in using the software.
2. Expectations for the running of the project must be set and communicated up front. Feedback communication channels, such as e-mail and discussion groups, have proven to be effective.
3. The software and all of its documentation for installing, using, enhancing and reporting bugs must be available on-line all the time. A Web site, indexed by a search engine, has been proven effective for interfacing with the developer community.
4. Code base releases must be timely and in sync with the developer community expectations.
5. A publisher or author must retain control over the official release and interact with the developer community.
6. Contributors must be publicly recognized.
We have not identified why corporate reuse programs fail here. It could be (and likely will be) argued that the open-source style of projects may not be the ideal approach for maximizing reuse in the corporate world. However, the open source phenomenon has certainly demonstrated an impressive ability to provide reuse in the real world.
Nelson is chief scientist and managing director of the Applied Technology Research Group of EDS Systemhouse. He can be reached at tnelson@shl.com.
