What open source projects are you using? How are they licensed? Which internal applications use the most open source? Which use the least? Which have security vulnerabilities you need to address?
Software development organizations need to ask—and answer—these questions on a regular basis, not just to ensure compliance with open source licenses, but also to understand their open source usage profile.
Why is it important to understand your open source usage profile?
Modern software development teams do more, faster, and with fewer resources, by leveraging open source components. Gone are the days when developers wrote their own String and HashTable classes, but with this new power comes a new responsibility. Teams are now responsible for tracking and managing their use of open source to avoid technical and legal incompatibilities, security issues, and maintenance nightmares.
While other articles address legal and licensing issues, this post focuses on the technical aspects of your open source usage profile.
Open Source Usage Profile
An open source usage profile is based on the open source languages, tools, and components used in application development initiatives and how those components are used. This profile is key in understanding where to invest (e.g., training, education, support, governance), investigate (e.g., analyze, automate, mitigate issues), and prepare (e.g., plan upgrades, find alternatives, replace components). To create your open source usage profile, either survey developers (fraught with peril) and track results in Microsoft Excel, or use an automated scanning toolsuch as
OpenLogic's OSS Deep Discovery. Whichever path you choose, be sure to update your profile at least once per year, because projects and licenses change rapidly in the world of open source.
Use your up-to-date profile to mitigate technical incompatibilities, security issues, and maintenance problems.
Since open source projects are the biggest users of open source code, it is highly likely that favorite projects depend on other open source components, and so on. This dependency tree can quickly become wide and deep with different versions of the same package (such as a popular logging tool for Java) in the same tree. It is important to keep up-to-date with new releases, bug fixes, security patches, and compatibility improvements to avoid ongoing incompatibilities that lead to long development cycles, hard-to-squash bugs, and single component upgrades that demand upgrading everything else at the same time.
Staying up-to-date with new releases and bug fixes is relatively easy for a single project, but is more difficult when using hundreds of open source components (a common scenario in today's enterprise development environment). Options include subscribing to open source community mailing lists, visiting new release web pages (if available), and reading forums. A simpler, singular approach is to use OpenLogic's OpenUpdate1 service that sends customers aggregated open source news items, including information on new releases, security issues, and critical bug patches for popular enterprise-ready projects.
Security vulnerabilities are always a hot topic because they often require immediate action to avoid a public incident. It is important to know when an open source component you depend on has a vulnerability, and how to address it. Keeping current on vulnerabilities can be as involved as visiting the Common Vulnerabilities and Exposures site2, the National Vulnerability Database site3, and the Open Source Vulnerability Database4, or as easy as using OpenLogic's OSS Deep Discovery to scan your applications, and point out open source components with security vulnerabilities.
One of the many positive aspects of open source is its abundance of choice. You can choose from a variety of operating systems, languages, data stores, application servers, tools, and utilities of every stripe. You can choose a simple or a complex solution. You can favor performance over scalability, or vice versa. You can even choose an abandoned project with a dubious license over an enterprise-friendly one with a thriving community. Wait, what was that? That's right, it is not always clear which projects are suitable for use in an enterprise versus those that are only experiments or hobbies. If your developers bring the wrong projects in-house, there may be issues down the road, if you run into trouble and need to remove those projects.
Thoroughly research any open source components before bringing them inside your four walls. All should have a well-known open source license, a solid community behind them, and the availability of enterprise support options (with a stated SLA). OpenLogic offers a white paper detailing the 42-point process used to certify open source packages as enterprise-ready. Follow this, or a similar process, or secure your open source components from OpenLogic, to avoid issues in the future. For enterprise support on open source components, turn to the community or a support provider such as OpenLogic. It is inadvisable to rely solely on internal staff for open source support because they frequently move among projects, are not always available for 24x7 production support, and may even leave the company.
Another type of maintenance issue stems from choosing too many good projects and technologies. If every application team selects a different set of open source components, it can be difficult to share experiences, move developers among applications, and expect the teams to move in the same direction. Your open source usage profile will clearly show any need to consolidate. On the other hand, an up-to-date profile can also lead you to discover how to leverage newer technologies once they have proven successful in the organization.
Get started by creating an open source usage profile for a single application. It may surprise you how many components you are already using, and how many languages, licenses, and technologies those components use under the covers.
1 Want to learn more about OpenLogic's OpenUpdate Service? http://www.openlogic.com/products/open-update/ 2 Common Vulnerabilities and Exposures 3 National Vulnerability Database 4 Open Source Vulnerability Database Need more information around Technical Governance? Contact us at: http://www.openlogic.com/services/technical-due-diligence-software-audits/
Allowed tags: <a> link, <b> bold, <i> italics
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.