41–50 of 117 posts
Earlier quoted context omitted.
I'd handle it the same any other business would who had their intellectual property infringed upon.
How would you know?
Not really something I'm worried about.
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,…
Earlier quoted context omitted.
I'd handle it the same any other business would who had their intellectual property infringed upon.
How would you know?
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 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.FoosT…
This is a nightmare
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.…
Got an good pointers for writing pluggable code? How to make the app itself ready to get all these fancy plugins?
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.
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
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.
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.…
Got an good pointers for writing pluggable code? How to make the app itself ready to get all these fancy plugins?