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.

M.C. Escher’s “Ascending and Descending” lithograph. March, 1960.

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):

Visualization of common business model progressions taken by commercial OSS companies.

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:

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:

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… 😏