Happi is now open-source. The entire codebase is freely available for anyone to self-host, contribute to or just read through to see how it all works.
As a developer who relys on open-source projects to make a living, I’ve always liked the idea of having an open core product and have been inspired lately seeing a few others doing this really well, such as Plausible analytics - a privacy focused Google Analytics alternative.
Why?
There are several reasons for doing this that I would like to touch on, but first, it’s not to get contributions. I doubt I’ll get many serious contributions to the product and I don’t really want to spend much time code reviewing pull requests, I’d rather spend time shipping improvements myself.
So why am I doing this?
- It’s pretty easy to build trust and accountability when your code is public. As a boostrapped product, some may have concerns about the product no longer being maintained. With a public codebase, they can choose to self host later down the line, or have the community fork and take over the product.
- I want to provide a secure and privacy focussed application, what better way to do it than to have the code available for all to see. I want to take a deliberate stand against Surveillance capitalism.
- Some people will prefer to self-host Happi, having full control of their own data and running it on their own infrastructure, and I’d like to support that.
- Lastly, I don’t think there are a huge amount of open-source Hotwire applications like this out there and with the screencasts I‘m making it would be great to be able to link to commits or source code directly.
How will this affect the business?
Some might have concerns that open-sourcing their application and allowing people to self-host will seriously harm their business model.
I have zero concerns about this, in fact I pay for plenty of software that’s available to self-host for free myself.
Self-hosting is far more expensive than just paying the monthly subscription for the cloud version. I value my time, and if I have to SSH into servers and start fixing things or running upgrades, I‘ve already lost more money than the price of a cloud based solution.
The other thing is, not all users are technical, and I’ve made Happi super easy to use, so non-developers can easily sign up and use the cloud based version.
Which license works best?
From following Plausible along the way, they have had some issues with corporations taking their MIT licensed app and trying to closed-source it and resell it, without giving back to the open-source project. This may seem like copyright infringment, but if you license your application under MIT, this is usually allowed.
For this reason, I’ve copied Plausible and licensed as AGPL. This license prevents modifications, without them also being open sourced and available to contribute back to the main source. There shouldn’t be any issues with GPL like there would be with a library, because Happi isn’t going to be included into anyone else web app.
The only exception to this, is that the embedable support widget is using the MIT license, as it will be included as an npm package into other peoples codebases, so we don’t want any GPL issues here.
Hopefully this turns out to be a good decision in the long run. If you have any questions or thoughts please drop a comment.
Top comments (1)
How do you protect from large organization hosting and managing the app for their customers without paying you a dime? It has been an issue for Elastic vs AWS and few other open source projects experienced that as well.
Having the user committing back is great, but they should not be entitled to operate your project as a SaaS. What do you think?