But some companies and government organisations are taking their commitment to open source a step further by participating in the open-source community.
The Linux operating system is only one example of the many pieces of open-source software in circulation. In each case, the software's licence allows it to be freely copied and distributed by anyone, the source code is available along with a working version of the software, and anyone can modify or expand on the code. Most open-source software can be downloaded free from the internet and is maintained and expanded by a community of developers who donate their patches and modifications.
These days, some corporate and government entities are getting into the act as well. When their developers write patches, modifications or new implementations of open-source software for in-house use, these organisations are releasing that new code back to the open-source community, thereby assisting in the software's development.
But what is the payoff? It makes for better software.
"If we find a bug or a problem, we're interested in fixing that problem. We're also interested in not fixing it again in the next version," explains Robert Lefkowitz, director of open-source strategy at finance house Merrill Lynch in New York.
"If you download open-source software, then take it in-house and don't share your revised code. You wind up maintaining your own separate fork of the software for all time," says Eric Raymond, president of the Open Source Initiative, a web-based, non-profit group that helps define and promote the open-source concept.
"On the other hand, by participating in open-source projects, you make sure your corporate needs have a seat at the table when large-scale design decisions are being made."
This is why Merrill Lynch sent the fixes it made to open-source software during one of its projects back to the open-source community. "The way a typical open-source project works is that there is a core team in the community with direct access to modifying the code on its central website," Lefkowitz says. "People who want to contribute to that community submit their code, which is looked at by a core team and integrated if found appropriate."
Sharing can be especially helpful if your software needs are different from those of most organisations, notes Jim Willis, director of eGovernment at the Rhode Island Department of State.
His office used open-source software to design a repository for the vast library of content, which ranges from rules and regulations to the minutes of municipal meetings, that the State Department must keep on hand and make available to the general public.
A colleague from the state of Hawaii heard about Willis' work and e-mailed to ask his advice about a similar project. That got Willis thinking that states could help one another by sharing the open-source software they had modified for special state uses. "We're now trying to set up [an online] repository of which state agencies are using open source and for what projects," he says.
Although the details have yet to be ironed out, Willis plans for the states' open-source repository to be available to everyone, so the rest of the open-source community can benefit - and contribute. The plan is for Rhode Island and Hawaii to create and maintain a website together that will archive the documentation of the work each state has done on its open-source software. The hope is that in the future other states will also document their work.
"Documenting our practices with the intent to share them with others has threefold benefits," Willis notes. "We learn from the experience of other states, we share development resources with other states, and we have better internal documentation of our own practices. All this for the effort of articulating our practices and documenting our internally developed software such that it makes sense to others."
For companies that decide to join in the open-source community, there's a right way and a wrong way to go about it. Raymond advises that corporate contributions to any open-source directory should come from individual developers, rather than generically from the corporation.
"In general, people in the open-source community don't want to deal with corporate entities. They want to deal with specific people who they can reach by e-mail. So you need to allow in-house developers to grow individual reputations," he says.
Willis also advises against jumping in too soon. "Most developers aren't ready to start giving back the day they start using a piece of open-source software," he notes. "It takes a while to get to know the software well enough to make a contribution." How long this takes varies from developer to developer, he says, but he recommends waiting until you're quite comfortable with the software before contributing.
Lefkowitz says source code is only one of several types of donation your company or its developers can make. "A lot of open-source communities say they have all the coders they need," he says. "But they need documentation. They need that documentation translated into languages other than English, and they need graphic artists to design and contribute icons."
For all contributions, Lefkowitz emphasises the importance of creating a corporate policy with help from the departments that could be affected by open-source involvement. At Merrill Lynch, an eight-member Open Source Review Board determines when contributing is appropriate. "We have representatives from security, legal, network, architecture, infrastructure support and purchasing," he says. "We work through the questions of where we want to have engagements and where we have concerns."
Having a policy in place is especially important for controlling when and how source code is released, which can have legal ramifications in terms of liability and licensing, says Tony Stanco, an attorney and associate director for Open Source and eGovernment at the Cyber Security Policy and Research Institute at George Washington University in Washington.
For example, one large company created a separate foundation for releasing code for liability reasons. The rules for releasing code vary for different types of open-source software because they are governed by many different types of licenses. But even without a policy, there's a good chance that your company's programmers will share their open-source work - and it might not even occur to them to ask for permission.
"A lot of it goes on under the radar," Stanco says. "Developers spend a lot of time working on something, and it requires them to do modifications. Because they know it's open-source software, they'll put it out to the community as a matter of course."
But, he adds, "that's why we have such great open-source software".
This was first published in April 2003