Build Open Source Management into Software Development: Open Source Development Tip #8

We’ve been publishing a series of tips on managing your use of open source maximize benefits and minimize the risks. You can find earlier other posts in the series here and a summary of the entire set of tips here. In today’s post, we continue with a tip on building open source management into your software development process.

8. Build open source management into your software development process

We’ve found that many organizations wait until development is nearly complete before they run scans to verify that their open source policies have been followed. What else have we found? That developers find this maddeningly frustrating. For example, if an application scan discovers that a component is unacceptably licensed, such as with GPL, you’ll have to find a replacement component, rework the code, and retest the application. The project will cost more than expected and be delivered late. The disruption will likely impact the next project too as the team will be stuck on the original project longer than expected.

Frustrated developers often tell us that they’d much rather catch and fix issues during development rather than wait until the end. We agree. Here are some of our ideas for ensuring open source compliance without disrupting development:

• During Design: Having access to security and licensing information for each component will allow you to validate them before including them in your project. This sounds obvious, but it’s often tough to discover this information, especially when considering the hidden dependencies in Java components.
• During Development: Open source projects are constantly being updated. Many updates can safely be ignored, but you’ll want to follow them all so you don’t miss any that address security or quality issues discovered by the community.
• During Build: The CI system is the ideal place to verify that all the components used meet your standards. You’ll catch issues as soon as they are introduced and be able to fix them quickly. Think of it as using the CI system to alert you of compliance issues just as it alerts you to quality issues today.
• In the Repository: Restricting the repository to approved artifacts is another method for ensuring that applications are free of defects. Some organizations approve every artifact before allowing it in the repository (whitelist), while others allow developers to add any component by default and only restrict those with known issues (blacklist).

At this point you may be thinking that all of this sounds great, but would be really hard to implement in practice without automated tooling. We agree with you, which is why we created Sonatype Insight. Learn more about Insight here.