But when open source fans try to use open source software at work they often find that their manager, or their manager’s manager, has a lot of concerns. After trying to battle them, they usually end up bringing in an outside expert to talk their manager into it; or they simply abandon their plan altogether.  It’s just too much work to convince management that it’s okay to use open source.

Now, we don’t want to point any fingers, but you know what often happens next. Authority is questioned, quiet revolutions happen and the next thing you know, open source software is being used — discreetly, unofficially — just to prove that it works! There’s got to be a better way. Well, fortunately there is. In this article we’ll outline some strategies you can use to convince your manager to use open source software, along with tips on how to make those strategies effective.

• Make sure you understand how proprietary software is acquired.
• Find out what your manager thinks about open source.
• Address all of management’s questions and concerns … preferably in advance.
• Bust the prevailing myths about open source software use.
• Create infrastructure.
• Take a shortcut or two (at your own risk!).
• Build your plan.

Make Sure You Understand How Proprietary Software is Acquired

Often, developers don’t really know how their company acquires software. They need something; so they tell their manager and a piece of software somehow gets purchased and shows up on their desk. (Or, probably more likely, they are told what software they need to use and they just download it from a central repository.) At most large companies, there’s a whole software procurement process. Many have tried simply adding open source software to the existing process.  Although open source doesn’t usually fit the existing  process perfectly, it’s best to try to use as much of that process as you can — while simply adding steps to address the issues that are unique to open source software.  So, while it’s unlikely that you’ll be able to fit open source software into your procurement process without making any changes at all, being able to discuss how you’ve addressed all the issues your company cares about concerning the procurement of software will certainly help your case. Examples of things that a procurement process normally covers are:

• Price. Both up front and on-going costs are at issue. This includes the price of acquiring the software, installing and integrating it, and providing maintenance and support. It’s best to address each of these potential costs, even if your company’s particular use of open source software may not involve them all.
• Source Code Escrow. The procurement process usually addresses what will happen if the software company goes out of business. Often there’s a clause stating that the customer will get a copy of the source code, along with the right to continue using the product. While this isn’t usually an issue for open source software, it is worth pointing out what you’ll do if your contract with a provider of open source software ends or if the company goes out of business.
• Support. Who is going to support this software? With the proprietary software procurement model, it’s often obvious who is responsible for support; which means this issue is really more about the terms of support: 24×7, work hours, numbers to call, etc.

Find Out What Your Manager Thinks about Open Source

Don’t assume that you know how your manager feels about open source software. There’s a chance they know all about open source software and use it all the time at home. There’s also a chance that they’ve fallen for every myth. Your manager:

• may be a big open source fan. In which case the problem may be your manager’s manager.
• may not know anything about open source software and be afraid to admit it. In this case, provide lots of information in a non-threatening way.
• may think open source is bad or threatening. Right or wrong, your manager may have already decided open source software is bad. If you can, try to figure out why they’ve reached this conclusion. Maybe someone they know has had a bad experience or maybe they read an article with misinformation.
• may believe every myth you’ve ever heard, and some you haven’t, about open source software. Be sure to address all the myths, not just the ones that are anti-open source. Addressing all of them, even the ones that would help your cause, makes you look knowledgeable (and impartial) about open source software — which will ultimately help your cause.

Outside sources can also be helpful in addressing management’s  concerns about using open source software. Depending on your manager’s learning style, you might point them to online resources like Wazi or to books like the Cathedral and the Bazaar (you can find a list of books here) or to conferences like OSBC.  You could even pull in an outside expert to speak to them — perhaps on the phone to start with.

Address Management’s Questions and Concerns… Preferably In Advance

If your manager (or their manager) is not familiar with open source software, they’re going to have a lot of questions. Be sure to anticipate and answer them before you make your proposal. Note that open source software is generally considered more secure than proprietary software for a number of reasons, including: many, many more people reviewing the code, many people testing and submitting bugs and more frequent releases to address any issues.

Here are some questions and concerns that managers often have about open source software.

Why Are These People Doing This for Free?

