Step Three:

Design and implement policies and processes that fit your organization

Companies using open source need to establish and communicate clear policies governing open source use and administration. These policies should strike a balance between the many benefits of using open source, while implementing a structured program to manage the risks and consequences of violating open source licenses. Policymakers should be familiar with the ethics and invention policies recommended by software engineering advocacy groups such as the ACM and IEEE.

A sufficient policy can be written in under five pages. Be sure it is consistent with the organization's employee handbook and pre-employment invention assignment and confidentiality agreements. Moreover, reduce reliance on written policies by automating the open source compliance policies as a business process, using an online compliance system. As well as controlling open source usage, a well-designed system can capture and preserve all open source project related data and provide current reports.

The compliance team should procure a developer training course and a self-test. An online version is recommended. Reward developers for supporting the compliance program. Reinforcing good behavior helps an organization mitigate potential risks.

Remember to establish rules for any developer contributions to open source projects. This applies to both outbound submissions by your developers, and in the case of open source projects sponsored by your organization, any inbound submissions you accept from open source developers outside your organization.

New products and productivity gains from developer ideas are the lifeblood of most organizations. Respect developer time. The best advice is to simplify and automate as much as possible. The compliance team should be facilitators of innovation and new products, not inhibitors.

When creating a governance strategy, don't simply accept a canned legal process from a third party service provider or law firm. Make it your own. Build it into the engineering SCM system. Use a developer-centric approach that includes issue identification and data presentation in formats that assist daily decision-makers inside and outside of the development group.

The compliance team should try to incorporate ongoing auditing in software build management process. Typical engineering practices include cascade, waterfall, agile, and scrum style development. Whichever form your organization uses, weave the audit tool into that development style and the existing release engineering process.

Software development involves extensive use of trial and error. By comparison to other disciplines such as chemistry where processes are quantifiable, software development is much more of an art than a science. Encourage rapid innovation cycles. Developer productivity is improved through independent and frequent release schedules. Consider lightweight toolsets including the many open source point tools available.

Strive to create open source policies that guide adoption and developer participation. Apply them to both proprietary and open source components. Remember, penalties for failure to abide by proprietary vendor licenses may be more onerous than open source license violations.

Organizations should create or buy an open source request and approval system that also serves as the system of record. It provides "one version of the truth" concerning open source project adoption, approval processes, target applications, licenses and developer actions. Don't focus solely on audit requirements. Include collaboration tools to document and share experiences and improve developer communication, morale and productivity. Business benefits of a capable request, approval and issue tracking system include:

• Open and effective framework for developers
• Reduced time in identifying and qualifying open source components
• Greater latitude in the number of components available to developers
• Faster product and service offerings to customers