Like most things in life, progress happens gradually on a spectrum of iterative changes over time. The same is true for business model evolution in commercial OSS companies.

In this post, we’ll explore the following at a high level and reserve greater detail for future posts:

• What: Defining common commercial OSS business models and differences between them: services, support, product variations (open core, cloud, SaaS) and the “in-between”.
• How: Progressions and combinations of these models, viewing them from a lens of gradually increasing “abstraction” as companies experiment and implement them.
• Why: I actually won’t go into much detail here since if I did for each model it would balloon this post way past 2,000 words (already breaking my 500–1K word rule) to probably 3–4X that, but… deciding which model is best for a given OSS project (as a founder/creator/developer, etc) should be a function of market “pull”. If you have a sense of critical mass use of the OSS, you should best be able to contextually infer which model, sequence of progressions, implementation approach, etc. makes sense.

Continuous business model progressions

I have scoped the following progressions based on what looks like an ascending sequential order, but many companies choose to start off directly with building a Cloud or SaaS product, ignoring all ‘previous’ steps. There is nothing wrong with this. However, observationally, after considering the many data-rich examples in COSSI over the past several years, the following logical evolution of business model experimentation many commercial OSS companies go through has been / is fairly consistent (again, from what I have observed):

Let’s dig in! Starting with Services through to SaaS:

Services (Training, Consulting, Workshops, etc.):

• Most commercial OSS companies start experimenting with a business model by helping users of their OSS project learn, adopt / implement, integrate and run the OSS. This usually means the company offers a set of human-capital / resource-bound offerings that are explicitly only linearly scalable, meaning that the company needs to fundamentally hire more delivery people / customer success resources to scale operations relative to the number of customers / engagements. These offerings include (but are not necessarily limited to) training (tutorials, workshops, classroom-style roadshows, custom SOWs), implementation services (on-site or remote professional consulting agreements for security audits, systems integration, etc.), architecture reviews (also scoped SOWs) and more. These engagements with early adopter enterprise users of the OSS also afford a glimpse and valuable insight into pain points and challenges companies face when adopting the OSS which can often serve as a solid basis for learning about / extrapolating product design considerations. Hence, this often being the “first step” in the perennial Penrose staircase.

Support (SLAs):

• As a subsequent set of offerings, many companies are drawn to offer support SLAs which guarantee different levels of response times to engage a customer when an outage occurs when using the OSS in production or other sensitive environments. Detailed support tier examples of SLAs that are offered by both open core and pure OSS subscription based businesses can be seen with Talend and Hortonworks, respectively. There are many other examples in COSSI since support is a very common line-item offering for customers who are happy to manage, run and configure the OSS themselves, but simply want to contract with a/the vendor behind the OSS in order to mitigate some risk of ops knowledge entropy and/or stability liability.

Packaging (Installers, binaries, images, etc. — less commonly: hardware appliance):

• Packaging very often comes after the learnings from a number of services and support engagements / customers and usually entails a number of things wrapped around the OSS project and often (mostly) built and distributed as OSS as well: installers for streamlining the deployment and stand-up of the OSS project on various infrastructures, in various default configurations, etc), executable images/binaries, full-blown “distributions” in the Linux sense but also “un-distributions” where very little of the core OSS changes. Mike Olson, the founder/CEO of Cloudera, once said that the core value proposition of his company was “packaging” Hadoop in a consumable way for enterprise use. Packaging is often something that spans all the steps in this progression analysis I lay out, but I decided to dedicate one step/layer to it since the base functionality added on top of the core OSS project when “packaging” is very seldom held back/made proprietary and is also very prone to commoditization.
• Another way to differentiate at this packaging level is to ship an embedded and vertically integrated hardware-optimized appliance like Sourcefire (now Cisco) does for Snort.

Unified Subscriptions — Services + Support + Packaging:

• Services, support agreements and packaging can all be sold in different ways, but they are typically constructed using different revenue recognition (internal finance mechanism) and customer agreement (external finance mechanism) approaches. Services are often just one-off agreements, support agreements are annual (renewing) and sometimes viewed as a subscription, but are a subset of services. I’ve noticed that once companies figure out how to service customers using the first three steps of the progression, a “higher level” unified subscription offering often arises as a result of combining all the previous steps into one offering: unified annual subscription that includes a level of professional services, training, support SLA coverage and access to some tooling/extensions for making the deployment and management of the OSS easier in various environments. These subscriptions are built as a way to express “continuous levels of service” to a customer in a simpler to reason about way with less disjointed and complex pricing negotiations.

Open Core (everything before ++):

