- When to use — and when not to use — Open Source Software
- Advice for Optimizing Open Source
This chapter is from the book
This chapter is from the book
This chapter is from the book
Advice for Optimizing Open Source
Experts have four key guidelines for using Open Source successfully.
-
Open Source is for "we" problems. "Open Source is a development model best suited for horizontal technologies, which lots of people need and use, such as the Mozilla browser or Apache server or MySQL database," says Eunice. "In those cases, the technology applies to everyone, regardless of the industry, and will get widespread contributions and upgrades. Conversely, if you try to use Open Source for something narrow, like a business application for the batch chemical manufacturing industry, it may apply to only a few companies. It's what you call a 'me' problem and probably going to be best solved by a proprietary product."
-
Use Open Source when 90% functionality is OK. You're more likely to find the most sophisticated features on commercial products, say experts. "By and large, Open Source meets 80% to 90% of [all possible] requirements, but companies pay for that last 10%, even that last 1%," says Eunice. "For instance, we really use Microsoft Office XP because it has two or three features we need that Open Source doesn't. On the other hand, the MySQL database is good enough, and we don't have a reason to pay for a proprietary database such as Oracle makes."
-
Craft corporate guidelines. Even more so than commercial software, Open Source requires guidelines, says Chiappinelli. "Open Source demands a higher level of attention to policies and processes partly because it is somewhat of a new thing and can really scare executives," he says. "If a vice president finds out his mission critical application is running on Open Source, even if it's the best product out there, there may be political ramifications if the decision hasn't been well communicated. It's like the old adage that you can't get fired for buying IBM; nobody wants to go with Open Source and risk a failure due to a lack of clear corporate policy." He suggests usage policies spell out how and where Open Source may be employed, as well as how — and if — modifications can be made public to the Open Source community.
-
Establish a reuse program. Flashline's Fay recommends implementing a reuse program as a way to distribute approved Open Source code, communicate organizational policies, and track internal modifications and versions. "A managed reuse program includes a registry of organizationally approved Open Source software and the usage policies, as well as guidelines and processes for making changes to Open Source. Moreover, a managed reuse program provides a channel of communication for internal users, so they are automatically notified of new versions or changing organizational policies." Organizations that use Open Source are already practicing reuse — they're leveraging existing software rather than building it from scratch. Through a more formalized program, they can extend reuse beyond Open Source and begin to leverage their internally developed software as well. "Some of our customers don't have a support team to maintain and modify their internally developed reusable software. These organizations have adopted an Open Source management model for their reuse program — the developers can use the software in the registry and make modifications. However, they are required to resubmit these changes to the registry so that the enhancements are made available to the internal community. It's a model that works well for organizations with distributed resources."
-
Consider the long-term implications. "Usually, the long term costs come down to people/skill costs and what I call entanglement costs," says Eunice. "Open Source often has very good attributes with regards to the entanglement costs. Unlike, for instance, Microsoft applications, where there are constant upgrades you have to do, and a whole set of training requirements and so forth. Most of your Open Source tools, on the other hand, may not be as functional, but leave a lot of your options open."
Version control policies are also critical, says Cimetiere, since developers have easy, and free, access to upgrades: "Version control is a major concern, since Open Source software is easy to download."
When establishing a reuse policy or program, also keep in mind that Open Source software tends to evolve from "white box" to "black box" status as it matures, so developers will have less need to tinker with the code over time and, instead, will come to treat mature Open Source products as pluggable black box components. In that sense OSS offers a viable support model for white box assets, a welcome solution to organizations struggling with asset ownership and support issues that can derail efforts to incorporate reuse into the development life-cycle. Community ownership and support of white box assets directly addresses concerns that sharing an asset in a reuse program leaves the individual developer open to time-consuming support questions and customization requests. Freed from the burden of sole responsibility for a particular asset, developers have a far greater incentive to submit assets for reuse, which in turn benefits the entire development organization by increasing the supply of assets with reuse potential.
Such was the case for Cardinal Distribution's IT staff. The decision to go Open Source provided them with a degree of flexibility and avoided forcing them into a long-term commitment to a particular platform or product
"For us, going with Open Source meant we could provide significant new opportunities without asking for a huge outlay of initial capital and with the ability to switch to something else if we'd had to," says Foster. "It gave us the degree of agility that we needed at the time."