Guidelines for Contributing and/or Committing Code to an Open Source Community Project
One of the benefits of using community versions of open source software is the ability to change and modify the source code and contribute (or commit) the new functionality back to the community. Acceptance of modified code contributions by the community will hopefully make the software perform better and become more secure. For the individual coder working with open source as a personal interest, a hobby, a learning experience, or even as part of a formal education this flexibility to modify and contribute to the project provides the freedom to explore possibilities on the bleeding edge of major Internet technologies. For the developer, engineer, enterprise architect, or system administrator working on a project for an employer, the freedom still exists. However due to various business concerns, the modifications and contributions should be managed carefully. For the later category of open source software users, today’s blog article will cover a few basic guidelines to consider when contributing open source code modifications back to the open source software project.
1. Understand the difference between a contribution and a commit.
Just about anyone in the world can attempt to contribute to an open source software community project. Contributions are partially how and why open source continues to outperform commercial software in many cases. It is important to do a little research about an open source community and its contribution process before modifying the code of an open source project and expecting the community to accept the modification into the newest version. Becoming a committer to an open source community means that the governing members of the community grant an individual (usually only highly skilled developers and coding experts) access to the main code repositories that hold the source code for existing versions and new development. Because committers control the code base repository they obviously have a greater level of influence and prestige in open source communities than the majority of end users.
2. Read your corporate open source policy or contact an open source policy administrator before making a contribution.
This is a “no brainer” for any kind of open source usage in the business world. If open source community participation and contributions are not addressed by the OSS policy, that policy drastically needs to be updated. Many companies encourage open source community participation; others prohibit it or prohibit the participation from being associated with corporate identity (i.e. using you full name, company email address, or LinkedIn profile info in a community forum). For the individual user modifying open source code and participating publically in an open source community may not be a great concern, howeverm for an information security team managing a corporate environment this should be monitored carefully.
3. Educate yourself in open source license obligations.
Some open source license obligations require code modifications, regardless of the product usage, to be contributed back to the community. This may include contributing your own proprietary, home-grown code to the community. Again for an individual coder this may not be a concern, but for an intellectual property attorney that is responsible for protecting corporate software assets this situation could be very concerning.
4. Consider carefully the long term sustainability of the project, your status in the community, and where you are using the open source.
Modifying an open source product to address technical support challenges and/or enhance the performance of the product may seem like a quick and easy fix. However if you are not a committer to the community and a modification that you have submitted to the community is rejected, that instance of the modified open source product (also called a forked version) is probably going to exist unmaintained without the support of the community. Part of a mature open source community’s diligence in their maintenance is to continue to address security vulnerabilities and improve the project with new releases. An unmaintained forked version exposes information security vulnerabilities in an organization.
In my admittedly biased opinion open source software is one of the most valuable technology assets in the business world today. To ensure open source software continues to provide value and not expose risks, corporate users need to become educated on community involvement. Policy rules should be clearly documented and easily accessible, and business managers must give management of the policy, associated open source usage, and contributions or commits, the attention it deserves.
My next article on this topic will go into more detail about how new open source products and communities are created from old ones by intentionally forking the code to take the project in a new direction.
How to you plan on contributing to open source?
Jesse Hood is an account manager for many domestic and international customers of OpenLogic Inc. He excels in developing an amazingly good understanding of a clients needs to occasionally make recommendations for OpenLogics services and products that help organizations achieve success in their open source software initiatives. Jesse is motivated by challenging quotas and was a sales leader at OpenLogic in 2010 and 2011. Outside of the office he likes downhill skiing in the winter; hiking, biking, and rafting in the summer; and enjoying the beautiful state of Colorado in general.
This work is licensed under a Creative Commons Attribution 3.0 Unported License