5 ms·

I have a single code base [0] for the self-hosted editions and for the SaaS. I split features up across two editions: community edition (CE) and enterprise edit

by ezekg 2y ago

I have a single code base [0] for the self-hosted editions and for the SaaS. I split features up across two editions: community edition (CE) and enterprise edition (EE), and then also two modes: singleplayer and multiplayer (single- vs multi-tenant). The switching is done via environment variables, KEYGEN_EDITION and KEYGEN_MODE. The SaaS offering actually runs the EE edition in multiplayer mode, and is right now the only instance of the EE edition in multiplayer mode (other EE customers are entitled to singleplayer only). I've been running this set up for about a year [1] and it's working well. Having a single code base was a requirement before I made the project fair source [2]; the fair source ELv2 license lets me add feature gates to facilitate this, while protecting me from forks giving away EE features for free (while still allowing forks). Updates are pushed to the SaaS offering daily. I cut self-hosted releases bi-annually unless it's for a critical fix. [0]: https://github.com/keygen-sh/keygen-api https://github.com/keygen-sh/keygen-api [1]: https://keygen.sh/blog/all-your-licensing-are-belong-to-you/ https://keygen.sh/blog/all-your-licensing-are-belong-to-you/ [2]: http://fair.io/ http://fair.io/

scottcha 2y ago
Couple of questions: 1. You link to fair.io but it seems there isn't a latest license there only a legacy version. Do you know what the current status is on what seems like a pending version update? 2. Your project repro actually links to the elastic license. Is there some relation between the two? Do you prefer the fairsource license over the elastic license>
- ezekg 2y ago
  1. You can read more about the Fair Source initiative here: https://twitter.com/chadwhitacre_/status/1790101820364267902 https://twitter.com/chadwhitacre_/status/1790101820364267902 (also [0] and [1] for previous discussions). It's not official yet, but it's an attempt to define a new term for Open Source vs Source Available. I figured I'd start using the term early and see what happens. 2. Yes, the ELv2 will be considered a Fair Source license, because it allows contributions, redistribution, forking, etc. You can visit https://faircode.io https://faircode.io for an idea of what Fair Source will ultimately entail (Fair Source and Fair Code will be merged eventually AFAICT). [0]: https://github.com/getsentry/fsl.software/issues/4 https://github.com/getsentry/fsl.software/issues/4 [1]: https://github.com/getsentry/fsl.software/issues/2 https://github.com/getsentry/fsl.software/issues/2
  - redwood 2y ago
    What was your calculus on ELv2 vs SSPL? The latter feels a better fit for the continuation of copyleft--too close to the fears you mentioned around AGPL?
    - ezekg 2y ago
      I looked at SSPL, but it was really between BUSL and ELv2 for me. I ultimately chose ELv2 because it allowed me to keep my community edition and enterprise edition in a monorepo, where the latter edition is protected by license keys, i.e. ELv2 has a clause to where you can't remove or circumvent the license key functionality. Since Keygen was previously closed source, I didn't want to split the repo up into the ee/ directory structure that you commonly see in other open core and fair source projects. I deemed doing so as 'too risky' -- too much code churn for little benefit -- as those changes would have a direct effect on the SaaS. Instead, I opted for ELv2 because it offered me the ability to say, "hey, I'm making this fair source, do what you want with it, just don't compete with me or remove the license gates for the paid features." Here's some of my internal dialog i.r.t. the license choice: https://github.com/keygen-sh/keygen-api/pull/668 https://github.com/keygen-sh/keygen-api/pull/668
- stevage 2y ago
  Fair Source seems to be pretty bleeding edge: https://github.com/fairsource/fair.io/issues/14 https://github.com/fairsource/fair.io/issues/14
reaperman 2y ago
Could an individual of ill-repute freely download the source containing the EE and edit it to turn off checks for KEYGEN_EDITION and KEYFEN_MODE? Obviously you have license protection against them redistributing the modified version but would anything practical prevent them from running it themselves?
- ezekg 2y ago
  It'd be a violation of the license terms. Other than that, I may send Liam Neeson after them. :)
  - killingtime74 2y ago
    His very specific set of skills is hunting down license term violators
    - cushpush 2y ago
      >...but what I do have are a very particular set of skills. Skills I have acquired over a very long career.
