Why open source needs more cloud

There isn’t one model for doing open source right, but generally the path to success will involve growing the overall market—even at the expense of control

Why open source needs more cloud
SAS

Too many open source companies are aping the worst of Microsoft’s past behavior, declares Redmonk analyst Stephen O’Grady in an interview, arguing that they’re “fixated” on the “shortsighted” view that “we built it, only we can profit from it.” This echoes something that Chef (now System Initiative) co-founder Adam Jacob recently said, when he argued that open source competition “makes the funnel at the top bigger.”

The choice, according to O’Grady and Jacob, is whether to own all of a small pie, or take a piece of a much larger pie, which turns out to be worth a lot more. And just as importantly, as O’Grady highlights of Microsoft’s earlier behavior, you can end up losing the market by trying to own all of it.

Back when Microsoft wasn’t cool

Microsoft today is a very different company from what it was in the 1990s and 2000s. I spent much of my early career raging against the Microsoft machine. The Redmond giant was easy to dislike back then. It threatened open source with its patent portfolio, and generally did whatever it could to halt the spread of open source.

By 2010, as chief operating officer at Canonical, I was suggesting that Microsoft should get serious about open source. The company seemed stuck on Windows and Office, apparently unable to think through its next billion-dollar business. By 2015 it was clear that Microsoft had its developer mojo back, fueled in large part by (you guessed it) significant, sincere open source outreach. Today I work for a direct competitor to Microsoft, but I love how the company has embraced open source.

Even as Microsoft got things right on open source, relinquishing the need to be in control, it was getting schooled in other areas where it couldn’t embrace a community approach. Whether with Mono or .NET, O’Grady points out, “Microsoft was fixated on an idea: ‘I wrote this, and therefore I’m the only one who should be paid for this.’” While this may seem reasonable, he notes it “didn’t do them any favors at the time.” O’Grady continues: 

It was probably '04, '05, '06, somewhere in that range, and I told Microsoft privately that the best thing that they could do at the time was to give the Mono Project [an open source project that enabled .NET applications to run on Linux]... a patent amnesty…. And all at once Microsoft would’ve had a[n]... implementation on non-Microsoft platforms. And that was what they were getting killed for at the time, which was, ‘Hey, this works fine on Windows, but I have some workloads that I want to run on Linux. And I can run Java on both platforms, I can run your stuff only on your platform. That doesn’t do me any good.’

But Microsoft at the time was fixated on, ‘No, we’re not going to do that, and we would never do that because we wrote this.’... [T]he ideology of the company at the time didn’t allow them to see that, and I think that there are a lot of parallels to the world that we see today.

Today Microsoft has embraced Mono, and open sourced its own .NET Core, a replacement for .NET Framework that makes it easy for .NET-based applications to run on Linux. 2020 Microsoft seems to realize that it’s better to expand markets than to constrict and control them. 2010 Microsoft did not. In similar manner, O’Grady stresses, some of today’s open source companies haven’t learned from Microsoft’s past mistakes.

Validating and growing the market

“I understand the visceral impulse,” notes O’Grady, “which is, ‘hey, I wrote this thing, I don’t want somebody else to go off and pick it up and make money from it.’ But frankly, that’s the kind of thinking that held Microsoft back for years.” How is it holding back open source companies today?

Well, first—and this is me talking, not O’Grady—it diverts their attention from the most important thing: their customers. It’s not hard to see commercial open source company fortunes rising in tandem with their cloud businesses, not licensing gymnastics, something I’ve highlighted. As an industry, we wasted years with such approaches. Remember Open Core? It was just a precursor to the different licenses (Commons Clause, Server Side Public License, etc.) that sought to do the same thing, i.e., make an otherwise open source project at least a little bit proprietary in hopes of scooping up cash.

Unfortunately, as O’Grady argues, “What are the implications [of such approaches] long-term? Typically it’s not good. You’re going to have, probably in most cases, problems with adoption, problems with usage, and problems with essentially getting to the ubiquity that you want and in fact need for a lot of open source commercial models.”

Instead, the answer is to embrace the cloud, because that’s how your customers want to consume your database, operating system, etc. But what happens when an 800-pound gorilla takes your open source project and creates a rival cloud service? That’s got to be bad, right?

Nope. The biggest problem for any startup isn’t collecting cash. The far bigger problem is getting noticed, attracting users. “To some degree, the spinning up of a competitive product from one of these cloud providers is nothing more than market validation,” says O’Grady.

Take the database market, for example. DB-Engines currently lists 359 databases. It’s a struggle to stand out in that crowd. “I can pick between these ones that are smaller, that don’t see much usage, and one that is backed by MongoDB, Amazon [DocumentDB], and Microsoft [CosmosDB]. That becomes a pretty easy decision in terms of, ‘Oh, hey, this is the one that has clearly the most traction, this is the one that the market is agreeing on.’”

But so what if competitors validate the market but also take customers? This is where Jacob chimes in:

When you think about somebody building and taking your software and trying to build another product to compete with you on it, what they’re actually doing is building the top of your funnel. They’re making the funnel at the top bigger. And since that impact is so outsized, the number of opportunities they create for you is bigger than the amount you lose at the bottom in competition every now and again.

Writing software is very different from operating it, and perhaps some open source companies will say, “It’s too hard.” They’re right; it is hard. But as O’Grady concludes, “You don’t have a choice, really. Customers are going to get what they want one way or another, and if you don’t give it to them, they’re going to find it somewhere else.”

Learning from Redis Labs

The great news is that many are going to want to get it from the company that knows the code inside and out. Redis Labs is a great example of this. When Redis founder Salvatore Sanfilippo decided he wanted to move on to other projects, Redis Labs had a choice to make: Lock down the Redis code or open up. It chose the latter, enlarging the governance structure for the project. There are currently a slew of managed services for Redis (offered by everyone from Redis Labs to Aiven to Instaclustr to DigitalOcean to Microsoft to... you get the picture). There’s also increased velocity in terms of contributions to the project.

Redis Labs seems to be banking on O’Grady’s and Jacobs’ vision of a bigger Redis pie, one that it doesn’t control but from which it still draws impressive revenue. Yes, the company still offers software under proprietary licenses, but it seems to be taking a more open path, generally.

And, as O’Grady notes, there isn’t one model for how to do open source right. Redis Labs may take a different path than Instaclustr, for example, but in general, the right path is going to involve growing the overall market even at the expense of control, rather than trying to hoard a relatively small market. That latter course costs a lot more to build, has greater chance of failure, and seems unnecessary, given that we can learn from Microsoft’s past mistakes in that area.

Read more about open source:

Related:

Copyright © 2020 IDG Communications, Inc.