Ask HN: Founders who offer free/OS and paid SaaS, how do you manage your code?

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

[1]: https://keygen.sh/blog/all-your-licensing-are-belong-to-you/

[2]: http://fair.io/

threecheese · 2 years 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 · 2 years 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!)

reaperman · 2 years 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 · 2 years ago

It'd be a violation of the license terms. Other than that, I may send Liam Neeson after them. :)

spoonjim · 2 years ago

Almost all software company revenues come from business customers who are too big to mess with stuff like this.

justsomehnguy · 2 years ago

> but would anything practical

But would be it practical to go for a such guy?

There are always... stupid people who use hacked software 'because the employer don't have money', but I guess someone with a skill enough to read and patch such code is fully aware how the things are working and wouldn't be doing such stupid deeds.

komali2 · 2 years 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.

insane_dreamer · 2 years 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 · 2 years ago

Thanks for the kind words, and for being a long-time customer (whoever you are). :)

I need to send your team some shirts!

pc86 · 2 years ago

Absolutely lovely website you have at https://keygen.sh/

Did you write that as well or outsource it?

ezekg · 2 years ago

Thanks! I designed and built the website as well.

insane_dreamer · 2 years 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 · 2 years 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

jamiesonbecker · 2 years 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!

rjhacks · 2 years 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 · 2 years 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.

Msurrow · 2 years 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 · 2 years 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).

abhimanyugrover · 2 years 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 · 2 years ago

I'd handle it the same any other business would who had their intellectual property infringed upon.

scottcha · 2 years 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 · 2 years ago

1. You can read more about the Fair Source initiative here: 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 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

[1]: https://github.com/getsentry/fsl.software/issues/2

stevage · 2 years ago

Fair Source seems to be pretty bleeding edge:

https://github.com/fairsource/fair.io/issues/14

neya · 2 years 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!

ijustlovemath · 2 years ago

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

ezekg · 2 years ago

Keygen uses Keygen to license itself via license gates: https://github.com/keygen-sh/keygen-api/blob/e668dffbb90bd53... (the EE edition requires a license key with entitlements to access the EE features).

greenavocado · 2 years ago

If you are desperate enough to shim it out you're not worth pursuing as a customer

In a previous well funded startup with a FOSS component that I worked for I designed a set up like this:

- 2 git repos, one public, one private

- Custom tooling inspired by other existing tools out there like copybara to move commits in a unidirectional flow from the private repo to the public one

The private repo had the contents of the OSS repo in a subfolder, and a unidirectional workflow where all commits flowed from the private to the public. The way the OSS repo accepted contributions was going through the normal pull request workflow on the OSS repo, then on approval the custom tooling copied the pull request into the private repository where it would go through a second round where it was tested against the private code. On merge in the private repo the commit sha of the original commit along with the original author would get injected into the new commit message and then the custom tooling would then automatically push commits in the private repo subfolder to the public OSS repo, which essentially served as a read only mirror on the main branch.

It actually worked quite well, though obviously this approach comes with some tradeoffs. Here are some of the benefits and drawbacks off the top of my head

Benefits:

- no mixing of free and proprietary code. Public users just check out the OSS repo and it’s completely free

- proprietary code is not visible to the public

Drawbacks:

- workflow slightly more complex for both end users and employees of the enterprise

- more work to mainline code by the enterprise: contributions essentially need to be reviewed twice

- it is not possible to have signed commits by OSS contributors with this workflow

Overall it ended up being a great solution for that organization but this kind of approach can only work for low traffic or easy to review repositories. Anything with a decent amount of traffic or lots of complex contributions has a risk of becoming too much overhead for the organization to double build and test pull requests

neya · 2 years ago

This is great, I think I may go down this path. Thanks for sharing!

kunley · 2 years ago

Thanks for honest words on pros and cons, the workflow indeed seems manageable but might lead to troubles for some projects.

jonrosner · 2 years ago

Don't split your codebase. Just add some flags if it is self-hosted or not. Devs here will cry and tell you you can't do that and people can bypass it. Really don't listen to them. 99% of the people who purchase your SaaS instead of self-hosting do it because they don't want the hassle. The rest won't buy from you anyway. The biggest problem is getting SOMETHING out there. If you have success (which let's be honest most likely you won't), you'll have enough time building a better solution later. So keep it simple.

spacebanana7 · 2 years ago

Also few enterprises are willing to risk openly violating a licence, even if no technical barriers exist.

mschuster91 · 2 years ago

This is precisely what Adobe's model was up to Creative Cloud. Probably tens if not hundreds of thousands of young people, school kids and students, grabbed the CS5/6 keygen off of some warez site, taught themselves how to use Photoshop, and asked later employers to provide them with Photoshop.

Nowadays, it's not the case any more as the 20€ or so a month are affordable for a lot of people.

> If you have success (which let's be honest most likely you won't)

My favorite part of your reply..haha

Thanks for sharing!

sneak · 2 years ago

By this logic, you also should release all of your code as free software under permissive licenses.

echoangle · 2 years ago

This but unironically

simonw · 2 years ago

Plugins!

My SaaS version of https://datasette.io is the open source version plus 76 plugins. Almost all of those plugins are themselves open source, with just a few that aren't for features that are unique to the SaaS product - things like showing how much disk space the user has used up already.

Here's what that custom plugin looks like, it's pretty thin: https://gist.github.com/simonw/114131fd9c1826f3629cc3b3dcb84...

