You know who loves open source software? Developers love open source software. Developers, and IT staff. If open source was a band, these guys would be the biggest fans. They've downloaded it, they've used it, they know it works — and they know it saves them loads of both time and money. They tend to use open source software whenever it makes sense to do so.
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.
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:
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:
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.
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.
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:
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:
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.
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.
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.
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 this 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.)
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.
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.
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.
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!
Allowed tags: <a> link, <b> bold, <i> italics