- spoonjim 2y ago
  Almost all software company revenues come from business customers who are too big to mess with stuff like this.
  - Suppafly 2y ago
    This. We have a few different things at work where it would be trivial for me to modify the database to allow unlimited users or grant access we don't pay for, but it'd be mostly pointless.
- komali2 2y ago
  Yes, and most places that do this (e.g. OpenProject) don't have licenses preventing this, so I have deployed, and shimmed out the enterprise blockers, many Foss sass tools.
threecheese 2y ago
We need more business owners like you. I’d never heard of your product (I’m not in an industry that would have one), just read your blog post on the license; I I wish you wild success and I hope more small dev shops will have the same courage and the same outcome. Cheers!
- ezekg 2y ago
  Thanks for the kind words. I've seen quite a lot of open/fair source companies this past year. But I'd love to see even more! (And I'd really love to see more bootstrapped ones!)
abhimanyugrover 2y ago
Say if someone copied your codebase tomorrow, and rebranded it as a competing solution and started advertising on same places as you are, what do you do?
- ezekg 2y ago
  I'd handle it the same any other business would who had their intellectual property infringed upon.
  - jayd16 2y ago
    How would you know?
    - ezekg 2y ago
      How would I know if somebody forked and rebranded Keygen's API to compete with me? I feel like it'd be pretty obvious unless they redesigned the entire API schema, endpoints, etc. Not really something I'm worried about.
    - necovek 2y ago
      If this happens in a market far away that the original product would have a hard time reaching, it does not really matter. But if the original product grows enough to be able to reach far away markets, then it's lawyer and discovery money would grow too. I applaud Keygen API approach, though I really hope we find a formula that makes free software become pervasive while providing financial stability to authors and maintainers.
    - madeofpalk 2y ago
      If you don't know, then it probably doesn't affect you.
ijustlovemath 2y ago
How do you actually protect the CE users from setting the environment variables to activate premium features?
- greenavocado 2y ago
  If you are desperate enough to shim it out you're not worth pursuing as a customer
  - billy99k 2y ago
    Yes, but this will cost money and resources. Large companies can take this as a loss. Small companies will go out of business
    - ezekg 2y ago
      In my case, Keygen is a very critical part of a business -- much like billing -- so making sure it's reliable, secure, and well-maintained is paramount. This fact, in and of itself, weeds out most individuals (and businesses) who want to fork and steal, because then maintenance is pushed onto them or onto an untrusted third-party, which has a non-trivial cost for any worthwhile business. Much less risky to just pay the vendor of the software instead of treading through the risky route to save a few bucks.
- ezekg 2y ago
  Keygen uses Keygen to license itself via license gates: https://github.com/keygen-sh/keygen-api/blob/e668dffbb90bd53a2c6aa040866e4883fa7aab25/app/controllers/api/v1/licenses_controller.rb#L65 https://github.com/keygen-sh/keygen-api/blob/e668dffbb90bd53... (the EE edition requires a license key with entitlements to access the EE features).
Msurrow 2y ago
How do you handle conflicting feature requests from two different paying customers? Like customer A wants buttons in the right, customer B wants them on the left.
- ezekg 2y ago
  I make the choice. I don't really listen to specifics like that from customers. I'm a SaaS, not a consultancy. Instead, I try to fully understand the customer's problem and then provide a solution to it a way that will work for everybody. If it doesn't work for everybody, or is a niche feature, then I probably won't introduce the feature unless I can come up with a way to make it valuable to other customers. Often, the customer doesn't understand the best way to implement something to make it valuable/usable to other customers, or the costs involved i.r.t. to maintenance, but I do. With an API product, you also have to be picky about new features because once something is introduced, it can't be taken back (assuming you want to maintain backwards compatibility).
rjhacks 2y ago
Thanks for sharing, such an interesting approach! At my startup we're currently discussing licenses, this is very inspiring. I have a follow-up question! The reasons for OSS you list include "Bus-Factor", "Longevity", and "Continuity". I'd summarize all of those as "even if they can't do business with [company] anymore, users can continue on" - our customers also say that's very important to them. ... But what if "can continue on" means "need some of those proprietary features"? And you're not there to sell to them anymore? Or you've been acquired by private equity, started charging 10^6x, and users want out? Users aren't allowed to clone the repo, remove your proprietary code, and reimplement it with their own solution, because: > you may not remove or obscure any functionality in the software that is protected by the license key. Is this a thing your customers are concerned about? What do you expect them to do in such a scenario?
- ezekg 2y ago
  I've sold multi-year and perpetual EE licenses for this exact reason -- to reduce risk of eventually losing EE features if Keygen LLC goes under and is unable to renew EE licenses. So in this case, if Keygen LLC goes under, they still have a perpetual EE license that will allow them to use existing EE features. But this is something I've been thinking about lately, and something my customers have been talking about. I want to come up with a better answer other than "well, pay me for a perpetual license and we'll remove that risk." Maybe some kind of clause for a "Change License" in case Keygen LLC goes under, e.g. we go from ELv2 to Apache 2.0 if that happens. I'm not really sure what that'd look like right now, but I'll keep thinking on this and hopefully come up with a good answer eventually. Outside of that, nothing is really stopping somebody from forking Keygen and reimplementing the EE features 'in-spirit' under a new code path, especially if Keygen LLC has gone bust. They just can't remove or copy the existing EE features verbatim.
insane_dreamer 2y ago
I can confirm this approach works. We've been a satisfied paying keygen customer for 6-7 years, long before keygen was open sourced, and the fact that it is now doesn't change our decision to continue to pay for its use. If you have something that works well and fills a certain need, customers are happy to pay for it so they don't have to give any thought to it and can focus on their own core competency.
- ezekg 2y ago
  Thanks for the kind words, and for being a long-time customer (whoever you are). :) I need to send your team some shirts!
  - insane_dreamer 2y ago
    Thank you for a product that is well designed and thought through. Not a common thing these days.
