Open source programs at organizations of all sizes are fueling innovation, and many program leaders are quickly learning that weaving open source code into projects — and creating new projects — require informed guidelines and best practices. Organizations are often leveraging existing open source code to build their own commercial products and services, and contributing back to projects.
However, diving in and using open source code without an understanding of everything from legal risks to best development practices is perilous. Approaching open source code usage without best practices in place can also tarnish an organization’s reputation. That’s where the free, new Using Open Source Code guide comes in. It can help you craft and codify a comprehensive strategy.
One of the most important steps in using open source code effectively within your program is to set explicit guidelines to be followed, which are often summarized in a strategy document. What if code comes into one of your projects from a project with a different licensing setup? What acceptance, rejection, and exception policies should developers follow? What is your organization’s overall stance toward open source development?
These are all among the questions that need concrete answers as you codify your strategy, and there are more questions involving the ecosystem that applies to using open source code. How are APIs documented? Have you laid out a Contributor Licensing Agreement that everyone can use? Have you picked the right license for your project? Your strategy document should be specific about best practices, APIs and more.
“A well-designed open source compliance process should simultaneously ensure compliance with the terms of open source licenses and also help companies protect their own intellectual property and that of third-party suppliers from unintended disclosure and/or other consequences,” notes Ibrahim Haddad, Vice President of R&D and Head of the Open Source Group at Samsung Research America.
Creating a Policy
As the guide notes, creating a strategy document featuring best practices does not need to be complicated. A good open source usage policy includes six simple rules:
- Engineers must receive approval from the OSRB before integrating any open source code in a product.
- Software received from third parties must be audited to identify any open source code included, which ensures license obligations can be fulfilled before a product ships.
- All software must be audited and reviewed, including all proprietary software components.
- Products must fulfill open source licensing obligations prior to customer receipt.
- Approval for using a given open source component in one product is not approval for another deployment, even if the open source component is the same.
- All changed components must go through the approval process.
Importantly, the guide also notes the importance of effective code review practices. “If your code review process is overly burdensome, you’ll slow innovation or provide a good excuse for developers to circumvent the process completely,” Haddad emphasizes.
Additionally, Haddad, advises that circumspect code usage and compliance practices must be ongoing. “It’s important to remember that open source compliance doesn’t stop with version 1.0,” he said.
The Using Open Source Code guide can help you with everything from licensing issues to best development practices, and it explores how to seamlessly and safely weave open components into your open source projects. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are all extremely valuable for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can establish and execute on their open source strategies efficiently, with clear terms.
These guides were produced based on expertise from open source leaders. Check out the guides and stay tuned for our continuing coverage.
Also, don’t miss the previous articles in the series:
Latest posts by Sam Dean (see all)
- Open Source AI For Everyone: Three Projects to Know - May 10, 2018
- The Maintainer’s Paradox: Balancing Project and Community - May 4, 2018
- 7 Axioms for Calm Technology - April 18, 2018