One of the things that often baffles management is why these people (i.e., developers) are working on open source software for free. They aren’t necessarily worried that you get what you pay for. They are more suspicious that developers may have ulterior motives and, without understanding those motives, they can’t evaluate whether or not open source software is free.

Open source software developers write open source software:

• to “scratch an itch”. The most common reason people start writing open source software is because they want something. For example, they want their screen to flash instead of beeping when they get new mail because they can’t hear or they spend lots of time in meetings. They want the weather to show up on their desktop. They want to be able to share their files with their friends.
• to fix a problem they’ve had or a problem they’ve seen. This is an extension of scratching your own itch. Once people discover they can solve their own problems and they release their software, they discover that others find the software useful as well, and will submit bug fixes and ideas for features.
• for recognition. One of the most powerful forces behind open source software is one that is often not recognized. Open source software is a meritocracy and individuals are recognized for the strength of their code. Being known as someone who writes good code and maintaining your reputation is a strong motivator.
• because they enjoy writing software. You may want to leave this reason out, as it’s really hard to convince people that don’t write software that it is true. People who write code really enjoy writing code. Coding is often not only fun but very addictive.

Where Does It Come From?

This is closely related to the “why do they write it” question, but with a slightly different spin. When a manager asks this, it’s like they’re saying: who are these people? The answer is, they are software developers. They’re professionals who write software for pay during the day, and write open source software during their free time or for their employer (see addiction & itch-scratching, above). You can find several studies with more information on the web, but here are some rough stats:

• 40% of open source software developers are paid to work on open source software. The rest are volunteers.
• It’s easy to tell if an open source software project relies mainly on the work of one company.
• Most open source software developers are men (less than 2% are women).
• Most have families and full time jobs.
• Most are employed as full time software developers.
• Open source developers are a very international group. (Red Hat recently created an open source activity map that shows where open source software developers live worldwide.)

There’s No Support

Support in the open source software world looks a little different than support in the world of  proprietary software. Naturally, this often leads people to conclude that there is no support for open source software. It’s not true! There are often even more support options for open source software than there are for proprietary— at least for the more popular projects. In the proprietary software world, it’s obvious that if you buy AIX from IBM, you are going to buy your support from IBM. In the open source software world, you may get Linux from a random website and then purchase support from any number of vendors.

It’s a Security Risk

Because open source software is written by individuals spread out across the world instead of by large companies, and because all of the source code is visible, people often initially assume that it’s a security risk. The open source community has successfully shown this isn’t true. Today open source software is viewed as at least as secure as proprietary software.

It’s a Legal Risk

There’s been a lot of fear created around open source software and legal risks. The truth is that any business action carries some legal risks. The legal risks of open source software are just different from the risks of using traditional proprietary software. A good policy can help address and mitigate the legal complications your company might face. See Best Practices for Creating an Open Source Policy for more information.

You’ll Give Away Our IP

Many people are very fearful of the copyleft nature of the GNU General Public License (GPL) under which a lot of open source is released. They are afraid that if they use GPL-licensed software, they will have to give away all of their software. Often they allow the use of open source software, with the exception of any licensed under the  GPL.  Clearly, if you want to make sure your company doesn’t prohibit software licensed under the GPL, you should address tis one early. There are many ways to make sure you don’t accidentally copyleft your software. They range from not copying any GPL-licensed software into your code base, to not linking to any GPL software from your code, to not distributing any GPL-licensed software (or anything derived from it.)

Bust Prevailing Myths

Here are some of the more common myths concerning open source software. Address both the “good” myths and the “bad” myths. It will help in the long run if your management really understands open source software.

