Adapting downloaded code and finding developers to submit bug fixes back to the projects are just two of the many costs associated with incorporating open source code, according to Don Rosenberg, president of Stromian Technologies. Don Rosenberg is SearchOpenSource.com's newest expert, specializing in open source issues and strategies.
In this interview, Rosenberg, author of Open Source: The Unauthorized White Papers (Wiley), a book about taking a business approach to open source software, discusses criteria for releasing, incorporating and evaluating open source code.
What are the costs associated with incorporating open source code?
Don Rosenberg: A company wanting to take advantage of open source code for internal use, you should consider the following cost items:
- Developer(s) to:
- adapt downloaded code to local requirements
- deal with software dependency problems, and to maintain local code as newer versions are downloaded
- submit bug reports/fixes back to the projects, along with improvements the company has managed to make while solving its own problems
- A communication system for the developers. Depending on the size of the company, the communication system could include IM, email and forum/wiki.
- Development tools for the software, including source tree with version control and methods of dealing with bugs, trouble tickets, etc.
- System to decide what code is accepted, what needs to be modified, what needs to be written, etc.
In working out the costs, you will find that the needed software tools are likely to be free, but the manpower for setting it up and doing all of the above is not.
But rather than go to management with a list of costs (nobody wants to be a "cost center"), compare your costs with the costs of a.) proprietary software and outside consultants and b.) doing nothing. Also, look for ways to show that the software will not just save money but will also increase revenues (such as a more efficient or larger order-taking/fulfillment system, or one that has more uptime).
What are the costs for a company that wants to release internal code into open source?
Rosenberg: If a company has internal code that it wants to share with the outsiders, involving them requires preparation.
First, the goals and strategy must be worked out. What are you trying to accomplish?
Suppose you decide that you are tired of maintaining middleware all by yourself. Surely some other companies would like to have what you've developed and are using internally. If more people used it, then the maintenance burden could be shared. Since middleware does not usually provide a compelling competitive advantage, there is no reason why people in the same business (your competitors) could not use it too.
The most important step, however, is to talk to the people you think would be interested in the software. Don't proceed if you can't turn up outside interest. Simply putting the code up on the Internet and hoping people will come by and contribute is not very realistic.
Assuming there is outside interest, then you need to consider all the items in the internal open source example given above. Everything must be done so that it is attractive to outsiders. What tools do they like to use? Is it easy to contribute?
You need to pick a license and decide who will have the right amount of drive and diplomacy to be the project leader. How will decisions be reached? What are the standards for granting code-committing privileges? Will you require all contributors to sign a contributor's agreement before accepting their code?
Finally, what about a publicity plan to bring in even more outsiders beyond the initial group who have expressed an interest? At a minimum, consider announcing the project in the proper places and giving it its own Web site.
How can companies evaluate whether or not a given open source solution aligns with enterprise system requirements?
Rosenberg: I can only point you in the direction of finding the methods of evaluation. All the work will fall on your shoulders.
First, build a decision matrix listing the qualities or features that you want or the problems the software must solve. For each one of these qualities, add a value to express how important each item is to you, relative to the others. The resulting numbers can help guide your decision and make you think hard about what you value and how much you value it.
Maturity modeling is a long-established engineering/quality-control method of assessing a technology, and now it has been brought into the software world. Bernard Golden's book, Succeeding with Open Source, gives an introduction to this method and shows how to apply it to open source software.
