Hacker News Reader

Comment by ensignavenger | Hacker News Reader

The article doesn't appear to mention that Sentry abandoned open source. If anyone is looking for an open source fork of sentry, there is https://glitchtip.com/

View on HN

> Sentry abandoned open source

sentry from github works most of the time, but the setup process is such a PITA.

For what it’s worth I’m not super happy that it’s so painful. It also makes the DX for Sentry developers harder than I would like. I can’t promise improvements but it’s definitely something that’s a shared concern.

Generally speaking though we deploy our git repo to prod multiple times a day. So if you contribute changes, they deploy fast :)

No shade here at all, but I always figured this was intentional. One legitimate way to get people to pay for OSS is to make it a real nightmare to self-host.

edit: Just wanted to add, I say this as a happy Sentry paying user for more than a decade now.

It's not intentional. We actually held back more complicated features for years to make it easy to self-host (e.g. only used Postgres and Redis as data stores for a long time).

The complication really just comes from the new capabilities we've added, and the dependencies that come with that. I suppose also our sophistication in hosting the platform has evolved (as the scale has increased), and so the tooling we use to manage it has become more complicated.

Kudos! And I get it, it's hard to do really cool and powerful things when large amounts of data are involved without involving better (and possibly more complicated) data stores.

GlitchTip isnt a fork. Its a reimplementation of Sentry by folks who I had never had interactions with (afaik) before we migrated to BUSL. They leverage our SDKs, and maybe they've vendored in some of our original code (hopefully correctly applying the license), but you can browse the source and clearly see its not Sentry. It turns out its quite complicated to fork, build, and maintain a project at the size of Sentry when you arent familiar with it, and didnt help build it.

Theres a lot of nuance in Open Source, and I will probably write more about this part of Sentry's history, but unlike say Terraform, Sentry (the service) was almost exclusively developed by myself and other employees of the company.

GlitchTip describes themselves as a "partial fork/mostly re-implementation"- https://gitlab.com/glitchtip/glitchtip-backend

Early versions of it I beleive used more Sentry code. If I recall correctly their initial release was basically a renaming of the open source sentry code. It has taken its own direction since.

Is sentry.io no longer open source? Have not followed it as closely since its so cheap.

Almost all the code is out there either as MIT or Apache2. Changes in the last 4 years have a temporary exclusivity period via the BUSL and roll over to Apache2 on a monthly basis. We have however heard loud and clear that a lot of people are dissatisifed with this, particularly with us calling ourselves an Open Source company.

We're trying out best, maybe that's not the last part of the story. Combining a sustainable business and Open Source under the same hat is tricky, and maybe we haven't found the right solution yet.

As one who is highly critical of the BUSL and especially of companies switching from Open Source licenses to the BUSL, I want to chime in a bit on this.

First of all- Thank You. Thank you to Sentry and the people there for making Sentry and making it originally Open Source. Thank you for continuing to make it eventually Open Source. Thank you for your continuing financial support of Open Source. I should have been more nuanced in my comment above, as Sentry only abandoned Open Source for their core product(s) and continue to contribute to other open source projects.

I don't believe Sentry "owes" anyone continued open source license terms.

I believe strongly in the value of the ability to fork. This is best for both companies and their customers. It allows both to pivot to new models. This is why I promote open source and insist on it for any core infrastructure or applications within my business. The freedom to fork has to be available to the community or any subset thereof, and viable. This is the weakness of the BUSL- because it prevents the community, or a subset thereof, from pursuing a key source of revenue to fund a fork.

I also really appreciate the business challenges of running any business, and especially an open source business. I believe there are many viable avenues to doing so. Community, product quality, support, and freedom are all critical selling points that open source companies have to do a better job of promoting and leveraging. I am willing to talk to anyone at Sentry or any other company considering the BUSL about strategies to make money and to avoid "heretical" software licenses. :)

> The freedom to fork has to be available to the community or any subset thereof, and viable. This is the weakness of the BUSL- because it prevents the community, or a subset thereof, from pursuing a key source of revenue to fund a fork.