• If you don’t modify the code, you’re good. Many companies believe that as long as they don’t modify the source code, they don’t have to worry about which license open source software has. Some even create a policy that prohibits the modification of open source code because then, they think, they are risk free. While modifying open source software may cause support problems, modifying code isn’t usually what triggers anything in the license.  For example, the GPL says that if you make modifications to the software, you have to distribute those modified source code files with your binaries.  But it’s the distribution that triggers that clause, not the modification.  So if you distributed the binaries unmodified, you’d have to distribute the source code.  And if you linked statically to those GPL-ed binaries, you’d have to distribute your source code as well — but only if you distributed your product.  If you’re just using it within your company, it really doesn’t matter whether you modified it or not — except from a support perspective.
• If you modify GPL code, you have to give the modifications back to the project. While it is smart to contribute your modifications upstream (i.e., back to the project), it’s not a requirement.  Under the GPL, you only have to give the modified source code to anyone to whom you distribute the binaries.  It’s smart to contribute your modifications back upstream because then you are using the standard product, not a special, forked version. If there are any problems, it’s much more likely someone else will also encounter them and a fix will be made quickly. It also makes upgrading to the next version much easier, and open source software projects typically release new versions often.
• Distributing GPL code under a non-disclosure agreement (NDA) doesn’t really count as distribution. Many attorneys believe that distributing GPL code under a NDA doesn’t really count as distribution.  Further, they think that the recipient can give that GPL product to anyone they want to — under the terms of the NDA — regardless of what the NDA actually says. Unless you’re comfortable releasing your software under the GPL license, don’t release code linked with GPL code under non-disclosure.
• If you are only using open source software internally, you don’t have to worry. Actually, you probably do need to worry a little. First, you should remember that software rarely stays internal. It’s almost always shared with a partner or vendor, or a company is acquired or sold.  Second, many licenses have clauses that are triggered by something other than distribution.  Sometimes they’re simple, and sometimes they aren’t.  For example, one license says that you have to buy a copy of the developer’s book for every developer on your team, regardless of whether you redistribute or not. Another license says you have to buy the developer a beer if you see him at a conference. These may seem like trivial clauses to you, but company attorneys are paid to worry about things like whether or not every employee will even recognize the developer at a conference, let alone buy him a beer.
• Anybody can sue me for the misuse of open source software. Only the person who owns the copyright for a piece of software can sue you for violating the license.  Typically, the person who owns the copyright is also the person who wrote the code.  They can, however, give that copyright away.  They can even give it away and keep it for themselves — so now two people hold the copyright.  The copyright holder is also the only person who can change the license on a piece of software.  This is why SCO lost their lawsuit.  (SCO sued IBM for allegedly contributing SCO intellectual property to Linux, but in the end the court ruled that SCO didn’t hold the Unix copyright, so it couldn’t have been their intellectual property.)
• There is no support for open source. First off, lots and lots of products are open source.  The support options vary widely, from the do-it-yourself variety to multiple companies competing for your business.  (OpenLogic offers open source support for hundreds of different software packages.) The challenge is that you sometimes have to do a lot of research — a product’s name doesn’t necessarily give you a direct clue to the company that supports it; or you might come up with more than one name and have to compare several companies.  Regardless, there are lots of companies and individuals out there supporting open source software.
• Freeware and shareware are open source. Freeware and shareware are not open source.  All things free are not open source.  Just because it’s free, doesn’t mean it’s open source. (There, we’ve said it three times now, in three different ways.) The freeware and shareware licenses are very different, and they do not meet any of the traditional open source guidelines around things like providing source code, allowing modification, and redistribution.

Create Infrastructure

Many companies decide they need an open source policy and an open source governance process before they use open source software, but then stall in the process of deciding how to create that infrastructure. It may help you to have a preliminary draft of an open source software policy and governance process that is specific to your company’s needs. The danger is that if you make it available, your project may be stalled until the policy and process are approved. On the other hand, showing that you’ve not only thought about the policy but have created a draft based on research might help show that you understand the risks and benefits of open source software. It could be a relief to your management.

If you do decide to create a policy and governance process, check out these guides to writing an open source software policy and creating an open source governance process.

Useful Shortcuts

