1 min

Read

4

Follow the CAPEX: Commercial Open Source vs. the Cloud

By

Charles Fitzgerald

See the source image

A mighty albeit abstruse debate rages: whether commercial open source companies can withstand and/or deserve to withstand the immense and feature-crushing gravitational pull of the public cloud black holes. While others far more versed (or at least self-interested) in the metaphysical intersection of open source ideals and cold, hard economics furiously deliberate the stakeholders’ putative rights and obligations, I thought it would be fun to look at it through the CAPEX lens (which some might say resembles a hammer in my hands).

In particular, Elastic and MongoDB offer managed services based on their software. As they are publicly traded, they report their CAPEX investments. Lets compare their investments to the hyper-scale public clouds (AWS, Google and Microsoft):

image

Here’s the chart on a log scale if you’re on a vertically challenged screen:

image

Note: this is all up CAPEX for the public cloud companies, not just their cloud infrastructure. But this is true for the COSS companies too Winking smile .

, , , , , , ,

4 responses

  1. Bryan Avatar
    Bryan

    I don’t think CapEx is the right lens in this case. A better one would be OpEx, notably R&D expense for the open source community as a whole vs. the R&D for cloud hyperscalers. This is because CapEx reflects physical infrastructure that these companies are not involved with, while software development is a non-recurring expense.

    You could also look at gross and operating margins. High margins implies that most of the benefit comes from the base software development investment. Lower margins would skew more towards services, which while valuable is less scalable and vulnerable to cloud scalers or others poaching the talent. As most of these open source companies are in growth mode, you could take a ratio of revenue to R&D (removing sales and marketing). The expectation is that would be rapidly improving over time as the software development investments pay dividends over time.

  2. Charles Fitzgerald Avatar
    Charles Fitzgerald

    CAPEX is the right lens only in the sense that it shows the COSS companies are not even remotely in the infrastructure game. Yet they want to compete with the public clouds to offer a service (and only one specific service — they still need the cloud vendors to provide all the other complementary services their mutual customers require). It raises lots of interesting questions. Is that a viable business or a just a feature? Are the COSS companies really better at operating services than the hyper-scale cloud vendors? Should they be able to retroactively amend the open source “contract” to deny competitors who have made huge investments to realize economies of scale and scope the ability to use those open source bits? Do COSS companies have a “right” to profit from a particular open source project?

  3. Bernardo Rodrigues Avatar
    Bernardo Rodrigues

    I love reading your posts. So much so that I now completely disregard any non-CAPEX-related metrics when thinking about cloud business growth 😀

    In all seriousness though, I think the waters get a bit muddier when we look at these open-source developers and the services they provide.

    They are not directly competing with the major cloud providers, but rather piggyback off of their offering to provide both software and services – MongoDB Atlas being a clear example of it – customer uses Atlas to provision infra over AWS and then pays MongoDB for managing and maintaining.

    So provisioning still happens on the major cloud providers but just the services are provided by the developers themselves. This really looks like to only way open source companies like MongoDB and Elastic can make money (aside from the obvious value-added complements, like extra features) – services, support and extra features.

    As far as CAPEX goes, maybe I’m totally missing the point here, but the business model seems to make a direct comparison impossible.

    I do agree doesn’t look like a very sound business model, especially when a small push/investment from a company like Amazon can put it at the forefront of leading the development of such technologies and, hence, enable it to provide such services at a much larger scale.

    Sorry if I should have researched this further or missed anything!

  4. Charles Fitzgerald Avatar
    Charles Fitzgerald

    Thanks and welcome to team CAPEX.

    I was probably too droll in this post. The comparisons are ridiculous but I didn’t draw out the explicit conclusion. The COSS companies argue they deserve to have the service business for their bits, yet operate those services on the hyper-scale cloud players’ infrastructure as opposed to building their own. This is a crummy strategic position (it is like being an MVNO), especially when the traditional obligation of being an OSS company is you at least nominally sign up to let anyone else use your code. The fact some companies are better positioned to offer such services (global footprint, huge economies of scale and scope, single pane of glass, single bill, tight integration with lots of complementary services, etc.) is problematic. I don’t think you can say they don’t compete: they both run cloud services. Like any software company, the cloud vendors are highly incented to move up the stack and cater to their customers’ desires for higher level services. If there is demand for Mongo or Elasticsearch, why shouldn’t they offer managed services for that software?

    I’m old enough to remember all the noble rhetoric in the early days of open source. Free speech vs. free beer vs. free like a puppy, etc. Now it is a grubby discussion about who is and is not entitled to make money from the ostensibly open code. But whatever principles you want to invoke, it doesn’t change the relative strategic positions of the COSS companies vs. the clouds.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Get Updates By Email

Discover more from Platformonomics

Subscribe now to keep reading and get access to the full archive.

Continue reading