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

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

181 pointsneya113 comments

I am curious as to how do you solve the problem of maintaining different offerings of your product.

1) Do you have two separate codebases for free and paid? Or do you have some sort of standard workflow where you have two different branches? 2) How do you handle updates to your product? 3) How about employee access?

Thanks in advance!

View on HN

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/

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>

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

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?

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

Fair Source seems to be pretty bleeding edge:

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

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?

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

His very specific set of skills is hunting down license term violators

>...but what I do have are a very particular set of skills. Skills I have acquired over a very long career.

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

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.

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.

> 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.

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!

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!)

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?

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

How would you know?

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.

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.

If you don't know, then it probably doesn't affect you.

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

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

Yes, but this will cost money and resources. Large companies can take this as a loss. Small companies will go out of business

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.

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).

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.

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).

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?

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.

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.

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

I need to send your team some shirts!

Thank you for a product that is well designed and thought through. Not a common thing these days.

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)?

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

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

Did you write that as well or outsource it?

Thanks! I designed and built the website as well.

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!

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!

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.

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

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.

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

But not to many students or young professionals.

Photoshop is actually cheaper than Netflix now. ($9.99/mo versus $15.49/mo)

https://www.adobe.com/creativecloud.html#pick-a-plan-to-star...

https://help.netflix.com/en/node/24926

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

This but unironically

Exactly.

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

My favorite part of your reply..haha

Thanks for sharing!

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...

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

Thanks, fixed

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

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!

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

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.

Another good example is CKAN, the most widely used open data portal platform. Their docs are pretty good on how to write plugins -- gives you an idea of how the architecture works.

https://docs.ckan.org/en/2.9/extensions/index.html

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

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

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.

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.

> 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.

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...

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

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

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.

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

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

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

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

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

1) Do you have two separate codebases for free and paid?

No. Sentry has one codebase between free and paid. We have a Django monolith plus some services where all our features are implemented:

https://github.com/getsentry/sentry

https://github.com/getsentry/relay

https://github.com/getsentry/snuba

https://github.com/getsentry/vroom

etc.

We have a Docker Compose wrapper in a separate repo:

https://github.com/getsentry/self-hosted

We have a private repo called getsentry/getsentry that is another Django app that imports the public one and uses Django signals (iirc) to meter usage for billing. That is what we deploy to SaaS. All product features are implemented in the public repos.

3) How about employee access?

Employee access is managed through UI, I honestly don't know whether it lives in getsentry/sentry (public) or getsentry/getsentry (private). Probably the latter?

2) How do you handle updates to your product?

Employees work in public on GitHub. We ship more or less continuously to SaaS. It's possible to deploy approximately continuously on self-hosted as well, though we also bless monthly snapshots for a more relaxed cadence. Does that answer this question?

Oh wow, I'm a Sentry customer and didn't know this! Thanks for sharing!