1. Bring in an outside expert. Often it’s just easier to trust an outside expert. Remember when you were a kid and your mom wouldn’t believe you, but she believed the neighbor? It’s the same here. If you do bring in an outside consultant, make sure you work with them closely and help them understand your company’s internal situation as well as what you are trying to accomplish.
2. Just do it. Ask for forgiveness instead of permission. Do this one at your own risk! Sometimes it works to just use open source software and then show that it’s been working for a while, saving you time and money, and nothing disastrous has happened. Be sure you can show that you’ve considered all the risks, addressed all the issues, created an informal policy, etc.
3. Have a fire. There’s nothing like creating change in an organization like finding a problem that can only be fixed in time … with open source!

The Plan

As promised, here’s a plan you can use to convince your management that it’s in your company’s best interest to use open source software. You’ll have to do quite a bit of preparation work, but in the end it’ll be worth it because of the time and money your company will save by using the open source software solutions you’ve found in a way that minimizes the risks.

1. Know what software you want to use.
2. Make sure it works well. Know it.
3. Figure out how to address all the points that your company normally would in acquisition.
4. Know where your management is concerning their knowledge of, and beliefs about, open source; and know how to address all of their concerns and perceived risks.
5. Put together a document that:
   1. States the problem you are trying to solve.
   2. Describes the software you want to use.
   3. States plan for transition, support, etc.
   4. Addresses risks.

Conclusion

If your manager is already an open source fan, then convincing her to use open source software might be really easy, and the two of you will be able to focus on building the plan and creating the infrastructure to use open source software effectively. If your manager is not familiar with open source software or has an active fear of the risks associated with it, it might take you a little longer. But you’re not alone! Many open source fans have successfully used the strategies in this article to bring open source software into their companies in a way that saved their companies time and money — improving their businesses. If you are one of those people, please share any additional tips or suggestions you have in the comments!

Best of luck to all you open source fans!

Why do you need an open source software policy?

At first many companies question the need for an open source software policy—primarily because they think it will be too difficult to create. Policy creation does require a lot of work and cooperation, but by following this guide you should be able to create and roll out an open source software policy in less than a month.

Some of the main benefits to having an open source software policy include:

• Ensuring the company is in agreement about how to use open source software. Companies often start drafting an open source policy when somebody in management realizes they don’t know how much their IT department or software products depend on open source software. A clearly-stated policy can help ensure that everyone in the company is on board with your open source strategy and that employees feel like they’re empowered to use open source software where appropriate.
• Maximizing the benefit of open source software. By creating a policy, you will put processes in place that will enable employees to use open source software effectively as well as share knowledge and workload between teams. For example, three different teams won’t independently figure out how to get support for the same project, and different employees won’t independently evaluate the same upgrade. Having an open source software policy and sharing information across the enterprise will enable your company to maximize the benefits of the open source software it uses.
• Minimizing the legal, technical, and business risks of using open source software. Executive management and attorneys are often very concerned about being sued for using open source software, getting caught without sufficient technical support, or receiving bad publicity related to how open source software is used. An open source software policy can not only minimize those risks but also show concerned employees how the company is addressing those needs.

The process of writing an open source policy

The key to writing an open source software policy is just to get started! Companies typically either write, approve, and adopt an open source software policy within a month, or else they spend months working on a policy and yet fail to gain company-wide approval on the finished product. By following these steps you can ensure your company has an approved and adopted policy within a few weeks:

• Identify key stakeholders
• Get stakeholders to buy into the concept of a policy
• Figure out your company’s strategy
• Create the first draft of the policy
• Get widespread review and acceptance, starting with your stakeholders
• Repeat last two steps as necessary

Stakeholders

Your first step—the one important to making sure that your policy is adopted—is to identify the stakeholders in your policy. There are several types, ranging from those who care desperately because you might change their ability to do their job (like developers) to those who care desperately because they think a bad policy might get them fired (like CIOs and those who report to them.) Be sure to include people who you think will disagree with your policy—better to address their disagreements upfront than to have them fight the policy because they don’t like one part of it.

While you’ll have to use whatever strategies work best in your organization, getting all of the stakeholders involved as soon as possible will help your policy get widely adopted more quickly. The more your stakeholders feel like it’s their policy, the better. The best case scenario is if they can say they reviewed it and feel comfortable with you (or whoever is writing the policy) taking care of the details.

