Finally, when acquiring open source, you'll have to ensure that you have the appropriate procurement processes in place. If you're working with an open source vendor, you'll probably encounter a subscription model or an entitlement. If you're looking to significantly increase the use of open source in your enterprise over any period of time, you'll want to develop a contract process specifically designed to handle subscription-type acquisitions. Above all, remember that your worst enemy is a recurring "don't ask, don't tell" situation where developers assume that using a minor open source component doesn't require approval. Sweeping the acquisition of open source under the table to speed development will impede overall knowledge of what your organization is using and how best to leverage your open source tools.

Tips & Tricks for Governing Open Source Software
Creating an open source policy to manage risk and govern the use of open source doesn't have to be difficult. With a few tips and tricks for dealing with the main concerns around open source adoption, you'll be able to reap the benefits of an efficient, scalable open source policy that gives you security and confidence in your software.

You can't manage what you can't measure
Though open source can have a rogue reputation, the first thing to recognize when beginning to create a policy for open source governance is that you're probably already using open source. Somehow, somewhere, there's open source installed in your company. However, you can't manage it if you don't know it. If you're not exactly sure what open source software is installed and in production, start by taking an inventory to identify and list all the open source you have deployed. Today, you can even find free tools to scan multiple computers for open source components and provide an inventory of what's installed across your systems. Once you get a comprehensive picture of what your organization is using, you'll be able to analyze how you're currently governing and managing it. Then you can build from there.

Think about mitigating, not eliminating risk
Every business decision you make has risk associated with it. Just as with traditional proprietary software, you shouldn't expect to eliminate all the risk associated with open source software. Instead you need to evaluate the level of risk you're already exposed to and the level you're willing to be exposed to. Instead of throwing up your hands, make informed choices about acquiring open source based on a risk assessment.

Open source governance isn't "once and done"
Like any compliance program, open source governance isn't "once and done." Once you've identified and inventoried the open source installed on your system, keep up-to-date audits for posterity as well as upper management. Your open source policy will also have to evolve over time, so build in the appropriate processes for doing so.

Writing an Effective Policy
Once you understand how you're using open source, you're ready to begin writing an efficient and clear policy. Here are some easy-to-follow steps in drafting a policy to govern the use of open source in your organization.
1.  Define objectives and strategy
Your best approach is a pragmatic one. Sit down and ask yourself: What are the legitimate concerns here? What are my organization's goals? Where do these intersect? From the answers to these questions, you can develop specific procedures and controls that are case-specific. Keep all guidelines consistent and simple to foster compliance and to reduce instances of unintentional divergence.

When communicating your policy don't be afraid to focus on the bottom line. IT teams need to know that business goals aren't only driving development but your open source policy as well. Build your policy to fit the best interests of every stakeholder including all practitioners and influencers.

2.  Divide policy into three distinct areas
The policies you'll need to create should address three distinct areas:

• The acquisition of open source,
• Governing what you'll do with open source technologies in your organization, and
• The rules by which you'll interact with the community.

Acquiring Open Source
You need to determine guidelines for how you'll review and adopt open source software and then apply these rules to your whole organization. Find the balance between too much control and too little control. For example, your policy might allow developers to freely download open source software for evaluation and experimentation, but require approval at the time when it's chosen for use in a production application.

As part of your policy, you'll have to build in an approval process for using open source technologies in the applications you're building. Whether it's centralized or decentralized, keep in mind that this process has to be scalable - so design the process with efficiency in mind. Whenever possible, make it easy to reuse previous decisions such as "open source package A is approved for use in software that will not be distributed."

Using Open Source
You must also decide how open source will be used in your organization. Determine guidelines for the level of risk you're willing to carry and decide under what circumstances developers are allowed to change and modify source code. You also need to put audit and compliance processes in place to ensure that the approval process is being followed and that you're complying with the terms of the open source license.

