Sentry's company blog covering its error-monitoring product, Rust and Python engineering work, and its open source licensing decisions.
Commenters mostly discuss Sentry's relicensing; an employee says outside commits barely changed (3.5% to 3.4%), and others debate the exclusivity period and terms updates.
For additional context, here is a copy of the email we (as a current Sentry customer) received earlier today:
---
As you may have heard, we are beginning to make investments in machine learning ([0]) to improve our product experience along with launching an EU data region ([1]) for Sentry.
To support these new product offerings, we need to make the following changes to our Terms of Service (TOS):
- Update Sentry's data usage rights to use the error and other data sent by our customers to Sentry for AI model training and other product development efforts (but only in an aggregate and anonymous manner for any external-facing uses); and
- Update our existing data locality language to align with our making new data regions available.
We are also making a few administrative changes to our TOS for further clarity. Please check out our Change Log ([2]) and the full text of our updated TOS ([3]) for more details.
The updated TOS goes into effect on February 3, 2024 (the “TOS Effective Date”). The updated TOS applies to [removed customer name] as follows:
- If you have an existing free subscription to use our products and services (“Service”), your continued use or access of our Service on or after the TOS Effective Date will be deemed to be your assent to the updated TOS; or
- If you have an existing paid subscription to use the Service, you will stay on the existing TOS through the end of your current subscription period. The updated TOS will apply to you beginning on your…
I have a tremendous amount of and appreciation for Armin Ronacher and many of their fabulous Python libraries which I use regularly. However, this blog post is odd. It says that the open source sass model "has worked out very well for us", but then goes on to say "at one point someone has to make money somewhere.." in order to justify abandoning open source licensing of Sentry.
Maybe "worked out great" means that they got a ton of publicity and traction because they were open source, and now they are ready to abandon open source so they can monetize the traction they gained from being open source in the first place?
Sentry certainly doesn't have any obligation to continue being open source- the old code is still open source- but these events make me question any companies commitment when they claim to be open source. It seems that you can't take any company at their word, even when they publish multiple blog posts about how "committed" they are to open source- because in the end, many companies will do what Sentry did and will dump open source the minute they have gotten what they want from it.
[https://blog.sentry.io/2019/02/14/sentry-thrives-open-source-software-company, https://blog.sentry.io/2016/10/24/building-an-open-source-service, https://blog.sentry.io/2015/06/30/driven-by-open-source]
And if there was any doubt about Sentry's willingness to use and abuse open source- months after this announcement, they continue to advertise being open source on their site,…
I have been aware of Sentry for years, but I've never used it and haven't followed the company closely. Reading Armin's post, and the official Sentry announcement [0], this strikes me as pretty reasonable.
Sentry is about 11 years old. The industry has changed a lot in 11 years. There are people and companies around now that can build direct competitors more quickly than they could 11 years ago. The question raised in the Sentry post is completely valid: Was the license chosen 11 years ago the best one to base a company off of? A company relicensing its software after 11 years is a lot different than a company waving the open source flag for a year and then closing off access.
I appreciate the work people are doing to find a middle ground in the open source world. Purist approaches are important in many areas, but can't work for everyone and for every project. People who are suggesting that Sentry is no longer open source have a point, but there is also a world of difference to me between a company using a BSL, and a company whose entire codebase is a black box to the outside world.
One of the key questions I ask about companies built around open source, is "Are you being honest about your business structure?" I'm fine with middle-ground open source licenses as long as the terms are clear and transparent. I have no respect for hidden small-text clauses that put legal limits in place which contradicts what a company's PR copy says.
I say all of this from the perspective…
There is a lot of overlap between logging, monitoring and crash/error reporting. In Sentry with some systems it does hook up to your logging framework to gather extra context through breadcrumbs or adds a hook to send logged error reports (in addition to the error reports from exceptions and crashes). They also follow logging good practices and integrate with them, but if you need logging, you can't use sentry for that. It only keeps the relevant information to a specific crash, and it aggregates data from crashes of a specific type so you won't even get historical data from crashes in some instances. Quoting from one of their blogs:
>>>
Sentry is built on top of best practices like logging. However, this can cause confusion and signal-to-noise issues if you don’t understand the the difference between logging and error reporting.
Throughout your application you are likely logging many kinds of events. While these are commonly errors, you are probably logging a lot of debug information as well. This is the fundamental reason why logging has levels (e.g., debug, warning, error). When we abstract our crash reporting through logs, the challenge is to differentiate between actual errors and debug noise.
>>>
https://blog.sentry.io/2016/02/09/what-is-crash-reporting
I wonder if they have a major Postgres database that hit transaction ID wraparound? Postgres uses int32 for transaction IDs, and IDs are only reclaimed by a vacuum maintenance process which can fall behind if the DB is under heavy write load. Other companies have been bitten by this before, eg Sentry in 2015 (https://blog.sentry.io/2015/07/23/transaction-id-wraparound-in-postgres). Depending on the size of the database, you could be down several days waiting for Postgres to clean things up.
Even though it’s a well documented issue with Postgres and you have an experienced team keeping an eye on it, a new write pattern could accelerate things into the danger zone quite quickly. At Notion we had a scary close call with this about a year ago that lead to us splitting a production DB over the weekend to avoid hard downtime.
Whatever the issue is, I’m wishing the engineers working on it all the best.
These requests to the Sentry company used to be sent over HTTP with no encryption
https://blog.sentry.io/sentry-ingestion-domains-updates/
https://cloud.google.com/blog/topics/partners/using-sentry-to-monitor-web-and-mobile-apps
https://old.reddit.com/r/PleX/comments/1b12phf/plex_sending_requests_to_017675ingestsentryio/
There has never been any resource record for any sentry.io domain in the DNS that is used by computers I control. This DNS is local and I control it. I saw a request to an ingest.sentry.io domain once while experimenting with Firefox. It failed
The DNS used by me only contains addresses for servers that I find useful
But every user has their own preferences. It is possible that some end-users might see value in allowing their computers to automatically send requests to sentry.io while receiving nothing in return. I am not one of those users