As you put together your list of stakeholders you should consider:

• Developers—the people who will have to follow the policy
• IT staff, as they probably download and use open source software
• Managers of teams that use open source software
• Attorneys
• CIO and staff
• Technical architects; many companies have architectural committees, and they should be involved

You’ll probably have two groups of stakeholders: the key stakeholders who will need to approve the policy, and the people who will be affected by the policy.

Strategy

An open source software policy is meant to help your company’s strategy—both its general strategy and its open source strategy.

For example, you might see open source software as a way to reduce your IT costs. In this case your strategy should not be to “use as much open source software as possible,” but rather to “reduce IT costs by using open source software.” This will enable all of your employees to make the right decision when it comes to choosing between open source and proprietary solutions. The policy will then help your company reduce IT costs—not just by encouraging the use of open source software that has no licensing fees associated with it, but by also leveraging the preexisting open source knowledge of your IT staff.

On the other hand, you might want to build an online community around your company’s product. In this case your strategy might be to use open source software in order to encourage outside developers to help build out features that enable your community to grow. Your interest is in the community, not in making money through software sales, so you might even want to open source your own software and grow a community around it.

Identifying your open source strategy upfront will not only help you figure out your policy, but it will also help you explain to others why it’s the right policy for your company.

Here’s an example of what an open source strategy statement might look like:

Background Statement

Many open source software policies start by talking about the problem they’re trying to solve. Whether or not you need this section probably depends on your company. You may need this section if:

• Management doesn’t know how much open source software the company uses or depends on.
• There are widely varying opinions on how much open source software is used.
• There’s an open source software rule or policy that conflicts with reality (e.g., “No open source allowed,” but your IT infrastructure is built upon open source software).
• There are big disagreements on how the company should use open source software.

If you decide you need a background statement, make it brief. Some key things to include in the background statement (if you know them) are:

• How much open source software the company currently uses.
• How much open source software has or will save you—not just monetary savings, but also consider reductions in development time, consulting time, learning curves, and so on.
• Any risks to be aware of—for example, your 24×7 website depends on an open source software package for which there is currently no defined support process.

A background statement in an open source policy might look like this:

Scope

Your company may have many policies, and it may be obvious who they cover. However, with open source software policies it is often necessary to define not only who is covered but what is covered.

Who’s Covered

Most companies with an open source software policy adopt the policy company-wide. However, for many organizations it makes more sense to have a very brief company policy that simply states the strategy and provides some general guidelines for how to use open source software. Then, each division is allowed to elaborate and expand on the policy to meet its needs. In other cases, a particular division creates a policy and later tries to get the company as a whole to adopt it.

Don’t forget to specify subsidiaries and agents in this definition. You might want to consult with an attorney about whether giving open source software to the company’s agents or subsidiaries is considered distribution, as distribution triggers clauses in some open source software licenses.

Also, you might want to specify whether or not the open source software policy applies to everyone or just to employees in certain jobs or roles. For example, you may not care how your IT staff uses open source software in the internal IT environment, but you want to ensure that all software developers working on applications that are distributed to others are aware of the open source software policy.

Whatever you decide, make sure it’s clearly stated and that you have the right people review and approve the policy. The example below illustrates one approach to defining who’s covered by a policy:

What’s Covered

There’s a lot of misunderstanding and disagreement about what exactly qualifies as “open source software.” One common misconception is that freeware, free to use, and free for personal use only licenses are open source software licenses.

Companies typically decide that any software released under a license approved by the Open Source Initiative (OSI) is considered open source software.

You need to define what is covered and what is not covered by your company’s open source software policy. Many companies have different standards for open source software used in IT, development, and production environments.

You’ll also need to think about what qualifies as open source software and what usage cases need to be covered.

• Does the policy apply to using software inside the company?
• Does it apply to shipping software?
• To freeware? People often assume anything that doesn’t cost money is open source software—that’s not true, and you need to explicitly include or exclude that type of software.