Interact with the Community
Ask yourself how your business, as a brand, will converse with the community: will you be active forum participants, contributors, evangelists? Not all organizations interact publicly with the community surrounding a project, so if you decide to become a contributor, make sure your development teams know what can be shared and how you'll structure your contributions. You should also build a base of ready responses to common situations and make sure that all levels of your organization are on the same page when it comes to community attitude and interaction.

3.  Describe behavior to guide behavior
The best policy is one that continues to take feedback into account from enterprise developers, as well as the changing legal landscape of open source software. Your policy should ultimately describe what kind of behavior is necessary in response to the open source technologies you're adopting and should align with an overarching organizational stance with regard to risk and a standard value system around software.

4.  Are you using Linux?
If you've deployed Linux in your company, what kind of infrastructure exists around it? Can all or part of that policy be expanded to open source? This is a fairly classic example of how many companies come to find Linux as the gateway to tens of thousands of stable open source projects, and then begin to structure their use of open source around their Linux policy.

5.  Bring in the lawyers
You will need legal advice throughout the creation and implementation of your open source policy so don't be shy about calling on legal counsel. If you have a bunch of developers writing a policy, when you actually go to enact it, you'll find lawyers knocking down your door with red flags. Avoid this heartache and unexpected legal fees by getting lawyers engaged early and often. Make sure open source policies are based on specific license types and versions and do your research to see what common legal problems have surfaced in the past. If you can anticipate the roadblocks you might potentially encounter, you'll be prepared to write a policy to address issues before they arise and will have a much better outcome.

6.  Don't hide your policy
Once you've poured your sweat and tears into creating an open source policy, shout it from the rooftops! Well, maybe not literally. But do make sure that your policy isn't collecting dust and cobwebs in some dark corner of the office. One of the most important things about creating a policy is identifying a central repository for all of the knowledge and information you gather. If your policy isn't easily accessible, it won't empower the individuals who are looking to adopt open source. This might actually impede open source adoption and you might find yourself reinventing the wheel down the road as similar issues arise over and over in the absence of a marked policy to guide development.

7.  Software is software
As mentioned above, software is software. You'll save time by creating an open source policy that mirrors whatever guidelines are already in place for reviewing, managing and governing proprietary software. By measuring open and closed source solutions with similar metrics, you'll maintain consistency in your overarching software policy. In addition, keeping the same management team and review boards for both open and closed source solutions will save you the time required to coordinate guidelines between two separate governance silos. Depending on your level of open source use, you may be able to simply add an extra layer of rules and guidelines to your existing proprietary software policy for open source cases. With a little time and patience, your policy will hopefully evolve into a nicely branded "software policy" for all kinds of source code, but with an addendum for anything that's unique around open source.

8.  When in doubt, find or create a library
One of the top challenges to evaluating open source in the enterprise is ensuring that the code is coming from a trusted, stable source. In other words, browsing the 153,000 registered projects among over 1.6 million registered users on Sourceforge.net can be intimidating and overwhelming. Don't fret. By implementing a central library or repository of vetted open source projects, you can immediately reduce risk and rest assured that you're shopping mature, tested, and proven open source code. You can subscribe to a repository from an open source solution provider or start one from scratch. Your repository should contain open source that's pre-screened, supported, and certified for use in your enterprise.

Clearly communicate with your development teams so they know how to access your open source repository, and ensure that the repository holds relevant information about licensing agreements, support options, and approval status. Implementing a central repository will ultimately speed development and help you avoid legal problems.

Conclusion
Creating a policy for governing open source in your business requires diligence, hard work, communication, and ongoing maintenance. Once you've developed an effective, scalable policy, you can incorporate it into your daily development and management practices, and then into your company culture. Your policy will determine how your business as a "brand" adopts, uses, and contributes to projects and the larger open source movement and will establish lines of communication for constant feedback from programmers. Opening channels for feedback between business management and IT development teams will also keep open source use in line with business objectives and responsive to development goals.

At the end of the day, remember the amount of risk you carry depends not only on the presence of open source, but how well you understand and manage open source use in your business.