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.<p>Instead, what it is alluded here seems to be a comparison of hosted-only SaaS versus hosted <i>and on-premises</i> 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.<p>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, <a href="https://getaether.net" rel="nofollow">https://getaether.net</a>), and a hosted or on-prem SaaS for professional, private use cases like within-company comms (Aether Pro - still in development).<p>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.<p>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.<p>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.<p>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!
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..<p>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.
Of course people don't fund open core, look at the stuff even the most succesful open core companies have to deal with:
<a href="https://onezero.medium.com/open-source-betrayed-industry-leaders-accuse-amazon-of-playing-a-rigged-game-with-aws-67177bc748b7" rel="nofollow">https://onezero.medium.com/open-source-betrayed-industry-lea...</a>
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.<p>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.<p>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.<p>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.<p>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).<p>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.<p>3 - All EnvKey client-side code will be Open Source (this is already the case).<p>4 - Both the storage service and the metadata service described above will be <i>Source Available</i> 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.<p>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.<p>I would love to hear thoughts on this approach!<p>1 - <a href="https://www.envkey.com/" rel="nofollow">https://www.envkey.com/</a><p>2 - <a href="https://www.enterpriseready.io/" rel="nofollow">https://www.enterpriseready.io/</a>