An open source policy might address the issue of what qualifies as open source with language like this:

Ownership

Your open source software policy will be a living document. As business conditions change, your company becomes more comfortable using open source software, and new open source software packages and licenses become available, you’ll want to adapt the policy to the new situations. In addition, an individual or team needs to be available to answer questions, provide training, and approve any exceptions.

Although an individual usually writes the open source software policy, a committee or open source review board should own the policy. A review board is most effective when it represents the main divisions in the company. If every group feels like they’re adequately represented, you’ll get better buy-in and compliance later on.

When to Make Exceptions and Who’s Allowed to Make Them

Only a couple of people should be allowed to make exceptions to the open source software policy: the owners of the policy, and the business group or manager who’s allowed to decide that the business benefit outweighs the risk of breaking from the policy.

Approval Process

While it’s easier create an open source software policy before establishing an approval process, in reality the opposite usually occurs. Someone is responsible for making open source decisions, and he or she ends up pulling together a group of people to create an informal approval process. Once established, even informal approval processes can become quite elaborate and efficient.

If you don’t have an approval process, you’ll want to sent one up. If you have one, you’ll need to review it with your open source policy in mind.

Who’s Part of the Open Source Review Process?

You may want to establish a cross-divisional open source review board. This is usually the same team that owns the open source software policy. It should definitely include an attorney or work closely with one.

You’ll also want the review board to include any teams that will use approved open source software, as it’s important that they agree with the policy as well as the process. They can give you feedback to make sure the process integrates smoothly with their work flow so that reviews happen quickly and issues are resolved smoothly.

What Information Should Be Reviewed?

Decide what information should be included in the review process. At a minimum you’ll want each open source usage request to include:

1. Name of the employee submitting the request.
2. Name and version number of the requested open source software package.
3. Source of the software (website from which it was downloaded).
4. List of the licenses associated with the software and any bundled components.
5. Business reason for the request.
6. Platform on which the software will be installed.
7. Plan for integrating the open source software into other software currently being used or produced.
8. Whether or not there are plans to modify the source code (Y/N). If yes, explain the reason for modification.
9. Whether or not there are plans to distribute the open source software, either modified or not (Y/N). If yes, explain the reason for distribution.
10. Plan for supporting the software, monitoring for security updates, and performing upgrades.

Next, decide on the process for reviewing requests. You’ll probably save a lot of unnecessary reviews by asking local management and attorneys to review requests before they’re escalated to the corporate open source review board.

Best practices for open source approval processes include:

• Ensure quick turn-around on all requests. If the approval process takes weeks, developers will skip it because they need to download open source software and get their job done. Your approval process should take one or two weeks at most.
• Ensure all review board members are committed to the process. You should be prepared to replace people as the original members move onto other interests or discover they don’t have enough time anymore.
• Have a really good “pre-approved open source list”. You can pre-approved by license, package name, and/or usage models.
• Get lots of attorneys involved. While there may be an attorney on the review board, it will help if you have attorneys close to the team involved. They will best be able to understand how the open source software will be used, and they can help field questions. Educate these attorneys over time.
• Create an exception process, but do your best to set it up in a way that minimizes the use of exceptions.
• Make public within your organization all open source requests as well as the review board results. If people can see what has been requested and why certain packages were approved or denied they can tailor their requests appropriately, saving you a lot of time.
• Define some standard business reasons for your organization. Depending on your open source strategy these could vary from “saving time by using existing technology” to “saving money by eliminating licensing fees” to “getting buy-in from technical adopters by enabling them to see how product is developed.”

Audits

Although your policy can require all open source software be reviewed and approved through a defined process, it’s impossible to enforce by brute force—open source software can easily and freely be downloaded from the Internet. In order to make sure your approval process is effective and that employees are following it, you’ll need to define an audit process.

The flowchart below illustrates a typical open source audit process:

Sourcing

Your policy should explicitly state the websites and methods through which employees are allowed to obtain open source software (sourcing) and how to decide whether a particular open source package is the right piece of software for the job (selection). Who can download software? Where can they go to download it? Do they need permission before downloading? Before using? Before distributing?

