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

November 17, 2011
By Terry Bernstein

2 minute read time

We've been publishing a series of tips on managing your use of open source to maximize benefits and minimize risks. 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 unacceptable 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, as the team will be stuck longer than expected on the original project.

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 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 to ensure 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 think all this sounds great, but would be hard to implement in practice without automated tooling. We agree with you, which is why we created Sonatype Insight.

Written by Terry Bernstein
Terry is the former Director of Product Marketing at Sonatype. He is now the Director of Product Management at Verisign.