• As subscriptions begin to grow in number and complexity, commercial OSS companies soon appreciate that most of the simple features and value provided to customers on top of the OSS project in all the previous steps are necessary but not sufficient for catering to broader more complex needs. Enter the realization “open core” (many companies still refuse to call it this, which bugs me) as the next natural progression. So, what is open core? Well, the previous post went into some detail. However, I’ll add more thoughts here: Usually, in the open core model, there are a set of differentiating (against the OSS core) features that almost all customers need and want (i.e. are highly generalizable) — these features very often boil down to three major categories: Collaboration, Management & Security:
• Collaboration happens when a number of independent end users/consumers within a given enterprise have deeply committed to using the OSS project in question, but in order to work together more effectively and efficiently across Team/org/functional boundaries, additional “control plane” functions would very significantly simplify many workflows. Shared repositories, unified visibility of artifacts, job scheduling primitives and more.
• Management is a subsequent / complimentary category where additional enterprise features materialize: how can the IT leadership/platform teams “control” and “govern” the way the OSS project is consumed and used by the teams across the company? RBAC, ACLs, LDAP/AD integration, AuthN/Z, end-to-end encryption, etc.
• Security is quite obvious: companies want to provide security guarantees that conform to their standard practices and regulatory requirements, and there are a long list of features to enable this.
• For a great view into many of these “enterprise readiness” checkbox features that large companies look for when adopting OSS (or really, many new software products in general), the great folks at Replicated have sponsored the creation and maintenance of EnterpriseReady.io: While this site focuses on “SaaS” as the main keyword, most of the features here break down to what is often implemented over and over again by every commercial OSS company out there — for their respective OSS projects when used on-prem, in the cloud or elsewhere. If only we could see some standardization of implementation patterns here! Of course, making AuthNZ work for an OSS CMS is different than for an OSS middleware system.. the users, integrations, use cases and layer of abstraction/intensity of consumption by various constituents is highly contextual, so this is probably why we’ll likely never see standardization here on “enterprise readiness” functionality across vendors.
• Open core requires “master” software license agreements (MSLAs) to be created by each commercial OSS company (and each MSLA is different) for licensing the commercial (proprietary) software that is layered on top of the OSS core (retaining the same underlying permissive license, Apache 2.0, GPL, etc.). These custom MSLAs enable selling open core-based products into procurement groups, and they are quite complex and require legal teams with experience in setting warranty, IP and indemnification levels (indemnification being a topic reserved for a future post; deep stuff here!). These agreements carry terms and conditions that are regularly negotiated by procurement / asset management departments at large enterprise customers when strategic / significant transactions (say ~$200K+ deals) are being signed.

Managed/Hosted Service (“OC-as-a-Service”):

• Fully managed “pseudo-cloud” based offerings in this model are essentially hosting the open core bits as a dynamically scalable “image/appliance” on a cloud provider. This does not mean the OC product is built explicitly to be consumed in a multi-tenant, elastically scalable and highly abstracted (from the infra primitives) manner. Vendors often abstract the VM/infra-config level details from customers so the UX is closer to “give me 10 instances of the OC product and scale it based on my requirements”, but the *aaS model goodness basically stops there.
• I think of this approach as a “cloud appliance” version of the open core product. Not quite a full cloud offering, but much less friction to run and consume on demand vs. purchasing a license and a separate services engagement to deploy and configure the product.

Examples:

• Kafka-as-a-Service — Confluent Cloud: https://www.confluent.io/confluent-cloud/
• Cassandra-as-a-Service — DSE: https://www.datastax.com/dmc-service-description

Native Cloud Offering (OC-aaS ++):

• As an extension of “OC-aaS” in the previous “managed/hosted” service step/approach, a “native cloud offering” really means that the OC product was likely designed from the ground up for the cloud with the essence and experience of the OC features in-tact. This does not necessarily mean that the OSS went through the evolution in all the previous steps. This does essentially mean, however, that things like rich user+app-level multi-tenancy, choosing which cloud provider to run the product bits on, etc. are usually not so configurable.
• OSS cloud offerings here are usually implemented by leading cloud providers, as is evidenced by the two examples below. However, I strongly believe that in the future, companies like Upbound will deliver a vastly superior UX, portability capability and reliability/durability guarantee than single-cloud-based OSS offerings. We’ll explore this more in a future post on “next-gen” commercial OSS business models.

Examples:

• Kubernetes — GCP GKE: https://cloud.google.com/kubernetes-engine/
• Postgres, MySQL, MariaDB — AWS RDS: https://aws.amazon.com/rds/details/

SaaS Platform/App (Cloud + App-level abstractions):

• As perceptively the “ultimate” (but not really) step in abstracting all previous steps, a SaaS platform approach means the core OSS project is fundamental to the platform, but almost completely hidden from the UX of the product/app itself. Only advanced/power users even need to really know the core primitives and workflow of the OSS project powering the SaaS platform, which is still geared toward the same set of end users/engineers, but is as “declarative” and automated an interface as is possible.

Examples:

• GitHub — An app-level social network for code built on top of git; a very large % of GitHub users have no idea how git works.
• Fastly — No need to know how Varnish works in order to use the Fastly CDN.

Evolutionary Analogy

As the basis for explaining these business model progressions, I use a continuous staircase analogy found in Penrose stairs — also the inspiration for Escher’s “Ascending and Descending” lithograph, depicted in the opening of this post. Why? Because there is no “final step”.

Business models, not unlike machine learning models, are continually fine-tuned as data inputs inform assumptions and optimizations. Many times, current models incorporate previous models designs, building on them, synthesizing and fusing ideas.

Sometimes, though, stairs aren’t for ascending… 😏