Many companies allow developers to download software and try it before going through the approval process. Attorneys are often uncomfortable with this because employees can use the software before the license is reviewed. However, businesses typically balance this concern with the fact that the risk is relatively small while the developer is just evaluating the software.

Most companies end up adopting a free-for-all open source download and maintenance program—every team that needs an open source software package is permitted to download it and figure out their own support options. This is highly inefficient and often leads to the situation where a company is using many different versions of the same software package as well as duplicating evaluation and upgrade processes every time a new version is released.

Other companies have adopted the idea of an open source repository in which approved open source packages are stored. Employees who need to use open source software are required to download it from the repository instead of the Internet. While an excellent idea, this approach often leads to failure because it’s difficult for a single company that’s not in the open source software business to create and maintain a comprehensive open source repository. The repository often ends up outdated and missing many useful open source software packages. If you go with this approach, you’ll need a very good process for handling requests to add new open source packages or versions to the repository. Alternatively, you can use an open source repository provided by a third-party, like OpenLogic Exchange (OLEX) from OpenLogic.

A policy that defines how and where employees can obtain open source software might look like this:

Alternatively, your policy can allow employees to make a judgment call when it comes to sourcing:

Note that while many attorneys recommend that no software be downloaded until the license is reviewed and approved, this is rarely followed. Your policy needs to take into account the legal risk of downloading software for testing or trial purposes before attorneys have a chance to review it. Adding a clause like this can help mitigate the risk:

Selection

Selection is the process of deciding whether or not a particular software package meets your needs and quality standards. In addition to any testing and standards processes already have in place, you might want to consider additional aspects for reviewing open source software such as:

• Support: There are options for support for open source software, but which options are available and which you should choose may vary from package to package.
• Community: Is there an active open source community for the package? Are bugs fixed quickly?
• Quality: Is the software package reliable? How does it compare to similar open source packages?

For a list of other factors to consider around open source package selection, see the OpenLogic Certification Process white paper.

A policy might approach the issue of open source selection with language like this:

Your policy may also outline what to do in case an open source project “ends” or forks. For example, the policy might define a timeframe in which the team has to find a different open source package to replace the original package:

Mergers and Acquisitions

Don’t forget to include a section in your policy about mergers and acquisitions. Enterprises often fail to investigate open source usage or policy until after a target company has been acquired. It makes much more sense to check beforehand. You’ll need to make sure your company’s mergers and acquisitions team is aware of the internal open source policy as well as the need to investigate open source policy and usage at target companies prior to completing any acquisitions. Open source tools such as FOSSology, OSS Discovery, and OSS Deep Discovery can be run to identify the open source software deployed within a target organization.

A policy might approach the issue of mergers and acquisitions with language like this:

Support

Technical support in the open source world has a bad reputation. While many people think there’s no support available for open source software, the real problem is that there are too many choices for open source software support—and few of them resemble what people are used to in the proprietary world.

Options vary from do-it-yourself (by following mailing lists and even fixing critical bugs yourself) to paying a third party for a complete support and maintenance contract. The table below shows some of the common options:

An open source policy might address the issue of technical support with language like this:

Maintenance

Once the decision to use open source has been made, the process of downloading it and getting it to work is often challenging and satisfying. However, it can be frustrating to track the project for security updates, solve problems, and figure out when to upgrade to a new version.

Your open source policy should provide guidance on maintenance concerns by addressing the following issues:

• Security updates: Who’s going to be responsible for staying abreast of security updates? This often requires subscribing to a mailing list.
• New versions: Who’s going to figure out when you should upgrade to a new version? Deciding when to upgrade can be hard because open source software projects release new versions often. While some projects are very good about specifying what’s new, what’s changed, and what’s gone, others are not. Someone will have to evaluate each release and decide whether or not to upgrade. In addition, you’ll need a process to ensure that only one or two versions (or as few as possible) are deployed within the company. In particular, you’ll want to ensure the company doesn’t fall too far behind the latest version available from the open source project, as communities rarely support previous versions for long.
• Bugs: When a bug is discovered, what’s the process for reporting it to the open source project? Your policy should also specify when and how employees can fix bugs and submit bug fixes to open source projects. (You may want to provide some training about how best to create and provide patches, as it’s in your best interest to make sure patches are accepted upstream.)

