Why you should take notice of the open source in enterprise suckers conundrum

I recently published a story that covered the bold move by Ockam.io to open source its SDK for its IoT securing solution. During the conversation, I posited the question as to whether Ockam runs the risk of being Amazoned very much like appears to be the case with MongoDB where AWS has effectively repurposed an older version of MongoDB and called it DocumentDB.

In the MongoDB case, AWS is widely regarded as responding to a licensing change MongoDB made in October 2018 that has caused something of a stir among the open source cognoscenti.

In November, Geekwire reported:

“Whenever a new open-source project becomes popular, cloud providers strip mine the technology, put the freeware on their platform, capture most if not all of the value but give little back to the community,” said Dev Ittycheria, president and CEO of MongoDB, currently valued at $4.3 billion on the Nasdaq. “We think it’s important for someone like us to lead and help the next set of open-source companies and projects thrive and grow.”

Late last week, Frank Scavo offered his thoughts on why open source is not successful at enterprises. The Tl:DR:

1. Open source needs a large set of potential users. But enterprise applications do not have as broad a potential user base as infrastructure software. Although the ERP market is huge, when you break it down by specific industries, it is small compared to the market for, say, Linux.
2. Enterprise apps require a large effort in marketing and sales. Buyers put great weight on name recognition. But open source projects do not generally show much interest in the sales and marketing side of a business. If a project is truly community-developed, who is interested in marketing it? As a result, very few people know what Odoo is, for example, let alone, how to acquire it.
3. Open source is labor-intensive. It is great for organizations that have time but no money. My impression is that open source ERP adoption is somewhat more successful in some developing countries, where there are very smart people with good technical skills willing to spend the time to implement a low-cost or no-cost solution. Here in the U.S., such companies are rare. Most would rather write a check.

I'd go one step further and as a nuanced view of Frank's (2) element. In most cases, enterprise software is sold, it's not bought. Troupes of vendor reps, marketers and other hangers on line up to convince you about taking on one or other solution. In the open source world you are 'buying' not being sold. There is no real money for marketing and sales. You either take it (for free) and then work on it yourself, or you enlist the help of specialists who both understand your processes and the software code itself. And despite the early success of Salesforce as a cloud vendor from whom you bought applications at the departmental level on your credit card, the majority of enterprise deals are sold.

By way of response, Josh Greenbaum weighed in adding fuel to the words of MongoDB's CEO:

Open Source is popular not just because it’s good but because it’s foundational model is a sucker’s game. People develop this stuff for free, loads of them, and in the process hand enterprising vendors and investors a mighty fine nest egg on which to build out a for-profit enterprise. This makes Open Source hard to resist as a starting point for enterprise software. If someone hands me a free pile of pre-cut lumber to build a house, why would I bother to cut down my own trees and mill them? And if it were truly free, no strings attached, all the better.

You can be certain that inside most enterprise cloud based software today, you will find some if not a lot of open source code. But then Josh hits on one of the most crucial elements of this debate as it applies to the enterprise:

...Open Source is excellent at creating commodity-level software – hence its acknowledged dominance in the infrastructure world. But just as the world of PaaS is taking a lot of basic commodity functionality out of the data center and putting in the cloud, so is Open Source taking a lot of cost and complexity out of building next generation enterprise software.

But it can’t be that next generation enterprise software, any more than I can mill a house out of a forest full of trees. The last mile – that part where a business’ or industry’ needs and opportunities and its users’ needs and desires are realized in a piece of software – isn’t something you can do with more eyes and more hands. In fact, we all know lots of examples of software that’s over-engineered and over-programmed, and the resulting bloat says everything about why the last mile isn’t conquered by more, but by better.

Hell yeah and we've seen this time and again. It's one (of many) reasons why there are more than a million SAP developers out there. Goodness knows how many Oracle DBAs there are - anyone got a count on that?

My world problem

We see this in our corner of the world too.