mickael-kerjean · 2 years ago

Same idea for my Saas, pretty much every aspect of the software can be changed through plugins. A build is mostly about assembling the right lego blocks like this https://github.com/mickael-kerjean/filestash/blob/master/ser... and a plugin is just a piece of code implementing an interface like this one https://github.com/mickael-kerjean/filestash/blob/master/ser... which enables various build to switch the search engine to virtually any backend

jbarham · 2 years ago

I think that should be https://datasette.io/

Thanks, fixed

djbusby · 2 years ago

Got an good pointers for writing pluggable code? How to make the app itself ready to get all these fancy plugins?

I pitched a conference talk about this recently, if it gets accepted I'll have a good excuse to write this up. It's surprisingly hard to find good information about!

withinboredom · 2 years ago

WordPress is a pretty good example (and all the problems that entails if it gets out of hand). They use a hook/filter model to change outputs of various systems via plugins, and allow plugins to reimplment low-level functionality.

I recommend checking out their approach, as it is pretty flexible.

zerr · 2 years ago

You can get a good idea by reading docs about plugins APIs for a particular software.

That's a very interesting approach! Thanks for sharing.

tommoor · 2 years ago

Like many other answers here, Outline [0] has eventually landed on a plugin architecture with a private fork for EE – the paid edition has many extra plugins providing functionality such as extra importers, auth methods, search functionality etc. The interface itself has evolved several times and we're still adding new hooks to enable plugins to integrate with different areas of the product.

This approach has really made the private fork much more maintanable.

[0] https://www.getoutline.com

[0] https://github.com/outline/outline

h1fra · 2 years ago

Is the public repo the main branch? When you want develop something: you create a PR in the public repo, review, wait for CI, merge to main, wait for CI, finally merge to the fork, wait for CI?

I'm always unsatisfied with the number of steps to achieve that (and the total CI time required), but maybe it's unavoidable.

It is, CI times are fairly fast – in reality it's not been too much of a bottleneck but I'd imagine if you had a team working on the private fork you'd probably want to automate the merges from public at the least.

w10-1 · 2 years ago

As another data point, IBM WebSphere had an open-source version and a paid version which used AspectJ (AOP) to deploy proprietary features. People could deploy something like that potentially even at runtime via remote libraries and load-time weaving. (The technique was called product-line engineering.) Obviously Spring still does something similar with its AspectJ-derived AOP. It works mainly for features applied as transaction/API filters like authentication, security, first-failure data capture, etc., and when OS is used as an training tier rather than a fallback if the company folds.

neandrake · 2 years ago

> The technique was called product-line engineering.

Thank you for adding this bit of info! We’ve been using this model for a while but I hadn’t come across a label for it. Now knowing this, I’m coming across a ton of great info about managing/sustaining these product families.

pentacent_hq · 2 years ago

I’m building an Open Source multi-tenant email newsletter tool [1] and the project is entirely AGPLv3 licensed. I have automatic builds from the `main` branch that I deploy to the SaaS version while public Docker images are available only for tagged releases.

There is currently no difference between the self-hosted and the SaaS version, but I am planning two things:

1) An env variable `IS_SELF_HOSTED` which, when set to `false`, toggles certain features like billing (currently enabled via a separate env variable and theoretically available to self-hosters) and includes hard-coded stuff like a footer with links to the official project website and our ToS.

2) Add a registration feature for self-hosters who make a donation. I haven’t fully planned out this feature, but if a self-hosted instance is registered by a paid supporter, it will most likely remove a call for becoming a supporter (that is yet to be added) or give them a supporter badge.

Choosing the AGPLv3 has been partially inspired by Plausible’s very successful model [2]. They’re also using a `SELFHOST` env variable to differentiate between their "Enterprise Edition" and the "Community Edition" [3].

[1] https://www.keila.io

[2] https://plausible.io/blog/open-source-licenses

[3] https://github.com/plausible/analytics/blob/baa99652f612f50b...

anonu · 2 years ago

Afero, i feel, is a hindrance to adoption, especially in for profit companies where IP matters.

I see the AGPL as a way to ensure user freedom and as a way to make sure those who profit from our work give back to the community.

If someone is so concerned about their so-called "software patents" to the extent that they don't want to deploy their own instance of the AGPL code, they are more than welcome to use our SaaS offer.

MoOmer · 2 years ago

That’s by design; those corporations can purchase an enterprise license - and this is commonly the route desired!

SOLAR_FIELDS · 2 years ago

atonse · 2 years ago

For our SaaS [1] we have a plug-in architecture.

And each plugin has a concept called install constraints. They consist of app, tier, and the role of the user provisioning the account.

Based on the right combination, certain plugins get auto installed and the user can enable/disable optional plugins/features.

Upon installation, the plug-in module has a “lifecycle” module with callbacks for install, uninstall, after_install, etc.

In those, we insert db metadata (pages, folders, menu items, etc) related to that plugin.

All is written in elixir.

1: https://simplyscholar.com

mbreese · 2 years ago

I love this concept (and I’m probably in that market segment). But, I didn’t see any examples on your landing page. It would be really nice if you had one or two examples to show off what a resulting site would look like.

thanks! We are currently revamping that site because it’s just not converting and we suspect what you said is one of the reasons.

We will have samples up in a couple weeks. But stay in touch! ashish@simplyscholar.com