The maintenance section of your open source policy should specify whether or not company employees can modify open source software. While you’ll probably want to encourage people to not modify open source software (unless they are planning on fixing a bug or adding a new feature to contribute upstream), it’s likely that some packages will require modifications to work in your environment or process. Your policy should specify when that’s allowed and how changes are documented for maintenance.

An open source policy might address the issue of ongoing maintenance with language like this:

Contributions

Your open source policy should include a clear statement about whether or not employees can contribute code changes to open source software projects. There are several situations in which you’ll probably will want employees to contribute. For example, if an employee fixes a bug, you’ll want him or her to contribute the patch to the project so that you don’t have to maintain a unique patch through every version upgrade. In addition, by contributing code your company might gain credibility within the open source community. If your company actively contributes to a project, the community will be be more likely to recognize employees and quickly respond to their emails when issues arise.

Situations to consider when thinking about whether employees can contribute code changes to open source software projects include:

• Can employees post questions and answers on mailing lists? While many companies are afraid of what employees may accidentally reveal on mailing lists, it’s best to give them the proper training on confidentiality and then let them work on mailing lists. Not only will they build credibility for themselves and the company, but it’s often one of the best ways to get help with a problem. Disallowing employee contributions on mailing lists will impede employees’ ability to use and support open source software solutions.
• Can employees post bug reports to the bug tracking system? Unless there are very good business reasons not to, you should allow employees to post bug reports in order to ensure they can be fixed in a timely manner that will work for the company.
• Can employees fix bugs and submit their patches? Employees often need to fix simple bugs in order to get things up and running. When they do, it’s in the company’s best interest to ensure the bug is fixed in a general way that’s acceptable to the project so it can be submitted upstream. This will simplify support over the long term and help build credibility for the company.
• Can employees contribute features to an open source project? Can they become project contributors?
• Can employees work on open source software projects in their free time? On the same project(s) they work on in the office? On unrelated projects? How do you decide if a project is unrelated to the company’s business?

An open source policy might address the issue of open source contributions with language like this:

Some open source policies state that employees can only interact with open source communities using personal email addresses, not company email addresses. Note that if you include this rule in your open source policy, your company will never develop any credibility with the community.

Communication

Although many companies try to hide that fact that they use open source software, it rarely remains a secret—especially for organizations that decide to provide their own support using internal resources. It’s best to establish a policy for how employees should communicate with open source communities and other interested parties, even if you intend to limit communication about open source usage as much as possible.

Your open source policy should provide guidance on communication by addressing the following issues:

• How can employees communicate with open source software projects? (For more on this topic, see the Maintenance section above.)
• How can employees communicate about open source usage at conferences? Employees will likely want to attend open source software conferences, which provide an excellent opportunity to meet open source project maintainers. If employees can talk about which open source packages they’re using and even present case studies, it will help them meet the right people and gain credibility for your company. The open source software community likes hearing about how their products are being used.
• How can employees communicate about open source usage in documentation? If you ship products that contain open source software, you may have to display the open source software licenses in the product documentation (depending on the licenses). You might also want to say something to end users about what you’re using and why, depending on the type of end users. For example, if you sell TVs that use open source software you may need to display one or more licenses in order to comply with them, but you probably don’t need to spend a lot of time talking about the software installed on the TV. If, on the other hand, you distribute a toolkit for software developers, you’ll probably want to allow more space in your documentation for discussion about the open source software you’re using and why it’s part of the toolkit.

Summary

Be sure to remain positive in the summary of your open source policy—after all, you want your employees to want to follow the policy—while also clearly stating when and how open source software usage triggers review. For example, the summary section of a corporate open source policy might look like this: