-
keygen-api
Keygen is a fair source software licensing and distribution API built with Ruby on Rails. For developers, by developers.
I have a single code base [0] for self-hosted editions and for the SaaS. I split features up into two editions: community edition (CE) and enterprise edition (EE), and then also two modes: singleplayer and multiplayer (single- vs multi-tenant). 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 singleplayer only).
I've been running this set up for over 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.
[0]: https://github.com/keygen-sh/keygen-api
[1]: https://keygen.sh/blog/all-your-licensing-are-belong-to-you/
[2]: http://fair.io/
-
Scout Monitoring
Free Django app performance insights with Scout Monitoring. Get Scout setup in minutes, and let us sweat the small stuff. A couple lines in settings.py is all you need to start monitoring your apps. Sign up for our free tier today.
-
fair.io
Software sharing for modern businesses. Engage the developer community with your core products.
1. You can read more about the Fair Source initiative here: https://github.com/fairsource/fair.io/issues/14. 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. 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).
-
Filestash
🦄 A file manager / web client for SFTP, S3, FTP, WebDAV, Git, Minio, LDAP, CalDAV, CardDAV, Mysql, Backblaze, ...
Same idea for my Saas, pretty much every aspect of the software can be changed through plugins. A typical build about assembling the right lego blocks like this https://github.com/mickael-kerjean/filestash/blob/master/ser...
-
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
-
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 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.
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)
-
fugu
Fugu is simple, privacy-friendly, open-source and self-hostable product analytics. 🐡 (by shafy)
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)
-
InfluxDB
Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.
-
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.
It calls Stripe to check the plan for example.
-
Plausible Analytics
Simple, open source, lightweight (< 1 KB) and privacy-friendly web analytics alternative to Google Analytics.
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...
-
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.
-
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
-
-
self-hosted
Sentry, feature-complete and packaged up for low-volume deployments and proofs-of-concept
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?
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Related posts
-
What software with web interface do you use? What can you recommend? (Gimmicky or useful software)
-
Why I self host my servers (and what I've recently learned)
-
Tinystatus: A tiny status page generated by a Python script
-
Plausible Analytics: GDPR Compliance with O Cookie Consent Banner
-
Ente: Open-Source, E2E Encrypted, Google Photos Alternative