For better or worse we've operated using the open source Wordpress platform for nearly six years but are moving off it in the next few months. Why?

We quickly discovered that when you want to use Wordpress, you end up relying on an ecosystem of mostly open source plug-in developers. A few are commercial but many are not and that in turn means you have no idea whether the plug-ins you need are compatible, will throw errors or stop being supported. Over time, that turns your developer effort into a maintenance migraine. It is one of the hidden costs that people don't talk about.

Our alternative is another open source system but one that has a controlled community behind it and where new plug-ins are tested and certified to work with different versions. That way, we avoid the problems Wordpress brings and flip the maintenance/developer switch to allow for more innovation inside our devops budget.

However, it comes with a sting we have yet to work through with the development team who are committed to open source. They make much the same arguments as Holger Mueller does about access to community and fresh eyeballs on the problem you're solving. I have no fundamental argument with that except as it relates to the 'last mile' issue Josh outlines.

In our case we are after a specific piece of functionality we know will take time to build, will be bleeding edge, and will almost certainly cost a good sum of money. We know that some open source components may be required but we don't yet know which will work and which won't. Why would I pay for that development only to see it dumped into the open source community? I wouldn't and I won't. It makes no commercial sense, especially as we believe that we are looking to solve one of the hardest issues there is in our world. If we get it right then we have a clear measure of differentiation beyond what we can promote today.

We also see that more doesn't always mean better. In the SAP world for example, I know of possibly 100 seriously rocking coders who make what I see as real magic. I'm sure there are more but you should by now get that 100 out of a million is a very small percentage. Even if it is a thousand or ten thousand it's still a small percentage.

An example: a few years ago I was part of a demo team and we could not for the life of us assemble a decent front end. An SAP developer did it. On a three-hour plane ride. We'd spent months head scratching. Go figure.  And just as a side note, that software was what Slack is today. We were years too early but that is another story.

Where does this lead?

I'm in the camp that says IaaS and PaaS components should probably remain as open source because while foundational, they generally have universal application and are, by definition, commodity software.

That doesn't mean developers should be treated as sweated labor in that context and there, I wish like Josh, there was a simple answer to the question of compensating those efforts. Right now there really isn't apart from services built around those offerings. And guess what? The likes of AWS, Google, Microsoft, IBM, and many others will dine nicely on those.

The question then arises, how might this apply to enterprise software? I have long argued that in financials, the basics of what comprises a set of ledgers is built on a theory that has stood the test of time by some seven centuries. There is one outcome and that's called double-entry book-keeping. It, therefore, doesn't matter who supplies those ledgers because entries put into any one will produce an identical outcome when put in another system.

The business processes that feed into these systems exhibit the 'last mile' problem to which Josh alludes. Solving for that requires the kind of domain knowledge expertise that is rarely found in the open source community.

Endnote: Jon Reed does a tidy round up of the Mueller, Scavo, Greenbaum arguments in this week's Hits & Misses.

Update

Following my publishing this story, I came across a TechCrunch story that talks to the buy/sell issue outlined above. It makes an interesting argument as it relates to what it calls 'Gen 3' open source companies:

Another great advantage of open-source companies is their far more efficient and viral go-to-market motion. The first and most obvious benefit is that a user is already a “customer” before she even pays for it. Because so much of the initial adoption of open-source software comes from developers organically downloading and using the software, the companies themselves can often bypass both the marketing pitch and the proof-of-concept stage of the sales cycle. The sales pitch is more along the lines of, “you already use 500 instances of our software in your environment, wouldn’t you like to upgrade to the enterprise edition and get these additional features?”  This translates to much shorter sales cycles, the need for far fewer sales engineers per account executive, and much quicker payback periods of the cost of selling. In fact, in an ideal situation, open-source companies can operate with favorable Account Executives to Systems Engineer ratios and can go from sales qualified lead (SQL) to closed sales within one quarter.

The whole story is worth the reading but this section alone provides pause for thought.