One company I worked for did the enterprise version through a git submodule. So main repo was the OSS version (with it's own main), and the git submodule was a different program entrypoint that contained / activated the enterprise code. So devs would have both the OSS/Enterprise module checked out and could work on both together.

In this example as I recall most of the enterprise code was just activation code, so a properly motivated individual could probably figure out how to turn on some of the enterprise features, but most people won't bother to figure out how to do their own builds, and it's more work then finding the secret env variables in an open repo.

It's a little bit painful at times because changes that cover both code bases need two commits, and it isn't uncommon for someone to forget or commit the wrong submodule pointer. But depending on the team, it can work.

Not for everyone, just including it as an option I haven't seen mentioned in other comments.

I'm running a SaaS for serving Python notebooks as web apps [0]. We offer widgets for notebooks and server, both as open source [1]. In open source you are managing the server instance with default Django Admin Panel. In the SaaS version, we have a dashboard for managing site (adding users, setting visibility, usage analytics), the dashboard is closed source. The open source version by default is single site, but can be switched to multi-tenant (multiple domains and subdomains) just by adding instances in the database. In case of update, sometimes it is required to update both code bases. Employees have access to both code bases.

We started with open-source first, and added SaaS offering after ~2 years. The code base split was a natural choice. At first, I didn't want to add SaaS, because managing servers is a lot of work. But, we have a lot of requests for such service, and it makes really easy to deploy notebook online (with few clicks you have unique domain and notebook running). I'm happy with this code base split.

[0]: https://runmercury.com

[1]: https://github.com/mljar/mercury

I am not such a founder, but as a user of and contributor to open source projects let me give a suggestion of how not to do it.

If you include open source and proprietary components in the same repo I will be annoyed. Especially if it is not very clear how the licensing is split, or if the proprietary stuff is split in multiple folders.

If you don't have instructions, or it is otherwise unreasonably difficult to build the open-source only version, I will be very annoyed.

If your "open source" code is directly linked to the proprietary parts, and it requires non-trivial changes to your code in order to build without the proprietary components, I don't consider your project open source, no matter how much you plaster "open source" on your marketing materials. And it's even worse if the license is unclear on what the licensing situation is if you use a release that includes all these proprietary components, but they are turned off because you don't have a license key.

You can have open source and still charge for it. For example, getinboxzero.com or posthog.com or cal.com. Many others too.

Projects use different licenses for enterprise and regular features. Cal does that for example.

Novu doesn’t commit their enterprise features to their codebase. And they symlink those features in. Their project is all MIT because of this.

For Tunnelmole (open source ngrok alternative) the service is identical to the open source project, but with this module https://github.com/robbie-cahill/tunnelmole-service/blob/mai... replaced with a custom version to add the billing logic. It has the same function signature so works seamlessly with the NodeJS module system.

It calls Stripe to check the plan for example.

I keep a copy of it in another folder to avoid accidentally committing it and use `rsync` to patch it in at deployment time.

My mental model for how we do it is the analogy of git/github: git is an open source project that is useful in its own right; github is the opinionated SaaS “glue” between git and an organization.

Our “git” is Plane[1], which is by design fairly unopinionated and general. Our “github” is Jamsocket[2], which is more opinionated about deployment, observability, etc.

We use the open source version of Plane in Jamsocket, and build on top of it in a separate (proprietary) codebase.

[1] https://plane.dev

[2] https://jamsocket.com

Microsoft GitHub is fully proprietary & while Microsoft may or may not be pulling some strings, Git is independent. OP is asking if the free & paid software have the same owner.

OP is asking about codebase organization, and from that point of view the analogy works.

We recently launched Middleware(https://github.com/middlewarehq/middleware) - Open Source Software for Engineering Analytics. We made an architectural change first of splitting the product into core and non-core features. We put core in one repo and non-core in other repos.

We made the core part open source and our paid offering takes up the rest of the product as addons! So, we maintain only one codebase and avoid the hassle of drifts.

Happy to offer more insight.

Yes, I would love to learn more. So, how do you manage the code between core and non-core versions? Do you copy from one to the other via automations or is it some other way?

I worked in product at Elastic working on Elasticsearch, which ended up trying several different things (some of which I know the broader OSS-driven community didn't like, so I'm prepared for downvotes here).

We had started off by using a series of private repos for our non-OSS features. At build time, we had a pretty complicated suite of build tooling that took all of the repos and integrated them and ran the integration tests. The biggest reason why Elasticsearch went to single repo with all of the enterprise software included (knowing that the OSS-focused community was going to backlash on it) was just how much of a hassle that was. It bifurcated everything and the results were that paying customers were upset the most.

For example: have an issue with the product? You could file a GitHub issue in public and it would get looked at quickly, but if you were a paying customer with an issue with one of the enterprise features, you had to file an issue with the support team because the GitHub repo was separate/private, and then support would file an issue in the private GitHub repo, and you'd lose complete visibility with it. It was even worse for free/trial users: they had to file an issue on our forums (since they didn't have an established support contact), after which they lost visibility. Integration tests were also hellish.

I later worked at another open core company, which at first maintained a separate codebase for its paid offering, and synchronized changes over from the open source product periodically, and things were much worse: a ton of bugs kept popping up and getting the paid offering out the door was always extremely slow because you were always playing catch up on the OSS offering.

You can go down the submodule route, but you end up relying on pretty complicated build tooling. If that's in your team's realm of capabilities, it's not a bad route to go. If you have no need for "OSS," then you can choose a non-OSS license that provides whatever restrictions you care about and bundle it up together, which is easier, but might dissuade certain users.

Regardless, licensing enforcement isn't really an issue if you're working on a B2B product: there are certain demographics that won't pay for your software, but they won't pay if you have licensing enforcement either. B2C can be a different story.

Very insightful, thank you for sharing!

If I understand this is more of a coding question. I'd argue it would be best for most web based SaaS to have a single codebase, with a single branch that represents the production site. That code base would then be smart enough to enable the right features based on the current user and/or tenant and their subscription level and payment status. Pseudocode:

   public DoFoo(){
      if(CurrentUser.IsFreeSku && CurrentUser.FoosThisMonth >= 10) return Error('Free users are only allowed to do 10 foos each month);
      FooService.DoFoo();
      CurrentUser.FoosThisMonth ++ 
   }

Similar in the UI you may hide or show things based on the current user/tenant and their sub level.

<div class='hidden-paid-user'>Click here to get our paid service</div>

You would still have server code enforce the subscription level rules because a malicious user could circumvent any client-based rules. How exactly you do both will depend on the framework your saas uses.

This is a nightmare

Why

Because you'll end up with lots of "if (user.isPaidUser) {...}"

For me personally, I don't see the issue with this. It's an accurate representation of the app's behavior.

Well, yeah, but this was just pseudocode to convey the concept that you should solve the problem in code, not by maintaining separate code branches, deployments, etc. One approach would be to have an implementation of FooService for each sku, and code that uses the right one based on the current user/tenant/payment status/etc. This gets into dependency injection, inheritance, and other language/framework specific things. The actual approach would vary based on the project. It may be that CurrentUser.Sku and CurrentUser.IsPaymentCurrent is sufficient. Or it may be that you need a FooService per SKU, or any number of other ways to handle.

Ok this makes sense to me. Bundling feature sets by SKU.

I get that but then what would the alternative be? I am not saying that there is not an alternative but if you know another way I am curious to hear from you about that.

Not launched, but building open source components and mucroservices with a closed dashboard and overall backend.

For instance, a Git-like DAG for a config service [1] that supports history and eventually forking and merging on top of PostgreSQL. This was broken out of the larger Go codebase and is currently AGPL3 as a placeholder while I research better licenses to use.

The overall idea is the "nuts and bolts" of a small startup/SaaS app, including metrics, IAM/auth, and subscriptions via a single API and React/JS SDKs.

I hope to do a Show HN on one or both in the near future.

[1] https://github.com/tmzt/config-api

I have two open-source projects where people can self-host for free, or use the cloud (SaaS) version. Although with Mapzy I stopped providing the cloud version for now. I have one codebase and then use an environment variable to activate features like Stripe that I need for the cloud version.

Mapzy: A simple storefinder (https://github.com/mapzy/mapzy)

Fugue: Privacy-friendly product analytics (https://github.com/shafy/fugu)

I am planning too this. My general recommendation is a plugin-based system. A lot of business just offer the same product as a SaaS or with integration just installed (like HomeAssistant which offers SSL certs for Alexa, or HelathChecks.io which offers Whatsup/Teams integrations).

Most of the Cusommers didn't care self-hosting, if your SaaS price is decent.

I strongly do not recommend to have two copies of the codebase, because it increase the sync time (like bug fixing portings, for instance).

Sad to say, consider protecting you from AWS/GCP/etc reselling as a service

I watched an interview of Tom from GitHub recently with Indie.vc, and he spent a solid five minutes reiterating that you shouldn’t split your code bases.

Do you have the link please?

Here you go: https://www.youtube.com/watch?v=oA7mCjY5ySA

Discussion of split codebases happens around the 41 minute mark

On https://backgroundremoverai.com I put the utility into it's own pip and open source it https://github.com/nadermx/backgroundremover, and the web framework kept closed source.

For most businesses, you shouldn’t offer a free product at all, unless your solution’s success relies on becoming a popular ecosystem.

I feel like most people say plugin which is fair and easy to do on the backend but I'm always wondering how they are doing for the frontend. I never found an appropriate solution to modify the frontend (i.e: adding a billing page, a button in some page, etc)

What benefits will open source give you? Just keep it closed if you don’t have a good answer.

I'm working on a tiny saas that is moving in this direction. It's based on laravel in the backend.

I'm using different implementations of interfaces for self-hosted vs commercially (my variant) hosted.

What implementations get chosen depends on environment variables.

The code is available as GPL

Base platform with extension support, core functionality as well as paid additions are extensions.

I have a separate codebase for FREE which ended up unmaintained. Now, I think it's better with a monorepo where you will have the chance to share code and update as frequent as you need.

Many of these products are fully source-available, just different directories live under different licenses. That seems the easiest way.

Paid fork, rebased on free core.

Makes sense!

on our end the core is open sourced, we keep the saas backend closed.

Reply on news.ycombinator.com