The terms used here (SaaS and Open Core) are orthogonal. SaaS is a way to charge for software, Open Core is a way to license one. The comparison between them is of the apples to oranges kind — not very meaningful.
Instead, what it is alluded here seems to be a comparison of hosted-only SaaS versus hosted and on-premises SaaS (SaaS v2?) on the businesses' infrastructure. The fact that the latter appears more often in companies that open source some parts of their stack is probably coincidental.
If anything, this is what my startup is doing, as well, so I'm speaking from personal experience. As a live example, we open source product for public mass communication (Aether, https://getaether.net), and a hosted or on-prem SaaS for professional, private use cases like within-company comms (Aether Pro - still in development).
This is useful, because not only it provides value for the public (open source part), it also is useful for businesses, in that it removes the burden of implementation, while allowing the companies to still retain their own data by hosting it on premises or on their own clouds in an airgapped manner.
Had it been a regular SaaS, this would have been impossible.
> The last 30 or so years have been a lopsided tale of OSS creating a lot of value and SaaS / IaaS capturing most of it.
Well said. It is easy to forget that all that software that is running the cloud providers' machinery was in many cases started by enthusiasts that simply wanted to scratch their itch.
It is interesting that only a few businesses from the list of $100M+ OSS companies didn't receive VC funding. Also some of the facts are... weird. Mozilla financed by "Ads/Royalties"? Also, Coinbase? Maybe I just don't understand the contents.
Author here. As an intro, this is admittedly high level but hope to get more in the weeds on how the two models compare and overlap in the next few posts. Happy to discuss some of my (or your) thoughts here in advance of those. Thanks for reading!
This is a great article and I have been observing these trends and tradeoffs from my vantage point in the ecommerce platform landscape having worked across all models. I am very interested in thinking through what Model is next. Most break out companies have done so on business model (vs feature) innovation. I'm looking forward to reading more... and always happy to collaborate on thinking.
Interesting and I think I can guess where you’re heading. But would have been better to publish all posts at the same time. Right now it get’s cut off early.
I work with Salesforce and here's the reality: they are as closed source as possible. 'No software' logo and marketing campaign was targeting sales and marketing people with an appealing idea that they no longer need to rely on IT to get shit done.Reality is that any larger organisation adopting Salesforce would end up using developers for integrations and customisations that are beyond so called point and click. 'No software' has been phased out gradually and replaced with nice looking bears,goats and etc..
In most cases, open source means it is a commodity and the business makes money from related offering. A good example is JetBrains.Kotlin language is their commodity,while the IntelliJ IDE is the product.
This topic has been on my mind a lot lately. At EnvKey[1], we're gearing up to launch a long awaited v2 which focuses on making our developer-friendly configuration and secrets management tool robust and flexible enough to be used by large organizations in addition to smaller teams.
We’ve been checking off most of the items on the EnterpriseReady.io list[2] along with some stuff that's more specific to our product like a CLI, update hooks, and configuration 'blocks' that can be shared between multiple applications like modules. We want to be the full-spectrum solution for all things configuration and secrets--for any size team.
Keeping the user experience and developer experience simple while adding enterprise and power-user functionality is a challenge for any evolving product, but by far the toughest technical and strategic challenge has been how to approach flexible data storage, flexible hosting, and the open source vs. closed source vs. source available question. It's obviously a very important issue for customers and has huge implications for both the product and the business. On top of all that, it's an issue at the forefront of the tech Zeitgeist these days that has been producing tons of drama and soul-searching as we see one high profile licensing change after another. Whatever we decide, we’ll be making a cultural statement.
So here's our plan. I'm hoping it can thread the needle of giving customers what they want while still allowing us to maintain a strong strategic position as a business.
1 - We've split our server-side functionality into two independent services: a storage service that runs on serverless/NoSQL (responsible for storing end-to-end encrypted config/secrets), and a metadata service that runs on PostgreSQL and application servers inside Docker containers (responsible for authentication, authorization, and maintaining the hierarchical 'graph' that represents all an org's configuration and secrets).
2 - Either of these services can be self-hosted (in your own AWS account) or cloud-hosted by us. You can let us manage everything for a pure SaaS experience, host your own serverless storage gateway for encrypted data while letting us handle auth/metadata/running and scaling application servers (hybrid SaaS), OR just run everything yourself. You'll have this flexibility regardless of how much you pay us, even on the new free tier we're planning to introduce. Where EnvKey runs and stores its data will be completely up to you.
3 - All EnvKey client-side code will be Open Source (this is already the case).
4 - Both the storage service and the metadata service described above will be Source Available but not Open Source. You'll have full access to the code and we'll accept pull requests etc., but you'll need a license from us to run it, and you'll only be allowed to run it for its designated purpose: self-hosting one or both components of the EnvKey server.
Hopefully this will strike the right balance. It allows us to run a company that is transparent, open to contributions, and mostly aligned with the Open Source ethos while still maintaining enough ownership and competitive advantage to put us in a strong position as a business.
Not being a fan of SaaS, I applaud your intentions, but want to add a note of warning.
As a case study, Atlassian do 'source available' with self-hosted or cloud-hosted options. This is a result of history, and I suspect Atlassian wishes they were cloud-only. The self-hosted option is de-emphasised on the website, costs more than SaaS per-user at most usage points. The Cloud product codebases has been totally redesigned over the last 10 years for horizontal scalability. Cloud-only features are rapidly being added, while development on the self-hosted codebase languishes (Atlassian's public bugtracker is full of trivial feature requests ignored for years, my favourite being https://jira.atlassian.com/browse/CONFSERVER-27618).
As for source code for self-hosters, while the bulk of it is still available, it isn't buildable because Atlassian routinely neglect to publish build dependencies, and they don't publish source for new libraries like Confluence's real-time editor.
In Atlassian's defense: consider the costs of offering self-hosted. SaaS products these days are built on top of other IaaS and SaaS: you can't do that without adding abstractions (docker/containers) or finding self-hosted equivalents. You need to maintain installation and administration documentation, and offer support for weird customer-environment-specific problems. Your build infrastructure needs to spit out both SaaS-deployable and self-hosted versions. Your billing systems need to handle both cases. Even your license agreements need to address two possibilities.
OTOH, while software companies love SaaS, many of their customers (particularly large, conservative ones) do not. Having a self-hosted option can thus become a competitive moat, since 99% of your competitors won't offer it.
So good luck with your strategy, if you feel you can pay the costs of offering that flexibility.
Instead, what it is alluded here seems to be a comparison of hosted-only SaaS versus hosted and on-premises SaaS (SaaS v2?) on the businesses' infrastructure. The fact that the latter appears more often in companies that open source some parts of their stack is probably coincidental.
If anything, this is what my startup is doing, as well, so I'm speaking from personal experience. As a live example, we open source product for public mass communication (Aether, https://getaether.net), and a hosted or on-prem SaaS for professional, private use cases like within-company comms (Aether Pro - still in development).
This is useful, because not only it provides value for the public (open source part), it also is useful for businesses, in that it removes the burden of implementation, while allowing the companies to still retain their own data by hosting it on premises or on their own clouds in an airgapped manner.
Had it been a regular SaaS, this would have been impossible.