Design, deliver, and run enterprise blockchain workloads quickly and easily.
All servers and systems
Open source software (OSS) offers many benefits for organizations large and small—not the least of which is the price tag, which is often zero. Zip. Nada. Free-as-in-beer. Beyond that compelling price tag, what you often get with OSS is a lack of a hidden agenda. You can see the project, you can see the source code, you can see the communications, you can see what’s going on in the support forums.
When OSS goes great, everyone is happy, from techies to accounting teams. Yes, the legal department may want to scrutinize the open source license to make sure your business is compliant, but in most well-performing scenarios, the lawyers are the only ones frowning. (But then again, the lawyers frown when scrutinizing commercial closed-source software license agreements too, so you can’t win.)
The challenge with OSS is that it can be hard to manage, especially when something goes wrong. Depending on the open source package, there can be a lot of mysteries, which can make ongoing support, including troubleshooting and performance tuning, a real challenge. That’s because OSS is complex. It’s not like you can say, well, here’s my Linux distribution on my server, and here's my open source application server, and my open source NoSQL database, and my open source log suite. In reality, those bits of OSS may be from separate OSS projects, which may (or may not) have been tested for how well they work together.
A separate challenge is that because OSS is often free-as-in-beer, the software may not be in the corporate inventory—especially if the OSS is in the form of a library or an API that might be built into other applications you’ve written yourself. The OSS might be invisible but with the potential to break or cause problems down the road.
When it comes to OSS, there may be a lot you don’t know about, such as those license terms or interoperability gotchas.
Worse, there can be maintenance issues—and security issues. Ask yourself: Does your organization know all the OSS it has installed on servers on-prem or in the cloud? Coded into custom applications? Are you sure that all patches and fixes have been installed (and installed correctly), even on virtual machine templates, and that there are no security vulnerabilities?
Let’s dig a little deeper into six gotchas of open source: license management, security, patch management, maximizing uptime, maximizing performance, and supporting the OSS.
1. License management. There are many open source licenses, and some of those licenses have specific terms. This includes agreeing to give changes back to the community or to make projects incorporating OSS code open sourced. Also, some OSS projects are free for personal or educational use, but not for commercial use or use in specific countries.
It’s essential that whatever entity in your organization looks at contracts knows about all—and I mean all—open source that is in use, whether it’s used only on a developer’s desktop or it's deployed as the key foundation of your big data analytics. That includes binaries, tools, components, and software development kits. After all, those licenses are true binding legal documents, and you must stay in compliance with them. You (and those legal eagles) need to know what OSS you have, and which licenses you have. Don’t forget, many OSS projects are owned or controlled by big corporations, and they license terms seriously.
2. Security. In theory, one of the strengths of OSS is that because the source code is available, it’s more secure because “many eyes make bugs shallower.” Well, no. Not all OSS projects have many eyes, and not all OSS projects use modern software development methods. Not only is testing not always up to commercial standards, but the project may crowd-source the testing. Proof point: The major open source projects release security updates on a regular basis.
The software quality issue, including security, can be particularly problematic with forks, where community resources can be split. Plus, online support forums may not always have awareness about forks or customized versions of the OSS. And depending on the community, developers may not respond quickly to vulnerability reports.
And I hate to say it, but many eyes might make bugs appear. Bad actors could study OSS and discover zero-day flaws, which they might sell on the Dark Web or exploit themselves.
3. Patch management. Consider what happens when a bug is discovered: It might be a typo in a help screen, or it might be a nasty security vulnerability. With some (but not all) open source projects, it may take some time to get the word out and get a patch created and tested. News about the bug may not be well distributed, and even news about the update may not be widely publicized. Remember, there may be dozens, or hundreds, of separate open source projects being used in everything from a Hadoop cluster to a Ruby on Rails toolchain.
Administrators or users might easily miss reports of flaws and updates, and auto-update functions can be poorly implemented, if they exist at all. (And they won’t help you on embedded software components.) It is up to you to ensure that all OSS is at the proper patch level, which can be really challenging when dealing with OSS installed on embedded devices, servers, the cloud, and virtual machine instances or templates.
4. Maximizing uptime. Just because a piece of software is running doesn’t mean it’s running well. OSS software, like any other bit of code, can become destabilized or crash, depending on where it’s installed or if something changes after installation. (New device drivers, anyone?)
You should plan configurations and changes carefully, because many OSS packages (like commercial packages) are brittle if misconfigured. Use lifecycle management and monitoring tools to watch how the OSS is performing, and avoid beta releases in production environments. I know, you want the new features, but keep the betas in the lab, OK?
As mentioned under security above, it's important to stay up to date on updates and patches to ensure you’ve caught flaws that affect performance, such as memory leaks. And be aware that each OSS may have its own stack, where there are specific dependencies on particular versions of other OSS packages or libraries. Updating one application or library could have a really hard-to-find ripple effect—and who are you going to call?
Finally, and this is hard, retire old OSS packages. A package that’s no longer being updated is a ticking time bomb. Better to replace it while it’s still working, so it can be a clean migration, rather than wait until something breaks it.
5. Maximizing performance. Just because a piece of software is running doesn’t mean it’s running efficiently, nor that it will perform at scale or in tight quarters. A selling point of many OSS packages is that they run well with limited resources. Well, like other software, OSS may require more memory, more CPU, and more storage, as it scales. However, community testing does not stress-test for instances where storage is running low, memory is exhausted, or there’s excessively high CPU utilization, so watch for those conditions on production systems.
Practice good hygiene. If you compiled the code yourself, make sure you used a good compiler with the right switches. Clean out log files periodically, and don’t assume the software will handle it. You might install good CPU, storage, and memory monitors—and run a baseline so you can see if performance degrades, and if so, where. You might also consider the user of containers to isolate packages and improve update and performance.
6. Supporting OSS. One throat to choke? Sorry, the workers behind projects at Apache or Eclipse or working hard on GitHub don’t want their throats choked. At all. Ever. Now, often corporate open source users can establish a good rapport with a support community, but some are prickly. Ask a question the wrong way, and you could get the silent treatment or some pretty nasty abuse.
For some organizations adopting OSS, that’s fine. They are techies who love to get into the internals and are often contributors to the projects themselves. However, other organizations adopt OSS because it’s all they can afford (free-as-in-beer) and don’t have the time, interest, or talents to become experts. (Frankly, that’s why so many businesses use software from Microsoft.)
My advice here is forget free-as-in-beer. Get paid support for your most crucial projects, whether it’s from people involved in the project, the project’s sponsor, independent consultants or experts, or, well, anyone you can count on to answer the phone at 11 p.m. on Saturday night.
Open source software makes excellent sense for many organizations: The price is right (even if you need a support contract), the functionality is impressively high, and there usually aren’t many bugs—or at least, there usually aren’t more bugs than in commercial software. Just keep in mind the six gotchas, and if you cover those bases, you’ll be all set for success with OSS.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.