During a break in the talk, one of the F100 folks leaned to another and whispered “I like everything I’ve seen about Unix -- except the people in this room.”
Jump ahead 30 years. Have you ever been to an ApacheCon? It’s like living in the 70s all over again.
It’s Coming From Inside the Firewall!
Nonetheless, open source is here to stay. If your organization isn’t using open source software in mission-critical applications, you’re in the minority. Even then, I suspect you are using open source software and just don’t know it. Even Microsoft has embraced open source by including open source versions of big data repository Hadoop on Azure, and they count Hortonworks and Cloudera among their valued partners.
And if you’re really one of those rare open-source-free enterprises, you might want to reevaluate your situation: you’re in an increasingly small minority.
It’s Just Like Commercial Software, Except …
If you’re going to use open source projects in-house, you’re going to need to identify a strategy for selection, implementation, operations and support just as you would any commercial product you use in-house. The trick is how you will access the required expertise.
For almost every open source project that works at enterprise scale, there are commercial vendors and consultants who will help you with selection through to support and updates. The challenge is when you need to combine two or more different open source projects -- for example Hadoop and Solr. You find yourself with a multi-vendor problem from the start. Sound familiar?
For these situations, talk to an independent consulting firm that works with all of the technologies you are considering. The major consulting firms are beginning to support these broad practice areas, and there are a number of smaller specialty firms that can also help.
Managing Open Source
Using open source in-house brings issues of its own that you need to address.
You need to have a corporate policy on the use of open source code/projects in your infrastructure. “No” is not a policy -- it’s a way to guarantee open source will be used under the radar.
Just because it’s free to download, open source is not license free. When you install commercial software, you agree to the vendor’s license. Chances are your corporate legal team has reviewed a couple of them and accepted the terms. If you’ll be using software with an open source license they haven’t seen before, be sure to build that into your project plan.
In the open-source world, there are several styles of licenses. Two common ones you’re likely to see are the Apache Software License (ASL) and the Free Software Foundation’s GNU "GPL" (and a variation called LGPL). There are a variety of other licenses, and a full discussion is beyond the scope of this article. Keep track of which named licenses apply to which open source components you plan to use. If, for example, your legal department has previously approved the Apache license, you may not need to have it reviewed again, or at least it may be a much shorter process.
With commercial and open source software, be aware of compatibility and inoperability issues related to technology. Incompatibility between the licenses is common with open source software.These are generally not an issue if your application is purely for in-house use. But even if you use open source applications exclusively in-house, you need to be aware that some open source licenses require you to contribute any patches or changes back to the open source project. This alone can often make it worthwhile to deal with one of the commercial open source vendors rather than go it on your own.
There is another consideration that few organizations consider when it comes to open source software: version stability.
When you commit to a commercial platform, you expose yourself to "vendor risk" in a way that can be expensive. For example, the vendor may shut down or be acquired, leaving you without support, or in some cases with a forced “upgrade.” But even when your vendor remains fiscally healthy, you stand some risk that the next version of the product will not be fully compatible, and features you rely on will disappear.
With open source software, nobody can take it away. You generally do not need to upgrade simply because there is a major new release. If there are compelling new capabilities, then you can choose whether to upgrade. But it's often the case, “if it works, don’t fix it.”
Expertise: Buy or Rent?
Depending on the scope of your project and how critical it is to your business success, the amount of internal expertise you have may vary widely. Some e-commerce companies have large staffs to maintain and enhance their underlying search technology, because the technology is an integral part of their organizational IP and a major part of their bottom line. On the other hand, if open source is a tool you will use to solve an in-house requirement, you may be able to get by with one or two staff members familiar with the product, and rely on consultants or vendor support when question come up.
Chances are you’re already using open source -- whether you are also using platforms from SAS, Oracle or even Microsoft. Start by making an inventory of the tools you’re using now and the ones that you’re looking at. Keep track of which open-source license each tool uses. Take an inventory of skills you have in-house and the ones you need, plan training for your teams and find a reliable source for your support and customization requirements going forward. Open source can save you time and money, but you need to be prepared!