“Software is eating the world,” has been repeated so often that it is practically a meme. And though we wrote about how “open source is eating software,” as far back as 2015, it is a fact that is only being widely acknowledged now. Perhaps that is because the Linux Foundation has published survey results documenting exactly that. “Almost every organization today uses open-source code and it has become table stakes for most businesses,” according to the Linux Foundation.
Constellation Research vice president and principal analyst Holger Mueller echoed the sentiment publishing a blog post, “Why Open Source has won and will keep winning.” In addition to that, venture capitalists are suddenly deciding that open-source software companies make good investments.
But that doesn’t mean that enterprises should rush to open source blindly. Proprietary software vendors like Adobe, Amazon, Microsoft, Oracle and Salesforce, among others, still dominate the market, partly because they are so well embedded in enterprises, and partly because business application suites in areas like CRM, ERP, finance and human resources are so tightly integrated. Not only that, but vendors whose software was embraced as open source have now begun to change their licenses leaving adopters questioning whether they want to stick with their original decisions. And, finally, while large technology companies such as Alphabet, Amazon, Apple, Facebook, Microsoft, Netflix, VMWare and the like, have open-source policy offices that handle governance, interoperability, security etc., many enterprises do not. That needs to change, according to experts.
Related Article: 7 Free Enterprise Intranet Solutions (That Aren’t Really Free)
Here are five questions that companies should consider when it comes to open-source software
1. Is it actually open source?
Organizations, such as the United States Federal Government, are increasingly issuing policies that lean toward open source over proprietary software. Take for example a memorandum issued by former CIO Tony Scott, “Federal Source Code Policy: Achieving Efficiency, Transparency and Innovation through Reusable and Open Source Software.” Note that not every software vendor that calls its product “open” is open source. Patrick Masson, general manager and board director at the Open Source Initiative (OSI), told CMSWire that some software makers are “open-washing” their products hoping that enterprises and developers will mistake “open core for open source. Open core, according to the OSI, has NOTHING to do with “open source.” It is worth noting that today nearly every proprietary software product has various degrees of open-source licensed source code in its core. But that does not make it open source. “Open Core” has none of the advantages of open source to the user and is merely a nickname for a proprietary software company, according to the OSI.
Masson also cautions adopters against fake open-source, or “fauxpen” software. “Fauxpeness,” according to an article in Linux Magazine is “calling a system or platform open, while it is, when more closely scrutinized, under the tight control of its provider.”
2. How many committers behind the open- source project?
“More hands make better software,” according to Mueller. “Open source has successfully tapped into the desire of many developers and engineers to be part of something bigger, to improve something and most importantly to work on something that is near to their minds and dear to their hearts. Most importantly, open source has figured out how to scale to thousands of developers/contributors all working remotely. This has always been a key challenge for traditional vendor-based development forces,” he mused.
That being said, according to GitHub, most open-source projects do not have large communities around them, so buyers need to beware. Before adopting code from a project, it is important to look into the collaboration around it using qualifiers such as commits, conversation, support.” Open source is more than just code. Successful open-source projects include code and documentation contributions together with conversations about these changes,” Arfon Smith, head of data science mission office at the Space Telescope, wrote on the GitHub blog.
Related Article: Github’s Top Open Datasets For Machine Learning
3. How many eyeballs on the open-source code?
Remember Heartbleed, the bug that made user passwords vulnerable and sent the world into a panic in 2014? It exploited a serious vulnerability in the popular OpenSSL cryptographic software library that is said to keep the internet secure. Netcraft reported that Heartbleed made as many as 500,000 websites, that were thought to be secure, vulnerable.
What was at the root of the problem? According to an article (from 2014) by Robert Lemos in the MIT Technology Review, “(only) 11 developers donate much of their time to the OpenSSL project (probably too few) and that the OpenSSL Software Foundation, which handles the commercial contracting for the organization, employs just a single full-time developer.
The size of the community supporting the project matters. “Given enough eyeballs, all bugs are shallow,” Masson said, quoting Linus’ Law. In other words, as important as OpenSSL is, it didn’t have the community it needed to support it. It’s worth noting that OpenSSL has received more support in the interim with Akamai, Huawei, NetApp, Oracle and VMware as commercial sponsors.
4. Are you ready to actively manage open-source licenses?
Managing open-source licenses is a bear. According to open-source platform maker Sonatype, the average application contains 106 open-source components. David Jackson, CEO of software consultancy FullStack Labs, said one of the main challenges enterprises face is how complex open-source software licensing is. “Each language or library has its own primary license. But all open-source software is built upon other open-source software, which has its own individual license, and which itself is built upon even more open-source libraries. So, very quickly you end up with thousands of dependencies each with their own license type.”
His company’s approach toward helping enterprise level clients solve the challenge involves four steps:
- The legal team needs to define which open-source license types are acceptable and which aren’t. We’ve had a surprising number of large, multinational enterprise clients who haven’t taken this step, and don’t have any standards around open-source license types.
- Once the list of acceptable / unacceptable license types has been established, the development team needs to run a script to scan all of the license types for all of the dependencies of the app, and generate a simple report showing the different types being used. In our experience, this will generally find less than a dozen different license types for an average size app.
- If any of the app dependencies have license types that aren’t approved by legal, they should be removed.
- Repeat this process once per month, and prior to any major release.
5. Do you understand what it takes to secure open-source software?
The jury is out as to whether proprietary software is more secure than open source or vice versa. One argument says that open-source code is open and is tested and verified by a larger community and is therefore more secure. The other claims that proprietary code is better because the buck stops with the software vendor who is responsible for updates, patches and so on.
Contrast Security co-founder and CTO Jeff Williams said enterprises need to worry about open source because it is “inextricably bound with modern software. Every website, every API, every desktop application, every mobile app, and every other kind of software almost invariably includes a large amount of open-source libraries and frameworks.”
He added that with open source, “dozens of new vulnerabilities are discovered every week, but we’re only scratching the surface. The problem is that only a handful of talented security researchers are doing the highly skilled work of testing this code. That means that there are, almost certainly, large numbers of latent vulnerabilities in open-source software. Having a researcher discover one of these and publish it seems like an expensive fire drill for companies, because they have to search to see if they’re using the library, replace it, recode their application to match, retest, resecure and redeploy. But if a malicious actor finds the vulnerability and starts attacking companies with it, the damage can be much more expensive. Web applications and web APIs run with almost full privilege inside a company’s data center, and all that open source inherits the power to do anything the application can do.”