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.
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.
I would love to hear thoughts on this approach!
1 - https://www.envkey.com/
2 - https://www.enterpriseready.io/