Product
BlogDeveloper ResourcesPricingCompany
Enterprise-ready Single Sign-on
Katanémo supports SSO for OIDC and SAML compliant Identity providers
Katanémo supports SSO for OIDC and SAML compliant Identity providers
.png)
This post summarizes my remarks on Linkedin about open-source; given recent developments in licensing changes of popular projects (cc HashiCorp). In no way, should this post reflect negatively on the bravehearts of open-source, fighting dearly to protect the freedoms that we enjoy as developers. This post is about preserving confidence and trust in open-source, being honest about how to build value long-term, and why Katanemo chose to be closed-source.
Companies operating under the banner of "We ❤ Open Source", especially VC-backed ones will get put on trial soon. Because open source (the software) is not a business model, and if used as a distribution strategy to upsell cloud-based services (the product) then vendors must accept the fact that their contributions can become a source of serious competition.
We are part of an important phase in building and delivering software. With recent licensing changes made by HashiCorp to protect its commercial interests (via the Business Source License), and the one made by MongoDB to protect its business from large-scale cloud providers (via SSPL) - it has challenged the romantic nature with which developers adopt/build open-source software (OSS) projects. I might go as far as to say that it might end the era of OSS.
So what is OSS romanticism? And how did it start?
Punitive licensing terms, messy commercial contracts and accessibility (or freedoms rather) were among the few reasons that gave birth to the rise and popularity of OSS. Many developers of free software were heartened and encouraged by a resulting cooperation from their peers, which challenged old-guard tech with powerful alternatives like Linux (v. Windows), Tomcat (v. IIS), etc.
With the rise of OSS software, so came with it the rise of licensing terms like Copyleft (GPL) vs. Permissive (Apache2.0). You can read about the differences at a later time. But in the early day some licenses embraced being delivered through a publicly accessible networked server. In those days, the aggregation effect of large-scale cloud services wasn't a reality because infrastructure wasn't yet a commodity.
Cloud companies took advantage (and rightly so) of the fact that the software was open and free, and built massive businesses quickly by offering a product with a predictable supply chain (updates, security fixes, perf, etc). They commercially benefited from the work of the community without being obligated to share any bounty with its contributors. But open source projects were never about price, it was about freedoms.
So why are open source projects like Terraform and MongoDB changing those freedoms through new licensing terms? Because they moved past supporting freedoms to building a commercially viable business. However, the road to a commercially viable business was traveled fastest via community and gain distribution was to go open source. Why? Because the knock-on effect of something being free, trustworthy by the community and generally of high-quality removes barriers for adoption.
A change of terms is a breach of confidence and trust, and what people expect from OSS projects when they adopt them. So what's the fix?
It's a tough question to answer. But it starts with recognizing project goals, and working backwards from a great customer and developer experience. Project owners must be honest with themselves: are they doing this to further freedoms of open source development or for commercial reasons. And project owners must recognize the difference between source code and software products - the latter is six 9s of availability, day 0 exploit fixes, and the full software supply chain etc.
Doing OSS because it helps with distribution is where some developers are stuck today. We want the network effects of OSS but not the competition. But we can't have it both ways unless we breach the confidence and trust of developers by changing terms. Not to mention the collateral damage to other well-meaning OSS projects.
If the goal is to build a commercially viable business, then there are other ways to deal with distribution. A generous free-tier, usage-based pricing, and all the properties that services like Stripe, Twilio and AWS offer. For example, Katanemo's pricing plans are designed to meet where developers are in their business lifecycle. Their customer adoption phase is on us (when their customers are just kicking the tires), followed by our generous pricing tiers where developers can effortlessly scale enterprises with desirable and dependable security and governance features for their service.
This is where understanding differences between "software source", and "software products" comes to fruition.
In some ways I think MotherDuck and DuckDB might have gotten this right from the get go. The former is a well-intentioned commercial offering with trademark rights to distribute DuckDB and the latter is an effort to further the freedoms of developing software in the open. There is no confusion or blurring of boundaries (as I see ) between what developers will get when they interact with the two. And before them, the distinction between the CentOS operating system and Red Hat Enterprise Linux also successfully implemented this pattern before MotherDuck and DuckDB.
I thought about it several times before picking the title of this post. Because closed-source could elicit a visceral reaction. Open source feels more pure, more transparent, and feels aligned with the freedoms that developers want. Are those not our values? I could have also chosen to say we are “serverless” (because we are) and align to a modern framework that developers have established when evaluating between build vs. buy decisions.
But I thought it was important in the context of what’s happening in open-source to make a clear distinction on how we are using a closed-source approach to deliver value. We have full intention to be a commercially viable business, and the way we will deliver value is by taking a deeply complex system - with many moving parts - and exposing a simple API that gets the job done. In our case, building a multi-modal identity and fine-grained permissions service, is work in scaling and securing a permissions store, policy store, identity meta-data store, authorization decision point, fast and efficient caching, and making sure that our control plane and data plane architecture purr like a kitten ensuring x 9s of availability for our developers.
If you are familiar with the popular open-source project Apache Kafka, you should read about the challenges that have exhausted many an engineer on the path to successful data streaming. Why? Because that project solves a deeply complex distributed systems problem. It's fully open-source, and as I mentioned above, source code isn’t the product. It's not the supply chain that delivers value - building a highly reliable and durable data streaming solution that is resilient to version upgrades, day 0 security exploits, achieves 6 9s of availability and achieve peak performance in a multi-tenant scenario is a product.
We want to give developers new freedoms by not having to wake up early in the morning to patch nodes and servers. Not having to worry about backwards compatibility issues. Always improving price/performance via efficiencies offered by scale, etc. We want to compress complexities of infrastructure via a simple API. This isn’t a new idea. Stripe, Twilio, Snowflake have built developer-loved products using this approach. And we have taken an API-first approach to reimagine the role of infrastructure for SaaS apps - starting with unifying the complex and fragmented state of identity and fine-grained permissions.
So is Katanemo void of open-source development? No. We will push tools and frameworks fully in the open. For example, the way we use a serverless architecture to invalidate and update cache will be developed in the open. We believe there are a lot of use cases outside Katanemo that will benefit from such an approach. Also, if you read our post about using OpenAPI and GraphQL as the foundation for our permissions language, or our manifesto you’ll see that we have bet big on open standards to usher in a new era of innovation for developers.
We are trying to be honest about our goals. And hope that the developer community takes notice that we are making the complex, simple. That's also a form of freedom.
OSS and cloud services are inextricably linked given the aggregation effect of large-scale services on low-cost infrastructure. But I think there are bridges between these two islands. And we as a developer community must be honest with ourselves on what we are out to achieve.
