The Six Elements of Open Source Governance

No kidding, we've boiled it down to six - Six Elements of Open Source Governance laid out and discussed right here. Everything you need to know in a few thousand printable, portable, highlightable words about open source policies, managing inventory, provisioning, scanning, reporting, and more.

There's a rumor going around that the be-all-end-all of open source governance is scanning. Scanning an effective CYA on governance? Bollocks, we say. One component, but not the whole story. Scanning will help you figure out what you've got, alright, but then what? How do you know if what you've got and what you're doing with it are copacetic without a policy or two? And once you've done the work of figuring out what you've got, how you're using it, and you've got those policies in place, how do you keep that information current?

Each of these questions scratches the surface of concerns we think are urgent, and they're not addressed by scanning alone.

The rumor mongers have an agenda, and you'd be right to suspect that we do, too. We are, after all, the company behind OpenLogic Exchange (OLEX), which comes in an Enterprise Edition that's designed to cover all the bases of open source governance. However, rest assured that the point of this article is not to push our solution so much as to share the thinking behind our solution. If you can put together another stack that covers the bases we lay out for you here, more power to you.

Governance of Open Source in the Enterprise - Six Elements

What you really want is open source governance that's so easy you (and your users) will barely know it's there. We've done this a gazillion times, and we've boiled it down to Six Elements:

  1. Policies - First, decide what Is OK and what Is Not OK
  2. Inventory - Figure out what you got
  3. Provisioning - Figure out how you're gonna get more...
  4. Managing - ...while following the rules from #1
  5. Auditing - Circle back and confirm that everything's still going ok
  6. Reporting - Gift-wrap that "OK" to show you care (and give them sparkle for the board slides)

Approach these elements roughly as steps and they'll lead you through a set of exercises that determine comfort level and current usage, establish monitoring and control of what's used and where going forward, and result in the creation of a sustainable system going forward.

You'll notice 'scanning' is not mentioned at all here. That's because we believe scanning is a means, not an end.


Scan to your heart's content, but unless you've got a policy or policies in place, how in the world do you know if the open source you find in use in your enterprise is "okay", or not? What's "okay"?

To answer that question, you need to know some stuff, and then you need to create an open source policy. The questions below include the basic questions you and your organization need to be able to answer. A comprehensive open source policy includes bits of items #2 through #6 in this list, and we'll get you more detail on each of those later.

1. Legal Stuff: How and why are you using open source software? Policies should reflect a broader strategy — do you have one? Has your legal team vetted open source licenses? Which open sources licenses are considered enterprise friendly for your use case? Are different licenses acceptable for open source packages that are used in-house versus packages that are embedded in distributed products (e.g., products given to partners or offered for sale)? Distribution is the key concept here, as many open source licenses contain special clauses invoked only in situations where code is distributed downstream.

2. Getting It: How is open source currently evaluated and approved in your organization? Where do users get the source once a package has been approved for use? Is there an open source review board that defines the request and approval process, or are requests submitted to department managers, each with a different review process and risk tolerance threshold? Is there a repository where users can find and download approved packages, or do employees download open source from the Internet whenever they want? Where is all this usage information tracked? Who is the responsible party within the organization? The goal of these questions is to determine what the standards are across the enterprise. Key to governance is ensuring that users all follow same process by making it policy.

3. Using It: Are employees allowed to modify open source code, and can they contribute code changes back to open source communities? If code contributions are allowed, can employees use company email addresses when posting changes? Are employees allowed to participate in online discussions using their corporate email address? How do any of these policies apply to contractors, offshore resources, or partners?

4. Updating It: What are the guidelines for managing version updates? Open source projects typically release more often than commercial software companies, and most CIOs don't want 30 different versions of a particular package deployed throughout the enterprise. Do new version releases need to go back through the evaluation and approval process before they can be deployed? Version upgrades are often necessary for security reasons, but multiple versions can also present problems when it comes to support. Which brings us to...