I believe the main issue today is less the BUSL but that 3 or 4 years which are the common terms are a bloody long time. The secondary issue is that the BUSL is a huge turnoff for contributions for a potential community fork. I know people forked Sentry from the BSD source rather than the BUSL rollover versions, even though the Apache2 licensed Sentry is much newer (though still years old).

We might not owe anyone anything, but we also are not particularly happy with the license choice we have at the moment. We had the hope that we can start a positive trend for combining a SaaS business with Open Source and I don't think it has quite worked out how we wanted. A lot of companies rally behind the BUSL that have very different values than we do, and that adds to the negative perception of the license.

I hope you can pass on my appreciation for Sentry's support of OSS authors and maintainers!

> Combining a sustainable business and Open Source under the same hat is tricky

That's because open source is generally not sustainable - it's reliant on being funded by other means of revenue generation.

It's source available under the BSL: https://github.com/getsentry/sentry. After four years it becomes open source (probably to prevent "AWS Elastic Error Handling service(tm)" from becoming a thing)

You can still run it for your company for free, if you feel like managing all of the infra it requires.

This strikes me as a poor choice (moreso than other BSL adopters) since there are many other error-handling SaaS companies available. It seems like it is better for people to be using your tool hosted by someone else than using a different tool with a different API so that migrating to your offering (hosting or support) is more difficult.

This would a great segway for another post as theres a ton of nuance and interesting history in how Sentry has approached the competitive market. I'll add to the list and maybe at some point do one just around that.

That said, almost all of our competitors plateaud in growth even _after_ we switched to the BUSL. We found folks don't care that much. They appreciate open source, but they care less about the caveats of a license and more than they can self-host, view the source. They care about the liability of the product being maintainable, and BUSL still allows you to maintain software if the company behind it went belly up.

Something also not easily understood: our SaaS business grew 4x faster than Open Source right off the bat, and eventually even faster. People absolutely desire to outsource problems that arent there core strength, but that's kind of what the industries been seeing all along with the rise of cloud providers and other SaaS services.

I know for a fact that your competition is using your code, even where they've built a differentiated service. e.g. Embrace is using Sentry Symbolicator. Having built my own symbolicator before yours existed, that's easily months of work that requires highly specialized knowledge. Like maybe a few dozen developers on the planet could write that.

I know you get a lot of flack over BUSL, but I'm not sure folks appreciate just how much of Sentry is open source and how much you're giving away, some of it of very high value almost exclusively to your competition. I mean who but a Sentry competitor would need your symbolicator? No one.

Meanwhile looking at https://github.com/getsentry/symbolicator/graphs/contributor... I'm not seeing what looks like too many, if any, outside contributions.

More interesting would be what impact switching to BUSL had on your own business. Did growth accelerate after the switch? Was business declineing before the switch and did it pick back up afterwards? If there was a positive change in business growth trends, were there other thing the business did that may have accounted for the change?

I'll touch on it when we talk about relicensing, but the tl;dr is it didn't impact our business at all. It did however succeed at its goal of removing a nuisance (a story for a future post).

They pulled a switcharoo a couple of years back, switching to the BUSL source available/eventually open license.

There’s a lot of discussion about Sentry’s approach to open-source here, including many comments from people who work there, including the CTO and the Head of Open-Source at Sentry:

https://news.ycombinator.com/item?id=36971490

https://news.ycombinator.com/item?id=36990036

I've read comments from both threads. I still don't know why Sentry moved away from open source.

Why wasn't it sustainable?

Will put on my list for potential future topics (though we're going to talk a lot about this from a corporate point of view too).

OpBeat was another Sentry fork I remember, but they've been long gone too.

Just wanted to make sure I remembered right. Maybe only the client was based on Sentry, but I'm not sure.

https://github.com/opbeat/opbeat_python/blob/master/CHANGES....

Hey, thanks for this! I was just looking into this a few minutes ago and didn't know there were open source options.

Reply on news.ycombinator.com