Skipping open source at work: How to convince your boss

Jonathan Frappier Virtxpert

Recently, Pluralsight published a blog Going open source at work: How to convince your boss which covers aspects that might prevent users from adopting open source and provides reasons on how to help, well, convince your boss.  I couldn’t disagree more with the post.  That’s not to say however that open source might not be a good fit for your organization, but the points given are extremely one sided…as I seem to typically find with most open source proponents.

The first point the author makes is that linux is being used more and more and even uses Facebook as an example of companies using open source to run their business.  The biggest problem with this reference, and one so many business people bit on, is that your business is not Facebook, its not Google or Rackspace or any of the other companies making open source “sexy.”  Yes, open source IS the right answer at companies like that, companies that have budgets to dedicate engineering teams (development, QA, release, dev-0ps, whatever you’d like to call it) to support operational maintenance for their systems.  Said another way those departments are being paid to support a product that does not make the company any money.  Now start-ups have successfully used open source software for years, companies much smaller than even a normal sized business, however keep in mind that start-up companies, in many cases are chalk full of software and QA engineers.  These are the very type of people you need to successfully support such applications, but remember to allocate some of their time to support these applications, they can’t be working 100% of the time on new product features for your application and simultaneously support bugs or problems found in the open source application.

The next point the author makes is flexibility, and yes while the source code is available to you, the question you really need to ask yourself is does your company have the skill set AND time to devote to writing, updating, QA’ing and maintaining code to support these new features that you COULD build?  If you don’t, then open source is not the right answer for you.  The author uses Microsoft Office as an example.  Can Office get pricey? Yes, does 98% of the workforce know how to use it and prefer it?  That would also be a yes.  Just because there is an alternative application, will YOUR business users be able to be productive with it?  Is saving $200 worth lost productivity for your VP of Sales, Controller or receptionist?  I’d likely take the bet that when you want something from people within your company, hearing they can’t do it because its a feature is not available or different than what they have been using for years, that it is not going to be an acceptable answer.

Control, which sounds like the author is really referring to licensing restrictions on commercial software, is also a bit of a hoax.  How many different types of open source licenses do you think exists? 5? 10? 25? Try 43 (at least according to wikipedia).  While many are corporate friendly if you are not redistributing the software, you should still have a legal department review the license agreement to ensure your company can’t be sued, even at a later date if the open source project is acquired by a commercial company who then changes the license.  Are you ready to take on the cost of legal fees if you use external counsel or additional time worked for internal legal staff to review licenses and keep up with changes to licenses?

Speaking of taking on cost, cost of ownership may be the biggest myth in open source software. It is NOT cheaper to use open source software, if it is, its by a slim margin.  Open source software is not a product, while some projects can be used to perform a specific tasks, it should generally be thought of more as a platform to build on.  You also have to ask yourself does it integrate with your existing systems? What is the learning curve? Who is going to support bugs?  There is a people cost to open source, and finding good people to support those applications is not easy.  I often use the refernece of finding a good linux admin versus a good Windows admin.  When it comes down to it, I can find a good Windows admin tomorrow (not to take away from their skills, there is just simply more of them out there).  Having been part of searches for linux admins/engineers I can tell you that you are unlikely to find a good one quickly.

That brings up support, the authors last point.  He states there are options for supporting open source such as writing to mailing lists and forums.  With all due respect, those are not viable support options for enterprises who might be relying on this software.  For fringe use, or low impact applications that might be viable.  But if this application is going to support the entire organization, or even someone high up the food chain at your company do you really want to rely on a mailing list or forum for help when the CEO is standing over your shoulder?  To be fair, many open source projects do offer commercial support, and there are companies whose sole business model is providing support for open source applications but your cost benefit argument quickly dissipates if you need to go this route.  Beyond support, what happens when there is friction within that open source community?  Look no further than CentOS and Nagios.  It was not long ago that people were pushing the panic button over friction with CentOS and jumping to other distros (a slightly older article here, only 3 years old) or developers “leaving” an open source project and creating a new one like what happened with Nagios and Icinga.  Is that acceptable to your support team and organization to just switch operating systems  or applications because of what boils down to a lovers spat?  Can you afford to lose support, or the amount of time and money previously invested in an open source project if its abandoned?

Another interesting support point, just because a application or company focuses on commercial software, let’s pick on Microsoft and VMware here, I would actually argue that the support provided by the community is far and away better than most open source projects.  In fact, its the support from the VMware community that led me to recommend ESXi back in 2008 over Xen Server.  When we ran into problems with ESXi there was, and still is a huge community offering support and suggestions.  These commercial software companies also have the resources to dedicate to maintaining and active knowledge base and documentation, something I find that tends to be lacking in open source projects (dear open source developers, man pages are not documentation).

Along the lines of support and abandonment, life span is another tick in the pro column for open source.  Are there older applications that work?  Of course, but are they supported?  There are just as many abandoned open source projects, and I’d be willing to be more than there are active ones.  Windows XP commercial support has finally come to and end, the right move would be for Microsoft to opensource it but at the end of the day, the need for XP was really killed with Windows 7, there isn’t much reason not to upgrade to Windows 7 in 2014 if you aren’t there yet.  Oh, what’s that?  Your custom application your engineering team build won’t work on 7?  They don’t have time to update it?  In that case will they really have time to update it if there are changes to the open source project or operating system they built it around?

Summary (also in this case the tl;dr version)

Now that my anti-open source rant is over, lets be clear – I am NOT against open source.  There is a time and a place for EVERY application, every operating system whether commercial or open source but it comes down to YOUR specific technical AND business requirements.  Old school corporate IT departments are dinosaurs, they do need to be more nimble but you have to, again, look at your specific business and what your needs are.  Can you support the application or operating system within your service level agreements?  If you can’t can you bring in people who can?  Can you afford that turn over in?  Can it be adopted and used efficiently by departments outside of IT?  Are you will to allow an appropriate amount of time in your engineering team to keep up on changes?  Remember not everyone is a computer geek.  Would it be nice to save money of Office, I’m sure every company would love that but does OpenOffice work with your existing applications?  What would the cost be to replace those other applications it needs to integrate with?  Most importantly, is your organization ready to invest in open source the way it needs to be?

Remember, open source is a platform, and more than likely the support burden will be placed on your organization.  Always, always, always consider the business as well as technical needs.

Skipping open source at work: How to convince your boss