5. Supporting It: Is open source support required for some of the packages you use, all packages, or just specific ones? Can employees get support from the open source community mailing lists, and, if so, can they post questions using company email addresses? Or do some/all/specific packages require commercial-grade technical support (which, by the way, you can get from OpenLogic — just an FYI because, seriously, we're in this for money as well as the glory).

6. Communicating: How does the organization track and audit all of the above (or at least the most relevant parts), and how are results reported? Also, how often are audits conducted, and who's responsible for auditing and reporting? How does your policy apply to software already in use vs. software currently in development?

Not to toot our own horn, but we know a thing or two about this stuff. We've been teaching Fortune 500 companies how to realize the benefits of open source software for ten years. We offer open source policy workshops as well as one-on-one guidance for organizations looking to create or improve their open source policy. We also help organizations evaluate and select the open source packages that best fit their needs. Just sayin'.

Ok, so once you've got your policies in place, it's time for a scan.


All an inventory does is tell you open source software you got, and where you are using it.

Not to get all existential on you, but before you go crazy with an inventory, we suggest you first ask WHY. Why do you, X guy at Y company, why do YOU want or need an inventory of your open source? Here are some of the reasons we've heard in our work:

  • kickstart an open source policy
  • establish a baseline for ongoing auditing efforts
  • plan for support
  • manage security updates
  • manage risk
  • prepare to distribute, divest, or donate software
  • prepare for a merger or acquisition
  • comply with internal policies
  • comply with regulations
  • comply with open source licenses
  • manage intellectual property issues

The significance of these issues is weighted differently if the open source is intended for use internally, or it will be distributed. For example, your company may not have to worry too much about "intellectual property" issues if you only use open source internally. Generally speaking, it's more important to scan for licenses or code snippets when it comes to open source that is distributed outside the enterprise, and concerns around technical support are more relevant to scanning for open source software used internally.

WHY simplifies HOW. There are two main approaches to how: ask people or scan. Asking people to tell you which open source packages, licenses, and/or code snippets they've got in use has obvious limitations. Scanning tools are more reliable, but there are a bunch of options available with varying levels of cost and complexity. With your "why" information in hand, you can select the scanning tools that give you the information you need that fit in the context of the resources (both time and dollars) you've got. There are several open source scanning tools you can use, but the options listed below are usually a good place to start if you are just a normal user of open source — since you can't beat the price (FREE).

  • To scan for installed open source packages on a server or desktop, your best option is to go with OSS Discovery, a scanning application developed by OpenLogic that is both free and open source. OSS Discovery will tell you what's installed on your machines, or what libraries your application is composed of, and it's easy to download and run. OpenLogic also offers a free open source inventory analysis for up to 500 systems using OSS Discovery. Relatively painless.
  • To scan for open source licenses, you might want to try a solution like HP's FOSSology. FOSSology finds open source licenses in source code or binaries and it's a free and open source application. The learning curve on this one is a little high, but still well below planetary physics.

If you're part of a software company or a company that distributes hardware that contains open source software, you may want to consider shelling out the bucks for a proprietary scanning tool. Keep in mind, though, that this option will also require some expert analysts to run the tools and sort through the results, so make sure you've got that in your budget.

The important thing when picking a scanning solution is to start by defining your scanning goals. Once you do that, you can pick the right level of scanning that meets your needs. Be selective and avoid overkill, yet ensure you've covered all your bases — it's quite possible that you could end up using different scanning tools to create the result desired in different realms of the organization. Also, keep in mind that creating an inventory won't be a one time activity. Depending on your goals, you'll want to inventory again in the future — for example when putting a new application into production or releasing a new product.

Next, you'll want a place to report on and store your inventory results. You'll also want to compare your inventory against your policy in order to see where you might have, let's say, "circumvented" the policy. Once you've got your inventory cross-checked against your policies, you'll need to do a little remediation, but then you're caught up, up-to-date, and in the clear.

And what will you do with the results of cross-checking between policy and scan results? It would be best if there were a place to load the scan results that would log usage. If this place applied your policies, or checked against your policies and provided you a report on infractions, that would be best. A central open source governace tool, say for instance OLEX, might be a good option, but we'll get a little further into that in a minute.


As you're taking inventory of the open source you've already got, consider establishing a go-forward process that will govern the use of any new open source users need. Presuming you've taken our advice and put your policies in place, what you need now is a comprehensive repository of open source that's safe, secure, and ready for deployment in the enterprise.

Funnily enough, the OpenLogic Library of open source is just such a place. We provide a tidy one-stop-shop that's freely accessible through OpenLogic Exchange (OLEX). The OpenLogic Library offers the most extensive repository of enterprise-ready open source software on the planet. And "enterprise-ready" is not just marketing buzz in this case. If you download a "certified" open source package from the OpenLogic Library, you know that it has passed our 42-point certification process and meets basic standards of quality, usability, and community backing. OLEX provides you all the information you need to determine whether or not a package fits into your policies, and we also check daily for security issues and provide patches as they are released for all business-critical projects. When we find such an issue, we notify you via OpenUpdate — an HTML newsletter available to subscribers of OLEX Enterprise Edition. We also sell support on open source in case you find yourself needing such services.

1 2 Page 1
Page 1 of 2