I am curious as to how do you solve the problem of maintaining different offerings of your product.<p>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?<p>Thanks in advance!
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).<p>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).<p>Updates are pushed to the SaaS offering daily. I cut self-hosted releases bi-annually unless it's for a critical fix.<p>[0]: <a href="https://github.com/keygen-sh/keygen-api">https://github.com/keygen-sh/keygen-api</a><p>[1]: <a href="https://keygen.sh/blog/all-your-licensing-are-belong-to-you/" rel="nofollow">https://keygen.sh/blog/all-your-licensing-are-belong-to-you/</a><p>[2]: <a href="http://fair.io/" rel="nofollow">http://fair.io/</a>
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.
Plugins!<p>My SaaS version of <a href="https://datasette.io" rel="nofollow">https://datasette.io</a> 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.<p>Here's what that custom plugin looks like, it's pretty thin: <a href="https://gist.github.com/simonw/114131fd9c1826f3629cc3b3dcb845ad" rel="nofollow">https://gist.github.com/simonw/114131fd9c1826f3629cc3b3dcb84...</a>
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.<p>This approach has really made the private fork much more maintanable.<p>[0] <a href="https://www.getoutline.com" rel="nofollow">https://www.getoutline.com</a><p>[0] <a href="https://github.com/outline/outline">https://github.com/outline/outline</a>
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.
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.<p>There is currently no difference between the self-hosted and the SaaS version, but I am planning two things:<p>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.<p>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.<p>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].<p>[1] <a href="https://www.keila.io" rel="nofollow">https://www.keila.io</a><p>[2] <a href="https://plausible.io/blog/open-source-licenses" rel="nofollow">https://plausible.io/blog/open-source-licenses</a><p>[3] <a href="https://github.com/plausible/analytics/blob/baa99652f612f50bbb63282b42737ced93b6d483/config/runtime.exs#L243">https://github.com/plausible/analytics/blob/baa99652f612f50b...</a>
In a previous well funded startup with a FOSS component that I worked for I designed a set up like this:<p>- 2 git repos, one public, one private<p>- 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<p>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.<p>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<p>Benefits:<p>- no mixing of free and proprietary code. Public users just check out the OSS repo and it’s completely free<p>- proprietary code is not visible to the public<p>Drawbacks:<p>- workflow slightly more complex for both end users and employees of the enterprise<p>- more work to mainline code by the enterprise: contributions essentially need to be reviewed twice<p>- it is not possible to have signed commits by OSS contributors with this workflow<p>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
For our SaaS [1] we have a plug-in architecture.<p>And each plugin has a concept called install constraints. They consist of app, tier, and the role of the user provisioning the account.<p>Based on the right combination, certain plugins get auto installed and the user can enable/disable optional plugins/features.<p>Upon installation, the plug-in module has a “lifecycle” module with callbacks for install, uninstall, after_install, etc.<p>In those, we insert db metadata (pages, folders, menu items, etc) related to that plugin.<p>All is written in elixir.<p>1: <a href="https://simplyscholar.com" rel="nofollow">https://simplyscholar.com</a>
1) Do you have two separate codebases for free and paid?<p>No. Sentry has one codebase between free and paid. We have a Django monolith plus some services where all our features are implemented:<p><a href="https://github.com/getsentry/sentry">https://github.com/getsentry/sentry</a><p><a href="https://github.com/getsentry/relay">https://github.com/getsentry/relay</a><p><a href="https://github.com/getsentry/snuba">https://github.com/getsentry/snuba</a><p><a href="https://github.com/getsentry/vroom">https://github.com/getsentry/vroom</a><p>etc.<p>We have a Docker Compose wrapper in a separate repo:<p><a href="https://github.com/getsentry/self-hosted">https://github.com/getsentry/self-hosted</a><p>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.<p>3) How about employee access?<p>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?<p>2) How do you handle updates to your product?<p>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?
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.<p>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.<p>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.<p>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.<p>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.<p>[0]: <a href="https://runmercury.com" rel="nofollow">https://runmercury.com</a><p>[1]: <a href="https://github.com/mljar/mercury">https://github.com/mljar/mercury</a>
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.<p>If you include open source and proprietary components in the same repo I will be annoyed. Especially if it is not <i>very</i> clear how the licensing is split, or if the proprietary stuff is split in multiple folders.<p>If you don't have instructions, or it is otherwise unreasonably difficult to build the open-source only version, I will be very annoyed.<p>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.<p>Projects use different licenses for enterprise and regular features. Cal does that for example.<p>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 <a href="https://github.com/robbie-cahill/tunnelmole-service/blob/main/src/authentication/authorize.ts">https://github.com/robbie-cahill/tunnelmole-service/blob/mai...</a> replaced with a custom version to add the billing logic. It has the same function signature so works seamlessly with the NodeJS module system.<p>It calls Stripe to check the plan for example.<p>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.<p>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.<p>We use the open source version of Plane in Jamsocket, and build on top of it in a separate (proprietary) codebase.<p>[1] <a href="https://plane.dev" rel="nofollow">https://plane.dev</a><p>[2] <a href="https://jamsocket.com">https://jamsocket.com</a>
We recently launched Middleware(<a href="https://github.com/middlewarehq/middleware">https://github.com/middlewarehq/middleware</a>) - 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.<p>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.<p>Happy to offer more insight.
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).<p>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 <i>everything</i> and the results were that paying customers were upset the most.<p>For example: have an issue with the product? You could file a GitHub issue in public and it would get looked at quickly, <i>but</i> 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.<p>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 <i>much</i> 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.<p>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.<p>Regardless, licensing enforcement isn't <i>really</i> 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.
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:<p><pre><code> 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 ++
}
</code></pre>
Similar in the UI you may hide or show things based on the current user/tenant and their sub level.<p><div class='hidden-paid-user'>Click here to get our paid service</div><p>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.
Not launched, but building open source components and mucroservices with a closed dashboard and overall backend.<p>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.<p>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.<p>I hope to do a Show HN on one or both in the near future.<p>[1] <a href="https://github.com/tmzt/config-api">https://github.com/tmzt/config-api</a>
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.<p>Mapzy: A simple storefinder (<a href="https://github.com/mapzy/mapzy">https://github.com/mapzy/mapzy</a>)<p>Fugue: Privacy-friendly product analytics (<a href="https://github.com/shafy/fugu">https://github.com/shafy/fugu</a>)
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).<p>Most of the Cusommers didn't care self-hosting, if your SaaS price is decent.<p>I strongly do not recommend to have two copies of the codebase, because it increase the sync time (like bug fixing portings, for instance).<p>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.
On <a href="https://backgroundremoverai.com" rel="nofollow">https://backgroundremoverai.com</a> I put the utility into it's own pip and open source it <a href="https://github.com/nadermx/backgroundremover">https://github.com/nadermx/backgroundremover</a>, and the web framework kept closed source.
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)
I'm working on a tiny saas that is moving in this direction. It's based on laravel in the backend.<p>I'm using different implementations of interfaces for self-hosted vs commercially (my variant) hosted.<p>What implementations get chosen depends on environment variables.<p>The code is available as GPL
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.