(Also how did the other URL get double-posted? I thought HN folded dupes. :shrug:)
2,157 karma · joined April 5, 2011
(Also how did the other URL get double-posted? I thought HN folded dupes. :shrug:)
Details: https://openpath.quest/2025/luke-missed-the-memo/
---
Update from OSI: https://bsky.app/profile/opensource.org/post/3liz24zxtfk2i
https://openpath.chadwhitacre.com/2024/questioning-the-value...
[0] https://openpath.chadwhitacre.com/2024/widespread-use-of-a-f...
https://openpath.chadwhitacre.com/2024/widespread-use-of-a-f...
https://openpath.chadwhitacre.com/2024/widespread-use-of-a-f...
Fair Source is working quite well for us. You should try it. :^)
https://opensource.com/open-organization/16/7/compensating-e...
Super-experimental, though. Not ready for prime time yet. :D
I engaged heavily with a lot of Dirk's work in my historical deep-dive:
https://openpath.chadwhitacre.com/2024/the-historical-case-f...
> Dirk asked in 2021, “What’s next after ‘source-available’?” Our answer is Fair Source. I’ve made the case that it is a good way to resolve tensions that have been present in Open Source since the beginning. The net effect can be more closed-source code released to the world, and less pressure to change the Open Source Definition one way or another.
> we will see if it becomes popular
Agreed, time will tell. A major test is whether we ever see a viable fork under DOSP, seems likely years away if ever.
No.
> How do you value the various libraries of user interaction, issue submission, and other market intangibles?
Highly. Dirk Riehle has a post from 2009 where he talks about the business benefits of Open Source community. I quote from it in the Fair Source FAQ:
> Fair Source provides many of the same benefits for companies as Open Source, by helping to foster an engaged developer community around your software products.
> I notice that you dont mention them at all in your writing about Redis. Why is that?
Because my blog post predates Valkey by a week. I've added an update.
2009 - BSD-3
2019 - BUSL-1.1
2023 - FSL-1.0
2024 - FSL-1.1
Details: https://blog.sentry.io/sentrys-open-source-values/#our-histo...
and https://blog.sentry.io/introducing-the-functional-source-lic...
Allowed? Sure. Expected to? Nope. I put it this way in the FAQ:
> Developers can propose modifications back to the producer if they wish, or simply benefit from the company's continual investment in maintenance and improvement.
That said, for me personally (taking my Sentry hat off for a second), I think the most interesting future is one in which companies use Fair Source licensing _and_ open hiring/twyw compensation:
https://opensource.com/open-organization/16/5/employees-let-...
https://gratipay.news/sharing-our-take-what-you-want-story-9...
Fair Source is a small step towards that as a possible future.
> don't act sad when you alienate swathes of your contributors
This is ill-informed, for what it's worth. Our relicensing had essentially no effect on the ratio of commits from outside the company: it went from 3.5% to 3.4%. I wrote about this when OSI published the DOSP paper that we underwrote.
https://blog.sentry.io/nows-the-time-for-delayed-open-source...
> the company effectively doing a rugpull on third party users/contributors
Since Sentry has always been built by Sentry, our relicensing wasn't a rugpull. I wrote about this when Redis relicensed most recently:
https://openpath.chadwhitacre.com/2024/relicensing-and-rug-p...
Eric Raymond had a similar take. I wrote this response for him:
https://openpath.chadwhitacre.com/2024/widespread-use-of-a-f...
tl;dr Sentry, in addition to 100,000+ SaaS customers, has 10,000+ unmonetized self-hosted users from hobbyists up to FAANG companies. This is strong evidence against your claim that Fair Source licensing "usually terminates the product evaluation with a laugh."
https://openpath.chadwhitacre.com/2024/the-historical-case-f...
Fair Source: https://fair.io/
Our drama: https://news.ycombinator.com/item?id=36971490
Lots more context: https://openpath.chadwhitacre.com/2024/the-historical-case-f...
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
https://github.com/getsentry/relay
https://github.com/getsentry/snuba
https://github.com/getsentry/vroom
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?
[1] https://squidfunk.github.io/mkdocs-material/insiders/
> it will still suffer from the 'tragedy of the commons'.
Fortunately, we have lots of great research on how to avoid tragedies of the commons:
https://www.amazon.com/dp/0521405998
I aim to explain how this applies to Open Source in a future post, which I'm tracking here:
I consider this a case of "Open Source subsidization, not sustainability":
https://openpath.chadwhitacre.com/2024/the-open-source-susta...
Sustainability strongly defined means no hoops.
I define this in the post as "Open Source subsidization, not sustainability."
https://openpath.chadwhitacre.com/2024/the-open-source-susta...
It's fine as far as it goes, but it doesn't go far enough. It works for products, but it doesn't work well for libraries, frameworks, dev tools, and the like.
> donating is incredibly convenient nowadays
It's convenient to get started but not to scale. I run one of the foremost corporate Open Source donation programs (imo, obv):
https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-...
GitHub Sponsors is very difficult to use at scale (100s or 1000s of deps). Thanks.dev is better but still has a lot of room to grow.
> addressing the root of the issue
Open Source is a common pool resource, and these are funded through collective social pressure, the limit case of which is taxation. More on this in a future post.
It's $15 per month so $180 allocated overall. Would it be more worth it for you if it were paid out in one lump sum for the year vs. doled out monthly?