neon sign reading "open 24 hours"
PHOTO: Cyle De Guzman

Back in 2013, CMSWire asked a simple question of experts in the field: "Which is better, proprietary software or open source?" While there was no consensus at the time, the question itself seems archaic today.

'Open Source Is Everywhere'

"Open source is everywhere," said Holger Mueller, vice president and principal analyst at Constellation Research. A quick look at the proprietary software vendors of yesteryear drives his point home. Open Source code is not only leveraged by most of them, but they are also large contributors to open source projects. Consider that Cisco, Google, IBM, Microsoft, Pivotal, SAP, SUSE and many others back the Cloud Foundry Foundation. And even though Red Hat is the company everyone points to when they think open source, Microsoft has twice as many employees — 4,550 — who contribute code to open source projects. Amazon, IBM and SAP also land in the top 10.

So even though open source is prevalent, most software vendors don't label themselves as "open source." Why not? And what about those that label themselves as "open core" or attach specialty licenses that put conditions on use of their open source code, such as Confluent with its Confluent Community license or MongoDB with its SSPL license

Open source and "free open source software" (FOSS) developers and enthusiasts are often deeply passionate about what is and isn't open source. They talk about the different meanings of “free,” such as “free, as in beer” and “free as in libre.” Yet most software coders, especially of the Github generation, grab whatever code they find useful and start coding. They don't think too much about software licenses. "Their managers don't like the code grab and go method so much. They care about the consequences and price. Developers not so much, or at all," said Mueller.

But should they? Should IT managers? Should you? Let's start by looking at what people in corporations think when they hear the term "open source." 

Related Article: 5 Tips for Deploying Open Source Software

How Execs Define Open Source

Software executive Dave Kellogg, former CEO of Host Analytics and Marklogic and a board member at Nuxeo, said when people think about open source they confuse two things: the source code and the business model. The questions to ponder when it comes to the source code, according to Kellogg, are:

  • Access: Can you see it, access it, change it, etc.?
  • Who builds it: Is it built by a distributed community of hundreds or thousands of people making small contributions (as one imagines by default) or just primarily by a vendor's engineers?

Drupal, for example, has 114,702 users actively contributing to the project while around 99% of MongoDB's code is written by the company's employees.

When it comes to the business model, since open-source software is in most cases "free," assuming you're not getting the code directly from someplace like the Apache Software Foundation or the Eclipse Foundation, Kellogg suggested asking how the vendor behind the open-source project makes money.

  • In a pure services model, like Hortonworks was (and its HDP distribution still is), the customer pays for technical support and/or consulting services.
  • In an open-core model, like Elastic, some portion of the product is free, but the premium version or add-ons are licensed with a commercial license. (Think community edition vs. enterprise edition.) "Here an open-source vendor's biggest competitor is usually its free version," said Kellogg.
  • In an as-a-service model, like Databricks, the vendor hosts their open-source software as a service in the cloud and charges a monthly/annual fee for hosting and supporting it.

Gartner analyst Nick Heudecker breaks open source vs. open core down this way: "Open core are commercial products built on an open source project. Open source is both a development process and source code licensing approach."

Heudecker described the value proposition in a blog post

"The central value proposition of open-source core vendors has been freedom from vendor lock-in. After all, the core elements of the product are open source, and developed by a global community. The core product isn't owned by a single company, but, in almost every meaningful instance, by the Apache Software Foundation (ASF). If the worst happens and we go out of business, the code will live on in the ASF. You're safe. If you don't like us, it's open source. You're protected.

"It's a good story. If we're all honest with each other, it's not true. But still a good story. And a great way to get in the door and quickly close an expansion deal at the end of the initial 12-month contract.

"At the end of the 24- or 48-month period, the vendor needs to ramp up revenues and increases prices, sometimes drastically. That's a triggering event for clients to get me and my colleagues on the phone. They ask their users about the features they actually use and value. Can they do without the features that aren't part of the open-source component? In some cases, yeah. Who else is in the market that supports the open-source bits? Are they cheaper? Are they the same strategic vendors I'm already working with?

"Other vendors smell blood and ask us if they should offer support for those components for cheap. Their customers talk to them about other in-house vendors too."

Kellogg sees the sales strategy a different way. "From a vendor perspective, your free/community edition becomes both a major lead generation source and, in a sense, your biggest competitor — if you haven't put enough value in the enterprise edition over the community edition, then people won't purchase and/or renew it. And renewals I'm told are the real test," he noted.

Related Article: 5 Questions IT Managers Should Ask Before Choosing Open Source Software

Do Enterprise Buyers Prefer Open Source or Open Core?

When asked if enterprise buyers are choosing open source over open core or if they are simply choosing software/services based on the direct business benefits they provide, Ovum analyst Tony Baer said it depends.

"That's a loaded question," he said, "and the answer is 'it depends.' Theoretically, all software decisions should be driven by business benefits, but as to what those business benefits are, they could be a range of options from adding to top line, improving bottom line, staff retention (relevant for keeping developers who want open source on their resumes), or compatibility with existing IT environments or those of organizations undergoing M&A.”

Most of the analysts we consulted said companies should keep an eye on the different open source technologies they're using, which is easier said than done. First, because developers don't generally ask permission when they grab something from Github or other sites. And, second, as Kellogg pointed out, there are 82 different license types on the Open Source Initiative (OSI) approved list and companies need to understand which components are governed by which licenses and what the ramifications of using them are.

That is something that large companies, even those championing open source, are now beginning to do, according to Patrick Masson, general manager and board director at OSI. Consider that Google, for example, outright bans at least seven open-source license types.

Some might conclude that open-core software might be a safer and easier way to go because the commercial vendor behind the product handles things like the license compatibility and has built in the manageability and security features that enterprises require. But the jury is out, and big cloud providers like Amazon, Google and Microsoft may be changing the game.