Sentry is now Fair Source
Sentry has launched Fair Source, a software sharing model balancing user freedom and developer sustainability, allowing companies to share software while maintaining control, attracting participation from others transitioning to this model.
Read original article
Sentry has introduced a new software sharing model called Fair Source, aimed at providing a balance between user freedom and developer sustainability. This initiative allows companies to share their software while maintaining control over their business models, addressing the long-standing tension between open-source principles and commercial interests. Fair Source software is publicly accessible, permits modification and redistribution with minimal restrictions, and includes a delayed Open Source publication (DOSP) feature. This model is designed to protect both the producer's business and the community's rights, ensuring that if a company fails or changes direction, the community can continue the project. Sentry's experience with Fair Source has shown that it can be beneficial for both developers and companies, as evidenced by their growth to over 100,000 cloud customers and $100 million in annual revenue. The initiative has already attracted participation from other companies that have transitioned from closed-source to Fair Source, indicating a potential shift in how software is shared in the industry.
- Sentry has launched Fair Source to balance user freedom with developer sustainability.
- Fair Source allows companies to share software while maintaining control over their business models.
- The model includes delayed Open Source publication to protect community interests.
- Sentry's success demonstrates the viability of Fair Source for both developers and companies.
- Other companies are joining the Fair Source movement by transitioning from closed-source to shared models.
12 commentsMaybe it's because it's new, but the website doesn't offer a ton of insight into how "Fair Source" is different from other attempts to re-brand proprietary software as pseudo-open-source. For example, the FSS definition on the home page mentions "minimal restrictions," but I can't find a clear list of what those restrictions are in the FAQ[2].
(And to be clear: I'm not an ideologue around FOSS/OSS; I think source availability also benefits the commons. But I would not be surprised if FOSS/OSS people chafe at these kinds of implied-value-judgment labelings ("fair source," "commons clause") for what is fundamentally not OSS.)
[2]: https://fair.io/faq/
What I see is a lot of "single vendor" projects which carry most of development burden want their business protected while having, often minimal, contributions from community.
The "Real Open Source" though is multi-vendor - think PostgreSQL, Linux, Kubernetes among others, in which case many parties share the burden of development and maintenance but also have even playing field monetizing product.
- https://news.ycombinator.com/item?id=38877059 (sentry FSL relicense)
- in particular: https://news.ycombinator.com/item?id=38312686 (rugpull licensing still possible on future versions/contributions)
- Sentry's first relicense: https://news.ycombinator.com/item?id=21466967
Looking back to the first relicense in particular, the company effectively doing a rugpull on third party users/contributors, and the trend of companies trying to pretend they aren't doing exactly that sours me on basically any 'opencore'/required CLA project. I make rare exceptions for non-profits, but only those that are mature, well established, and not the sort of non-profit that puts most of their operation under a for-profit entity.
As woodruffw mentions, these implied-value-judgement labelings are really marketing terms designed to muddle the value and importance of what it means to be an open source product.
If it doesn't work for your business, fine, don't use an OSS license. But don't expect us to slurp up your peddling when you want to pretend its an OSS license, and don't act sad when you alienate swathes of your contributors.
*EDIT*: I misspoke, my brain had thought that old Sentry licenses were GPL, they were more MITish as seen in the LICENSE file in older releases of Sentry. My mistake :\
FWIW, if Sentry had stayed MIT or even moved to AGPL, I think they would have stopped much of their newer competition from even coming to market (I'm thinking of signoz, glitchtip, vs OTEL and its million integrations here.)
My position in 2019 was that much these decisions are being driven by the VC money, and I believe that is still true today. If it weren't, they could have chosen options that served the wider community better. (I also think that wider community and the accessibility of such is what got sentry much of its initial draw, but TBH im not sure how much that bears out in reality. I haven't studied deeply enough to have a good idea of the numbers there.)
Anyway, so, I tried Sentry at some point, like, five years ago. Signed up for the 'team' plan, even though it's just lonely me, and had bugs coming in for about... a week, maybe less? Then, my subscription suddenly became inactive, because I had exceeded the 10K (or so, at the time) bugs that they were willing to track for me. Not, unique bugs, mind you, just the same bug that the same automated process was hitting every second or so.
But still, I now had to either negotiate an "Enterprise" price plan, or go away elsewhere. And I did actually ping them about the former, but never got a response. So, well, back to manually reading logs like an animal it is, then, I guess?
TL;DR: If your vision is to solve a certain problem, aren't the oh-we-didn't-see-that-coming corner cases the most interesting?
The entire point of choosing to use open source projects is that if you, the author, begin to enshitify the product (Or simply start to move in a direction different from users) users can fork the project and carry on an un-enshitified version.
If you can't compete with the author, you can't do that. So what is the point of picking software using this license over traditional closed source?