How to build an open source business
ockam.io
ockam.io
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.
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.
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.
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.
As I understand it, Ockam has three products:
1. The Cloud SDK: Think Okta / Amazon Cognito but for services.
2. The Edge SDK: Think Okta / Amazon Cognito but for Mobile and IoT devices.
3. The Embedded SDK: Think Google Conscrypt but uses strongest available hardware primitives wherever available.
Always assume someone else did it better. Have a nap instead.
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.
This is an excellent one liner and makes what you do much clearer then what's on the website.
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.
Checkout our github repo for how we're building all of this: https://github.com/ockam-network/ockam
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'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.
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.
I think that the '20s are going to be exceptionally exciting for license models. We have our eye on all of these.
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.
Check out how Peter Levine talks about the 3 'eras' of OSS Companies. I elaborate here: https://www.ockam.io/learn/blog/zero_ipo/#peter-levine---par...
And there is a direct link to his perspective here https://a16z.com/2019/10/04/commercializing-open-source/
Just wondering, why did you choose Github to build your community? why not 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.
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 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.