How to Convince Your Manager to Use Open Source Software

Developers and IT staff love open source software, but when they try to use open source at work they often find that their manager, or their manager's manager, has a lot of concerns. In this article we'll outline strategies you can use to convince your manager to use open source software, along with tips on how to make those strategies effective.

1 2 Page 2
Page 2 of 2
  • 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.


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!

Stormy Peters is Executive Director of the GNOME Foundation and a passionate evangelist for open source software. She founded the Open Source Program Office at Hewlett-Packard and the Expert Community at OpenLogic, and she’s a frequent keynote speaker on business aspects of open source software at prominent conferences as well as for government organizations such as the United Nations and the European Union. Stormy has lived north of the Arctic Circle, traveled around the world solo, and—most impressively—taught classes to twenty-two eight year olds. She currently spends her spare time working with Kids on Computers, where she's helping to set up a computer lab in Mexico (using open source software, of course).

How to Convince Your Manager to Use Open Source Software originally appeared on Wazi, a website that provides in-depth articles on open source technologies, governance, and licensing. Wazi is a companion web site to OpenLogic Exchange (OLEX), a Software-as-a-Service (SaaS) solution for comprehensive governance and provisioning of enterprise open source software.

OpenLogic is a leading provider of solutions that enable enterprises to safely acquire, support, and control open source software. OpenLogic provides a library of thousands of open source software packages, including hundreds that have been certified for use in the enterprise. OpenLogic also offers scanning and governance tools, license compliance solutions, indemnification, updates, and commercial-grade technical support for open source and CentOS Linux backed by the OpenLogic Expert Community. For more on OpenLogic, visit

Learn more about this topic

Best Practices for Creating an Open Source Policy

How to Convince Your Manager to Use Open Source Software

From Policy to Process: Best Practices for Creating an Open Source Governance Process

Selecting an Open Source Operating System

The Six Elements of Open Source Governance

Copyright © 2010 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
The 10 most powerful companies in enterprise networking 2022