insane_dreamer 2y ago
I haven't heard of Fair Source before -- is it gaining traction? Did you use the "legacy license" (that is linked to on the website)?
- ezekg 2y ago
  It's bleeding edge -- not even "official" yet. It's meant to be an umbrella term to replace the 'open source' vs 'source available' debacle when discussing permissive 'almost-open-source' non-compete licenses like FSL, BUSL, SSPL, ELv2, etc. More: https://twitter.com/chadwhitacre_/status/1790101820364267902 https://twitter.com/chadwhitacre_/status/1790101820364267902
  - deleted 2y ago
    [deleted]
pc86 2y ago
Absolutely lovely website you have at https://keygen.sh/ https://keygen.sh/ Did you write that as well or outsource it?
- ezekg 2y ago
  Thanks! I designed and built the website as well.
jamiesonbecker 2y ago
I replied below about our homegrown solution, but this is very cool! I wish it'd existed when we wrote Userify, but we'll definitely plan on it for our next app! Kudos for solving this so elegantly!
neya 2y ago
Sounds good! Honestly, I may not take this route due to the nature of my product (a self hosted CMS with Enterprise and OSS versions). But very interesting, thanks for sharing!

by ezekg 2y ago

scottcha 2y ago

Couple of questions: 1. You link to fair.io but it seems there isn't a latest license there only a legacy version. Do you know what the current status is on what seems like a pending version update? 2. Your project repro actually links to the elastic license. Is there some relation between the two? Do you prefer the fairsource license over the elastic license>

ezekg 2y ago
1. You can read more about the Fair Source initiative here: https://twitter.com/chadwhitacre_/status/1790101820364267902 https://twitter.com/chadwhitacre_/status/1790101820364267902 (also [0] and [1] for previous discussions). It's not official yet, but it's an attempt to define a new term for Open Source vs Source Available. I figured I'd start using the term early and see what happens. 2. Yes, the ELv2 will be considered a Fair Source license, because it allows contributions, redistribution, forking, etc. You can visit https://faircode.io https://faircode.io for an idea of what Fair Source will ultimately entail (Fair Source and Fair Code will be merged eventually AFAICT). [0]: https://github.com/getsentry/fsl.software/issues/4 https://github.com/getsentry/fsl.software/issues/4 [1]: https://github.com/getsentry/fsl.software/issues/2 https://github.com/getsentry/fsl.software/issues/2
- redwood 2y ago
  What was your calculus on ELv2 vs SSPL? The latter feels a better fit for the continuation of copyleft--too close to the fears you mentioned around AGPL?
  - ezekg 2y ago
    I looked at SSPL, but it was really between BUSL and ELv2 for me. I ultimately chose ELv2 because it allowed me to keep my community edition and enterprise edition in a monorepo, where the latter edition is protected by license keys, i.e. ELv2 has a clause to where you can't remove or circumvent the license key functionality. Since Keygen was previously closed source, I didn't want to split the repo up into the ee/ directory structure that you commonly see in other open core and fair source projects. I deemed doing so as 'too risky' -- too much code churn for little benefit -- as those changes would have a direct effect on the SaaS. Instead, I opted for ELv2 because it offered me the ability to say, "hey, I'm making this fair source, do what you want with it, just don't compete with me or remove the license gates for the paid features." Here's some of my internal dialog i.r.t. the license choice: https://github.com/keygen-sh/keygen-api/pull/668 https://github.com/keygen-sh/keygen-api/pull/668
