re: OSS licensing, we use GPL and have been very hesitant about using something like AGPL. I’ve personally seen developers not use projects only because they’re AGPL. Even GPL seems to scare some developers.
Question for HN: have you recently wanted to use an OSS project in your stack and then stayed away from using it only because of its license?
If so, what license was it and what about the license prevented you from using it?
If you're really worried about copycats or leechers, you might want to consider either close sourcing / restrictively licensing [0] the very important bits of the stack that matter to paying customers (like GitLab does with their "buyer-based open core model" [1]).
Note though, open source has always been about commoditizing loss leaders [2] or commoditizing a product's complement [3]... never quite has been a good business model in and of its own.
[0] https://polyformproject.org/licenses/
[1] https://www.heavybit.com/library/video/commercial-open-sourc...
[2] http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...
[3] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
Do you think it is more likely to scare your potential paying customers, your potential contributors, or potential freeloaders?
I expect that is likely to scare people in this order:
1. Freeloaders
2. Contributors
3. Customers
If I have a Free Software project, I want to scare freeloaders while still welcoming potential customers and contributors. I know its a balancing act, but I like the AGPL.
So if a license scares the people who start using it for free, it then inherently hurts contributions and customers long term.
1. Contributors
2. Customers
3. Freeloaders
The type of person who is likely to contribute will be the first to look at the license, and AGPL will rightfully worry them.
For the open source funnel, the potential customers start off as "freeloaders". They are more likely to look at the license in the first place because they are more likely to be using the software in a commercial setting and have to worry about licensing. The AGPL concerns hit them first.
The freeloaders will just switch over to a more liberally licensed project.
Curious to know how you’re solving this — we should come up with some best practices in this area for everyone to adopt!
In companies I’ve worked at in the past, during every round of fund raising, as part of the due diligence, lawyers would ask for the licenses of all software packages we use. And when AGPL showed up in the list, they’d specifically ask how it’s integrated with the rest of the system, and evaluate it with more scrutiny. In hindsight, this makes total sense - they were just trying to make sure we were compliant with what AGPL calls for.
But the fact that AGPL software called for extra scrutiny from lawyers, became a stumbling block and added just enough friction to adopting additional AGPL software in the stack.
Now being on the other side of the table as an OSS product, this is painful to watch.
I don’t have a grand plan to solve these misconceptions yet. Hoping that publicly talking about this and driving awareness about GPL and AGPL might help. Open to ideas!
[0] https://nts.strzibny.name/privacy-oriented-alternatives-to-g...
However, at some point I'd like to monetize this site. I know there's https://www.ethicalads.io/, but they've limited their target audience to developers. Are there any privacy focused ad networks?
As a trivial example, I’m assuming youre using plausible in plausible, do you have protections ensuring secrets don’t leak to the open source for history ?
We also have a separate repository with examples and code for how to host Plausible Analytics with docker-compose: https://github.com/plausible/hosting
The hosting repo includes everything you need including databases, MaxMind GeoIP database, reverse proxy for SSL, etc.
We don't host with docker-compose ourselves because we want to scale our databases independently from the app server.
I'm not sure I understand your question. Secrets should never be committed to source control, whether the repo is public or not. Being open source does not change how we manage secrets in the slightest.
Does that answer your question?
2. Code needs maintenance and expertise to run. Could you download the source of a large app and compete against it profitably? Maybe if it were mature, well documented, and longtime contributors hired.
the slower schedule of the official "stable" self-hosted release is to simply make it possible for us to make it work.
we're a two person team and because of the popularity of the product, we've become overwhelmed with support requests from self-hosters and needed to make a change in the expectations and the process
This is sane, and how most other open source applications or tools work. Don't see any reason why this one should be different.
Upgraded to a paid plan for my project which is getting some traction and I was able to get exactly the kind of analytics I was looking for. I also share similar principles with regards to user privacy and so it’s definitely something I want people to use more and advocate for.
Great work folks.
Something like this, however, is: https://anonymous.4open.science/r/e85a54a3-983d-498c-8672-0a...
This make it seem you can't use the software at all, even if your company satisfies their conditions.
