Building Commercial Open Source Software: Part 4 — Deployment & Business Model

Building a Commercial Open Source Company

In our time investing and supporting open-source companies, we’ve learned several lessons about project & community growth, balancing roadmap and priorities, go-to-market strategy, considering various deployment models, and more.

In the spirit of open source, we wanted to share these learnings, organized into a series of posts that we’ll be publishing every week — enjoy!

PART 4: Your deployment model is your business model

  1. Serverless does not make a company: Offering a ‘serverless’ managed service for your project can be a significant boon to kick start customer adoption; it’s easy to get up and running, running a sophisticated service 24/7 is non-trivial and removes the operational complexities with devops and infrastructure. At the same time, a hosted open core does not make for a company. Offering a serverless version of your open core can be a great initial start but is not sufficient. You need to ask yourself: can your offering be differentiated enough from a cloud provider offering the same thing? Can a customer scale up on your managed service or will they eventually need to migrate onto their own infrastructure for security, residency, policy, or other enterprise needs? Can you continually build layers of value on top of your open core and deliver them all through the managed service? Or are you really just reselling cloud compute resources from AWS? Companies such as Mongo, Redis, Astronomer*, and Cockroach have gone well beyond just managed versions of their open cores in order to drive value on top of their open cores.
  2. My service, your infrastructure: The type of workloads, users, and use cases should dictate the deployment strategy, and doesn’t need to be limited to managed service or self-hosted. Think about strategies that meet the infrastructure requirements of the customer while making it as easy to deploy, manage, and scale as possible. You might offer managed orchestration but running within the customer’s infrastructure — allowing the customer to host within their cloud account but solving the operational challenges of keeping the service running. Or offer as a private ‘as a service’ for an entire customer organization to run on, making it easy to deploy on any cloud or platform within a customer’s infrastructure.
  3. Security as a deployment model: Workloads running on data centers or in the private cloud still make up 2/3rd of worldwide IT infrastructure. This means it’s highly likely that your customer may be migrating from an on-prem or private cloud instance to your service. Recently VPCs have been the baby-step solution for this, but lack many of the benefits from a multi-tenant, public cloud service. This is where companies such as MongoDB’s Atlas have introduced a pseudo-VPC or VPC-as-a-service like offering with an enterprise-friendly ‘-aaS’ offering but performant, reliable, scalable, and ultra-secure. It’s effectively a fully-managed environment and service, offering the performance, reliability, and scale of multi-tenant public cloud service but with the data security, namespaces, and isolation of a virtual or on-premise private cloud. Some services can now offer network isolation, role-based access management, bring-your-own SSO/SAML, and end-to-end encryption, but on a multi-tenant cloud offering — operating like cattle, not pets.
  4. Support-first is not a death wish, it’s a distribution strategy: Support-focused models get a bad rap, often being called a ‘lifestyle business’, and just enough revenue for a comfortable lifestyle, but unlikely to generate VC returns. In general I agree with this, with one caveat, which is the idea of *starting* with a support-first model to drive broader adoption of an OSS project that is fairly new technology. It’s a compelling way to acquire customers and generate value/lock-in before introducing new closed features that amplify the value of the open core. Heptio was a great example of this (open core + support/services), building a powerful land/expand motion that eventually led to more powerful enterprise features.
  5. Pricing should be a feature, not a bug: Think about your pricing strategy as a way to further reinforce the value you are delivering. Whether you are building a faster DB, a better way to build data pipelines, automation workflows, etc., pricing should reflect how developers use and benefit from your solution. Whether it means charging by instance, consumption, users, volume, features/capabilities, it should be easy to predict and grow as the customer value grows.

Venture Capitalist, Partner @Venrock, writing about software & hard things for developers, space, and modern computing.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store