Vendors and original equipment manufacturers (OEM)—and their IT customers, governments, and academics—are all using, buying, and making open source software, and often all three activities at once. This is a good way to think about one’s relationship with open source software projects. There are three activities one typically engages in with respect to the open source software project: make, use, buy.
Sometimes one is performing all three activities with respect to a single project, e.g. buying Red Hat Advanced Server for primary deployment in IT, while also using the Centos distribution for development and testing, and contributing (making) a few bug fixes back to the Centos project. At other times one has a different relationship with each project in the enterprise portfolio, e.g. buying JBoss support for the application server, while using Fedora Linux (from Red Hat), and using and contributing back to the Eclipse integrated development environment (IDE) project in development.
Using and buying liberally-licensed open source software is relatively straightforward. One is simply consuming the software. One buys a product that is based on open source licensed software in the same way that one buys other software. One evaluates the vendor’s offering against one’s own IT requirements and managed procurement risk profiles. Another way to say this is that you don’t procure Red Hat Linux server software differently than you historically bought Solaris or might buy Microsoft Windows Server systems.
Using an open source-licensed software project (as opposed to buying a product based on it) adds additional considerations that should factor in the strength of its community and the costs of supporting that choice either through the development of in-house expertise or external specialists. One develops in-house expertise by participating in the open source project’s community.
One reviews a project’s documentation and tutorials, forum and email list activity, and IRC channels. One also should consider the availability of contracting support from around the community. These considerations are the same whether the open source software under consideration is tools and systems or developer libraries and frameworks. The investigations and trade-offs are no different whether one is an individual with an amount of time to invest to solve the problem or an IT department wanting to use open source software on a large scale.
Once one starts to make open source software, i.e. to produce it, there are different considerations. These are the two scenarios for producing open source:
- Contributing to an existing project, adding value through bug fixes and new functionality (and non-software contributions like documentation and translations).
- Starting a new open source project, which means organizing the infrastructure, developing the initial software, and providing for the early community.
The motivation for contributing to an open source project is simple. People generally start using open source software before they become contributors. They use it because it solves a problem. Once they use the software for a while they will encounter a bug, have a change they want to make, or possibly document a new use case. Contributions can be given back if the user is comfortable making the software changes and the project community has done a good job of making it easy to contribute.
It sounds easy enough to simply make the necessary change and ignore the contribution back to the community, but living on a personal forked copy of the software comes at a cost. There are two main problems: other enhancements and bug fixes aren’t seen and shared except by installing newer versions of the 'official' software, and the forked software will need to be re-integrated if upgrading. This can amount to significant work.
It is far better to contribute one’s changes back to the project community if feasible, working with the project maintainers to ensure it is contributed correctly and patched into the main development tree. The onus is on the community to make it easy to contribute and on the on the contributor to do so correctly. The cost of living on a fork gets worse over time as the forked branch drifts further away from the project’s developmental course. It’s well worth the investment to embrace the efficiencies of the development model and contribute back.
The steps from using to contributing and participating in an existing project are small. A company that chooses to use an open source software project to solve its problems rather than purchasing a product has already invested in learning the project enough such that contribution is an easy step with automatic cost savings over living on a fork. The contribution step is easy—even if one is paying for support.
However, creating one’s own open source software project requires more care and investment, and we explore that in the blog post: Making Open Source Software: the considerations around a project's success.
Originally posted in a series on the OuterCurve Foundation blog. Reposted using Creative Commons.
View the complete collection of Beginners in Open Source Week articles.
2 Comments