stevage 2y ago
Fair Source seems to be pretty bleeding edge: https://github.com/fairsource/fair.io/issues/14 https://github.com/fairsource/fair.io/issues/14

reaperman 2y ago

Could an individual of ill-repute freely download the source containing the EE and edit it to turn off checks for KEYGEN_EDITION and KEYFEN_MODE? Obviously you have license protection against them redistributing the modified version but would anything practical prevent them from running it themselves?

ezekg 2y ago
It'd be a violation of the license terms. Other than that, I may send Liam Neeson after them. :)
- killingtime74 2y ago
  His very specific set of skills is hunting down license term violators
  - cushpush 2y ago
    >...but what I do have are a very particular set of skills. Skills I have acquired over a very long career.
spoonjim 2y ago
Almost all software company revenues come from business customers who are too big to mess with stuff like this.
- Suppafly 2y ago
  This. We have a few different things at work where it would be trivial for me to modify the database to allow unlimited users or grant access we don't pay for, but it'd be mostly pointless.
komali2 2y ago
Yes, and most places that do this (e.g. OpenProject) don't have licenses preventing this, so I have deployed, and shimmed out the enterprise blockers, many Foss sass tools.

threecheese 2y ago

We need more business owners like you. I’d never heard of your product (I’m not in an industry that would have one), just read your blog post on the license; I I wish you wild success and I hope more small dev shops will have the same courage and the same outcome. Cheers!

