I'm all for open source software but this feels like an awfully contrived way to make a profitable business.
18-36 months between each stage? This feels perhaps tenable for VC backed corps but for anyone bootstrapped, this is a long, long road.
I'm not remotely convinced that these steps feed into each other in a more pragmatic way than... I guess any other way? Couldn't you start with enterprise sales and move backwards, releasing your stuff as OSS once you're running a stable business?
The thesis seems to be that without community and a proven track record, you can't make money organically, which is patently false and proven by hundreds of businesses that don't have OSS/communities. Also, SaaS seems tangential to Enterprise sales in many cases, they're often times different segments (i.e. I won't consider your SaaS since I must be on-prem) -- if you only serve one segment, you're only missing out on the other segment, not cannibalizing? This is all hand-wavey of course, but I posit that this is a way to maybe build an open source business, but I'm not sure it's a solid, proven recipe by any means.
Maybe once Ockam knocks it out of the park in their IPO we can look back on this with greater confidence.
I run a company that organically reached self service SaaS and inside sales. We make borerline developer tools and an open source strategy is very tempting because selling horizontally (Not to a specific vertical) is really hard. Here's a long rant on my thinking about this ( a topic that's been on my mind a lot)
In our case, we make NLP tools, loads of companies have text and data scientists and our tools should be a good fit. But during a potential customers development journey, the buying window is small, they need to know they have the problem we solve, know about us and also not have found or planned an alternative solution yet.
That in turn makes things hard, because often times potential customers come to us too early in their journey to derive value from our product (we make sense when you have N>3 people doing stuff). It makes onboarding and first impressions really hard, because the user knows they might need this one day but isn't in a state to reach wow right now and leaves with an underwhelming first impression.
Open source is very tempting because it looks like it can circumvent those problems. The entry point into an organization becomes the mind of developers and practitioners (as opposed to our slightly more senior buying persona).
The aha moment for that persona is different, and because the persona is a developer and the product is a developer tool the aha moment is easier to convey in an open source setting.
Said differently, in developer tools the buying persona and user persona are different. Often you can reach the using persona but targeting the buyer from day 1 will lead to underwhelming results. Open source let's you capture the minds and hearts of your users, which god willing, will champion your product to the buying persona of the org.
I completely agree with the buyer v user persona distinction. If I were on a podcast and someone flipped a coin...heads I argue that Ockam is a B2C company, tails I argue that Ockam is a B2B company - I could do both.
"Freemium" is a good product model in this case, regardless of the OSS part, because "freemium" isn't a pricing model, it's a customer acquisition strategy.
Thanks for the note and for partaking in this discussion!
The intent of this post was to share our route. There are all sorts of routes to multiple destinations. This is the flight plan we are choosing for our specific objectives.
IMO very few things our zero-sum. Just because we pick this path doesn't mean that others are wrong or invalid. This route is based on my past experiences, which heavily influence my assumptions.
Interesting post. We're also building a business based on open-source / open-core software and have managed to build an active Github community around our first product (Klaro - https://github.com/kiprotect/klaro). It's a pretty simple tool that helps organizations to manage consent and protect their user's privacy on their website. We have other, more complex products in the making as well (e.g. https://github.com/kiprotect/kodex - a privacy engineering toolkit). What we found during the development of Klaro is that even a very simple product can require a tremendous amount of work to turn into a functioning product. I think we're almost there now but it took several months of building and refining.
For me, the main benefit of developing in the open is the great feedback and contributions we get from our community. A lot of people have reached out to us based on our open-source work, I don't think this would've happened if we had developed a closed-source tool.
OP, assuming you are the author. This is obviously the work of someone that has lived open source for a long time, and not the musings of a market analyst or investor. The product focus suggests tactical lessons-learned driving the broader thesis outlined here. What's the origin story on the piece? I'd love to see a follow-up piece one those lessons-learned.
Thanks! I happened to have a unique seat in the OSS world for the past 10 years, and worked with literally hundreds of companies across Heroku Add-ons, and Azure's pivot to an oss partnership strategy. I was a product manager, so as you point out I see the world through a product lens. Most interesting were my vantage points into GitHub, Docker, Mesosphere, CloudBees, jFrog.
This post was already long. It started off as a single slide and turned into this 2500 word blog. You are pulling the thread on a major part that ended up on the cutting room floor - the back stories on some of the companies that I worked with, including the aforementioned.
I read the website multiple times but I still can’t grasp what is your product exactly and what does it solves. Can you provide examples of how companies are using ockam? Thanks
Basically, we abstract away the complexity of networking security for application developers. Let's say you are building an application that has 2 parts: A weather sensor in a field and a InfluxDB instance in AWS. The application logic is simple. Every 60 secs send a reading to the DB. Most developers could write that logic. However if you want to end-to-end encrypt it across multiple network hops, you need to go find a networking security team with expertise in cryptography. That's hard. OR you simply add some Ockam code to each endpoint and voila you have e2e channels.
To put it another way. Stripe lets an app dev process payments without understanding payment networks. Ockam lets you secure edge to cloud applications without understanding network security.
We are building open source SDKs is multiple languages, for multiple environments to enable the following 3 things:
1. Generate, store & use secret cryptographic keys safely - in hardware or behind a tighter security boundary. There are Add-ons for Crypto Hardware Modules, Secure Enclaves, TPMs, TEEs, HSMs etc.
2. Use the above safely stored keys to establish secure, mutually authenticated, end-to-end encrypted channels. This secure channel protocol is decoupled from the network protocols which allows the secure channels to span across multiple transport layer connections and networks.
This is kinda like an end-to-end encrypted connections that are established when you use signal or whatapp messaging ... but in our case we enable that between IoT devices and services and make it easy for application developers to have granular control on it.
Imagine for example an end to end encrypted connection between your phone and your connected door bell - so the vendor of the door bell can help route the data but cannot see/store/modify/analyze the video data outside your door.
In a hospital, a patient's private data is not exposed to every device or network or vendor in the path of collecting that data (there are typically 100s of such parties), it could instead be revealed only to the patient and their doctor.
In an industrial setting, control commands to a critical machine cannot be compromised by compromising a weak network in the path of the command or business proprietary data is not revealed to every device or network vendor in the path of the data - instead they only get maintenance access to the component they are responsible for.
It's important to note here that confidentiality is only one guarantee that is provided by encryption, the other two guarantees of data integrity and authentication are critical components that are missing in a lot of deployed IoT today.
Our goal here is to give IoT application developers granular control to apply the Principle of Least Privilege to their IoT systems - which usually today have wide open attack surfaces with thin/weak boundaries.
3. Equipped with the above two foundational elements we want to enable easy solutions to scenarios that are very common in IoT. Usually application developers end up having to design ad-hoc solutions for these, our goal is to provide open source, vetted solutions for these common scenarios, for example:
Bootstrapping Trust / Device Enrollment in IoT is very hard at scale - to have cryptographically secured, mutually authenticated channels one has to some how generate unique keys in thousands/millions of devices and bootstrap trust between devices and services without leaking these keys, we are building an enrollment protocol based on Signals X3DH to make this as simple as calling a few functions.
Key Management is very hard at scale - Once you have unique keys provisioned in thousands/millions of devices, this only provides security for a short period of time ... you have to think about secure rotation and revocation of keys without physically touching every devices (which is cost prohibitive)... we are making that as easy as calling a few functions.
Authorization is very hard at scale - IoT systems have a variety authorization use cases .. I might want to authorize a friend to use my car, only for a day, without giving them my cryptographic key forever ... An industrial maintenance engineer may only be authorized to see internal telemetry data of a machine for a day etc.
We are building a general solution of such exchange of credentials and capabilities that is secure, provides granular control and respects privacy.
Marginally related, but something I've been curious about:
With the recent news about things like the TSL (Timescale Licence), BSL (Business Source Licence) maybe?, and other such licences, is there anything that's more general that covers the "you can use this but not sell this-as-a-service" use-case for a broader category? For a contrived example, if I were to make a geolocation-by-IP API as an open-source (source-available?) product, and I wanted to run a business around it, but didn't want a cloud provider to just snag it and offer it unmodified, what licence would I use?
I don't have a direct answer but want to offer a different perspective.
I've been working on an open source search engine for a few years (https://github.com/typesense/typesense) that's far more easier than Elasticsearch for a number of use cases and is a great alternative to Algolia.
I was faced with this same dilemma when I started out: how do I protect future commercial interests without stifling the spirit of open source? Eventually I just chose good old GPL and decided against BSL-like licenses for a number of reasons.
GPL is a fine balance. When you are small, your greatest risk is not an existing or future competitor: it is death by obscurity. To that end, you don't want to slow down adoption by choosing a license that screams "$$$" or makes somebody's legal team uncomfortable. In any case, if a big company wants to copy you, they will and can with the resources they can throw at it.
I think (A)GPL is great for standalone software, i.e. tools that don't get integrated into a codebase but used as an external service. Databases or your search engine are great examples for that.
For anything that should be integrated into the codebase of your customers I'd recommend a weaker license like MIT or BSD, as most companies shy away from integrating GPL libraries into their codebases for fear of contamination.
That is an interesting perspective. I would be that your product has well defined interfaces that would make integration with a commercial product easy. Plus I guess you could always dual license.
I think the secret behind making open source profitable is bringing it to the enterprise level. At first I didn't believe you can make a lot of money with open source but after Red Hat got sold for $34 billion I changed my mind. Also GitHub getting sold for $7.5 billion is pretty impressive.
I recommend watching Bob Young's presentation "So You Want To Start an Open Source Company" on YouTube[1], he is the co-founder of Red Hat.
Red Hat is both a great example, and a horrible one all wrapped up into one. They are the OG, but I'm very skeptical that a new project could take the Red Hat 2000s playbook and apply it in the 2020s.
Interesting post! Resonated quite a bit with us at Ionic (we commercialize Ionic Framework and tooling/products around it) and have experienced every one of these steps to the letter (now in the enterprise step)! Very cathartic and insightful.
Not OP, but I would never try to build an open-source community on Slack.
I'm not going to pay $6/month for each person who wants to sign up to check it out, and I'm not willing to lose message history (quicker and quicker as popularity increases). If someone comes in with an issue it sure would be nice to be able to refer back to the conversation when somebody else had a similar issue two months ago.
100% - the slack pricing model doesn't work with OSS communities.
Also it's a lot of overhead to join a new slack group for a random comment. It makes sense for the discussion to happen in the same environment as the code.
We use Slack internally at Ockam. The original community was on Slack as well.
We moved our community chit-chat to GitHub when we were invited to the Discussions beta. The main reason why I like it: It moves discussion closer to the code. Specifically it creates a nice swim lane next to `Issues`. I think of a progression of `Discussion` => `Issue` => `PR'. It gets discussion out of issues and PRs and declutters comments.
18-36 months between each stage? This feels perhaps tenable for VC backed corps but for anyone bootstrapped, this is a long, long road.
I'm not remotely convinced that these steps feed into each other in a more pragmatic way than... I guess any other way? Couldn't you start with enterprise sales and move backwards, releasing your stuff as OSS once you're running a stable business?
The thesis seems to be that without community and a proven track record, you can't make money organically, which is patently false and proven by hundreds of businesses that don't have OSS/communities. Also, SaaS seems tangential to Enterprise sales in many cases, they're often times different segments (i.e. I won't consider your SaaS since I must be on-prem) -- if you only serve one segment, you're only missing out on the other segment, not cannibalizing? This is all hand-wavey of course, but I posit that this is a way to maybe build an open source business, but I'm not sure it's a solid, proven recipe by any means.
Maybe once Ockam knocks it out of the park in their IPO we can look back on this with greater confidence.