Every developer has done it. We just needed a bit of XML parsing or a better utility for dealing with connections. So we downloaded a library, stuck it in our code base and used it. Minutes later we felt great as our software had new capabilities quickly. Weeks later when things started to break we wondered,  "Did one of those libraries also have bugs and does our team even know all the libraries it has let into its code?"

Reuse of open source or commercial libraries can be great. It lets a team focus on delivering unique functionality to the business without rewriting that XML parsing utility. However, a mature software development organization needs to understand some of the risks of reuse and take steps to chaperon their code.

A team should know

• which components we have in our product portfolio
• if we are staying compliant with licensing
• if the libraries we are using are secure
• if the various components we are using are compatible
• where developers can find pre-screened libraries

To address these challenges, we need a coherent strategy for chaperoning our organization's reuse. There are four elements of a successful strategy for managing components:

1) Testing and Validation of 3rd party components
2) A Definitive Software Library to track approved versions
3) Preventing unapproved libraries slipping in
4) Rapid audit of what is used where for impact analysis

Component Test Labs

At Urbancode, we increasingly encounter IT departments adopting rigorous standards for approving third party libraries for reuse. Developers identify specific versions of the components they want and a special testing team approves those versions. The best test labs screen licensing models, run security scans and test model applications built from a stack of proposed components for performance characteristics and correctness.

A Definitive Software Library

Once the test team approves a version of a component, we need to store the approved binary and give developers access to it. ITIL refers to this kind of storage as a Definitive Software Library (DSL) or Definitive Media Library. I'm a fan of the older DSL terminology.

Java teams using Maven can utilize solutions like Artifactory or Nexus to provide a basic DSL. AnthillPro customers, be they developing Java, Microsoft technologies or other stacks, can use the built in CodeStation repository to manage their shared artifacts. In either scenario, the approved libraries are provisioned automatically at build time making it easier for developers to use the pre-approved versions than download something new from the internet.

Using Protection

When a new library is required, developers may skirt the validation process and simply download a library and commit it into source control. Any gains made by the creation of an approval process for third party libraries can be undone very quickly. So we need a way of preventing unapproved libraries from entering our projects.

At Urbancode, part of our strategy is running an extra step in our automated, authoritative build process that scans the files checked out from source control for any obvious library files (those with extensions like .jar or .dll) and immediately failing the build if any are present. If the code base is clean, we continue on and retrieve any libraries we use from the DSL (CodeStation); and perform the build.

Rapid Impact Analysis

From time to time, a security firm may issue a warning about a commonly used library. Or the team behind the library may warn that a serious bug is in some versions. If we are using a DSL and preventing other components from being used, we can quickly identify if we might be impacted. If we have not approved those library versions we are in the clear.

If the team has approved problematic components, we know some of our projects are likely impacted. But which ones? To facilitate this impact analysis the team must track which projects use which libraries. At Urbancode, we use AnthillPro's CodeStation integration to automatically record when builds reference outside libraries. Our team can quickly and easily determine which projects, releases and builds include suspect libraries, speeding our impact analysis.

Conclusion

Reuse components. But reuse them responsibly. These four elements: testing, a DSL, prevention, and usage tracking; provide the foundation for controlled, effective reuse of 3rd party libraries.