Another good post, Dana. Paul Schott makes excellent points that can help guide an enterprise as it considers adopting open source. There?s only one thing missing: most enterprises are already using open source in one form or another, so in many ways that barn door is wide open. From Black Duck?s perspective, enterprise IT managers need to go one step further than Paul Schott suggests: they need to behave as though open source is already in use, and make sure they, and their developers, are playing by the rules. We would add a few points to Mr. Schott?s list:
1. Have a written OSS strategy and policy - develop a disciplined OSS policy and set of practices. Consider automating the use of OSS through the use of tools (like the Black Duck Suite) that identify OSS code and alert you to any license dependencies.
2. Integrate with other systems, especially build and change management tools -Integrating with your build system is a natural place to scan for third-party and OSS code and identify conflicts.
3. Check all possible sources for incoming OSS - Code can come from many sources - OSS forges, community projects, third-party developers/outsourcers. Your developers, external developers and contractors are part of your software supply chain. Create a best practice that describes how to manage inbound code, an institutionalized policy for managing third-party and OSS code, and a documented process that the entire organization can understand and support.
4. Drive efficiency by identifying and standardizing on OSS components- A lack of control in the development process can create duplication of effort. Standardize on an approved set of OSS components (e.g., Tomcat, log4j, zlib, etc.) by establishing a process and system for bringing in and evaluating components eliminates the need to test and get approval for the same components over and over.
5. Contribute back to avoid forking code - A big part of the OSS experience is giving back to the community. Some licenses explicitly state how code must be returned to the community. If your development plans include using OSS, it?s a good idea to think from the start about contributing code back including bug fixes. Not only will this help your organization eliminate the need to maintain your code as a separate fork, it?s a good example of cooperative development - and you?ll maintain a good working relationship with the community.
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