ezekg 2y ago
Thanks for the kind words. I've seen quite a lot of open/fair source companies this past year. But I'd love to see even more! (And I'd really love to see more bootstrapped ones!)

abhimanyugrover 2y ago

Say if someone copied your codebase tomorrow, and rebranded it as a competing solution and started advertising on same places as you are, what do you do?

ezekg 2y ago
I'd handle it the same any other business would who had their intellectual property infringed upon.
- jayd16 2y ago
  How would you know?
  - ezekg 2y ago
    How would I know if somebody forked and rebranded Keygen's API to compete with me? I feel like it'd be pretty obvious unless they redesigned the entire API schema, endpoints, etc. Not really something I'm worried about.
  - necovek 2y ago
    If this happens in a market far away that the original product would have a hard time reaching, it does not really matter. But if the original product grows enough to be able to reach far away markets, then it's lawyer and discovery money would grow too. I applaud Keygen API approach, though I really hope we find a formula that makes free software become pervasive while providing financial stability to authors and maintainers.
  - madeofpalk 2y ago
    If you don't know, then it probably doesn't affect you.

ijustlovemath 2y ago

How do you actually protect the CE users from setting the environment variables to activate premium features?

greenavocado 2y ago
If you are desperate enough to shim it out you're not worth pursuing as a customer
- billy99k 2y ago
  Yes, but this will cost money and resources. Large companies can take this as a loss. Small companies will go out of business
  - ezekg 2y ago
    In my case, Keygen is a very critical part of a business -- much like billing -- so making sure it's reliable, secure, and well-maintained is paramount. This fact, in and of itself, weeds out most individuals (and businesses) who want to fork and steal, because then maintenance is pushed onto them or onto an untrusted third-party, which has a non-trivial cost for any worthwhile business. Much less risky to just pay the vendor of the software instead of treading through the risky route to save a few bucks.
ezekg 2y ago
Keygen uses Keygen to license itself via license gates: https://github.com/keygen-sh/keygen-api/blob/e668dffbb90bd53a2c6aa040866e4883fa7aab25/app/controllers/api/v1/licenses_controller.rb#L65 https://github.com/keygen-sh/keygen-api/blob/e668dffbb90bd53... (the EE edition requires a license key with entitlements to access the EE features).

Msurrow 2y ago

How do you handle conflicting feature requests from two different paying customers? Like customer A wants buttons in the right, customer B wants them on the left.

ezekg 2y ago
I make the choice. I don't really listen to specifics like that from customers. I'm a SaaS, not a consultancy. Instead, I try to fully understand the customer's problem and then provide a solution to it a way that will work for everybody. If it doesn't work for everybody, or is a niche feature, then I probably won't introduce the feature unless I can come up with a way to make it valuable to other customers. Often, the customer doesn't understand the best way to implement something to make it valuable/usable to other customers, or the costs involved i.r.t. to maintenance, but I do. With an API product, you also have to be picky about new features because once something is introduced, it can't be taken back (assuming you want to maintain backwards compatibility).

rjhacks 2y ago

Thanks for sharing, such an interesting approach! At my startup we're currently discussing licenses, this is very inspiring. I have a follow-up question! The reasons for OSS you list include "Bus-Factor", "Longevity", and "Continuity". I'd summarize all of those as "even if they can't do business with [company] anymore, users can continue on" - our customers also say that's very important to them. ... But what if "can continue on" means "need some of those proprietary features"? And you're not there to sell to them anymore? Or you've been acquired by private equity, started charging 10^6x, and users want out? Users aren't allowed to clone the repo, remove your proprietary code, and reimplement it with their own solution, because: > you may not remove or obscure any functionality in the software that is protected by the license key. Is this a thing your customers are concerned about? What do you expect them to do in such a scenario?

ezekg 2y ago
I've sold multi-year and perpetual EE licenses for this exact reason -- to reduce risk of eventually losing EE features if Keygen LLC goes under and is unable to renew EE licenses. So in this case, if Keygen LLC goes under, they still have a perpetual EE license that will allow them to use existing EE features. But this is something I've been thinking about lately, and something my customers have been talking about. I want to come up with a better answer other than "well, pay me for a perpetual license and we'll remove that risk." Maybe some kind of clause for a "Change License" in case Keygen LLC goes under, e.g. we go from ELv2 to Apache 2.0 if that happens. I'm not really sure what that'd look like right now, but I'll keep thinking on this and hopefully come up with a good answer eventually. Outside of that, nothing is really stopping somebody from forking Keygen and reimplementing the EE features 'in-spirit' under a new code path, especially if Keygen LLC has gone bust. They just can't remove or copy the existing EE features verbatim.

insane_dreamer 2y ago

I can confirm this approach works. We've been a satisfied paying keygen customer for 6-7 years, long before keygen was open sourced, and the fact that it is now doesn't change our decision to continue to pay for its use. If you have something that works well and fills a certain need, customers are happy to pay for it so they don't have to give any thought to it and can focus on their own core competency.

ezekg 2y ago
Thanks for the kind words, and for being a long-time customer (whoever you are). :) I need to send your team some shirts!
- insane_dreamer 2y ago
  Thank you for a product that is well designed and thought through. Not a common thing these days.

insane_dreamer 2y ago

I haven't heard of Fair Source before -- is it gaining traction? Did you use the "legacy license" (that is linked to on the website)?

ezekg 2y ago
It's bleeding edge -- not even "official" yet. It's meant to be an umbrella term to replace the 'open source' vs 'source available' debacle when discussing permissive 'almost-open-source' non-compete licenses like FSL, BUSL, SSPL, ELv2, etc. More: https://twitter.com/chadwhitacre_/status/1790101820364267902 https://twitter.com/chadwhitacre_/status/1790101820364267902
- deleted 2y ago
  [deleted]

pc86 2y ago

Absolutely lovely website you have at https://keygen.sh/ https://keygen.sh/ Did you write that as well or outsource it?

ezekg 2y ago
Thanks! I designed and built the website as well.

jamiesonbecker 2y ago

I replied below about our homegrown solution, but this is very cool! I wish it'd existed when we wrote Userify, but we'll definitely plan on it for our next app! Kudos for solving this so elegantly!

neya 2y ago

Sounds good! Honestly, I may not take this route due to the nature of my product (a self hosted CMS with Enterprise and OSS versions). But very interesting, thanks for sharing!