zeeg

Just want to say I appreciate your stance.

(also no one should feel like they have to contribute to our SDKs, but please file a ticket if somethings fucked up and we'll deal w/ it)

We’ll fund solving this as long as the committees agree with the goal. We just want standard tracing implementations.

(Speaking on behalf of Sentry)

Yes! Its a bit deeper than that but its fundamentally a packaging issue.

Food for thought- the subjective nature of both of those is exactly why it shouldn’t be bundled.

It’s a bit deeper than that. The SDKs that library authors implement need to be extemely minimal. The collection libraries that vendors implement based on imo should also be minimal.

OTLP imo doesn’t even need to be part of the spec.

But minimal would also mean focusing on solving fewer problems as a whole. Eg OpenTracing plus OpenMetrics plus OpenLogs. I only need one of those things.

I totally agree I just wish we could do it in a way that doesn’t try to lump every problem into the same bucket. I don’t see what it achieves personally, and I think it’s limiting the ability for the original goals of the project to be as successful as they could be.

We just rewrote our most heavily used SDK to run on top of OTel. What do we gain from it failing?

We also make most of our revenue from errors which don’t have an open protocol implementation outside of our own.

Author here.

Y’all realize we’d just make more money if everyone has better instrumentation and we could spend less time on it, and more time on the product, right?

There is no conspiracy. It’s simple math and reasoning. We don’t compete with most otel consumers.

I don’t know how you could read what I posted and think sentry believes otel is a threat, let alone from the fact that we just migrated our JS SDK to run off it.

So you’re saying it makes my thinking more clear? :)

This is what happens when you use a tool designed for authoring code to also author content.

Author here.

OpenTelemetry is not competitive to us (it doesn’t do what we do in plurality), and we specifically want to see the open tracing goals succeed.

I was pretty clear about that in the post though.

Author here.

That’s kind of making my point for me fwiw. It’s too complicated. I consider myself a product person so this is my version of that lens on the problem.

I’m not dismissing the people problem at all - I actually am trying to suggest the technology problem is the easier part (eg a basic spec). Getting it implemented, making it easy to understand, etc is where I see it struggling right now.

Aside this is not just my feedback, it’s a synthesis of what I’m hearing (but also what I believe).

The challenge with making statements like this is you're making them against not only the person who made the decisions, but also the person who holds 100% of the facts, and will openly share them.

So lets talk about the facts, because the paint a pretty clear narrative, rather tha one that people would prefer to believe.

1. I built most of Sentry (back then), and while we had a few contributions here and there, it was almost exclusively my time, or future employees times. So no community contribution concerns.

2. We relicensed because of a new threat, not one that existed 16 years ago when I started the project. That threat was GitLab, who was openly trying to commercialize Sentry. They never once contributed to the project, nor did they want to contribute back as part of that strategy. I know this to be true because I asked them to.

3. We built the FSL because the BUSL did not create a strong enough conviction to our values - of which we repeatedly have put words into action on. We wanted to cement those values, and make it easier for people who had our same concerns, but also wanted to create more open source, to be able to achieve that _without_ undue risk or legal fees.

There is a huge difference in the way Sentry operates, and the way some of these other organizations have chosen to relicense (or in some cases, legitimately rug pull).

So you can say what you will, but we've always been straight forward with our beliefs, and talk about these things publicly all the time. I'm not here to convince you of changing your beliefs, but I will never sit idly when people spread false information, especially about us.

https://cra.mr/the-busl-factor

https://cra.mr/open-source-and-a-healthy-dose-of-capitalism

This is something we're (Sentry) not happy about. Always hard to maintain the simplicity with growing product functionality. There's efforts underway (e.g. https://github.com/getsentry/self-hosted/issues/1763) to reduce the footprint if you only need portions of the functionality.

Where was the rug pull? The only people negatively impacted by Sentry's relicensing were people trying to monetize it. Did we negatively impact you? Anyone else in the community? Not that I've ever seen evidence of.

Live and die on your hill. We'll keep focusing on building our product - which requires us to be able to be able to pay developers for the enormous amount of time it takes them.

Its literally described as open source all over.

https://www.databricks.com/blog/announcing-dbrx-new-standard...

Its even implied in comparisons everywhere:

> Figure 1: DBRX outperforms established open source models on language understanding (MMLU), Programming (HumanEval), and Math (GSM8K).

> The aforementioned three reasons lead us to believe that open source LLMs will continue gaining momentum. In particular, we think they provide an exciting opportunity for organizations to customize open source LLMs that can become their IP, which they use to be competitive in their industry.

Just search "open source".

Did you read the post? I ask because based on that comment it sounds like you didn't.

We have enterprise customers - you don't need artificial lock-in for that.

It looks as if this was published after the update, which you should take a look at if you haven't. That should answer some of your concerns.

https://twitter.com/zeeg/status/1743384320637849652

That said:

B) These arent fluff features we're building, and one of the most important features we need aggregate data on is core to our business (fingerprinting). The over rotation on generative AI in the topic is the problem - thats not a focus for us.

C) This has nothing to do with investors, and Sentry's well capitalized both from prior rounds as well as cashflow. This is simply us needing to be able to develop stronger features that have moved beyond what we can easily capture in hand-to-hand development.

Hard to tell as we always advertised with Syntax. I would say the investments are related, but not connected (and made independently). We love Syntax, believe in brand advertising, and wanted to push more thre. We also hate the CX of cookie banners, I personally dislike wasteful tracking, and wanted to push the boundaries a bit on that front.

Agreed! There's some things we think customers won't care about, that we'd like to leverage in general (latency benchmarking for example), but not everything is that.

Our current thought process is to support two additional consent mechanisms:

1) An opt-out for sharing data which has no risk of exposure to customers (e.g. think about our fingerprinting algo - we can train better heuristics for that without giving away any of your data).

2) An opt-in mechanism for sharing data, in exchange for access to the functionality, for anything that goes beyond the above. This is less well defined, and internally would be our default stance.

Our big TODO at this point is to clearly define those, build the consent mechanisms, and determine what, if any, updates we need/want to make to the ToS before enforcing it.

Its not just simple logs at the end of the day, so there are two things to be aware of:

1. Logs will, no matter how well you do your job, contain something sensitive. Typically this ends up being customer data (PII). PII is the largest customer to most customers.

2. IP is _very_ present in logs, and especially in the types of data Sentry gathers (e.g. stacktraces). While not everyone is hyper sensitive to their code being on other systems, some companies treat it much more seriously. One particular example is the gaming industry, where projects are kept tightly under wraps and often take a decade+ to commplete.

Regarding your note on the Tos Change, ours (Sentry's), and every other coroporate ToS I've ever looked at, always included some kind of clause to allow a change within a time window, without updated consent. As an implementor I understand the need for this (think about maintaining old versions of software, same paradigm), but as a customer I understand your sentiment as well.

That said, many customers end up on annual terms of service with slight variants, particularly larger customers. This is a typical negotiation process as many of the needs/demands of organizations vary slightly.

David from Sentry-

I just wanted to say that we've heard your feedback and are going to follow up. I'm not going to say we'll make any changes to the ToS, but there is at least a huge lack of clarity and clearly some triggering language in a number of things.

There are many things we want to be able to do - much completely unrelated to the current generation of LLMs - that we simply cannot due our current set of terms. A good example of something that you might not care about, but is not explicitly clear in our terms: can we show your production average latency comparies to other applications? What about other web services? Other Python web services?

I think we can all agree we missed the mark on comms here, and we may need to clarify and/or re-think part of the data use strategy. We certainly are not intending to funnel customer IP or PII into a random chatbot, and at the end of the day trust is involved in these things as we cannot explicitly label every feature we have built or plan to build within our ToS.

While I dont think HN often represents our customer base 1:1, I do know our customer base also lurks here, and data security is and always has been of utmost importance to us. That isn't changing, and there's no conspiracy with investors or anything else going on.

Let me circle back on the Vite issue. Bundles are the biggest challenge when doing this turns out :)

Would you mind opening a GitHub so we can circle back there?

Regarding .NET - it’s coming to all Sentry SDKs (even mobile!). They were looking at .NET already but I’m not sure off hand what prevented its release. I’d expect our other core languages have full support in the next 60 days.

In this case it makes sense: it’s a UI widget. We wrote the proxy also in Node just because you already likely needed JavaScript to install the UI component that it felt logical.

Aside, 2019 and onward JavaScript has become the largest and fastest growing ecosystem of developers.

To others feedback though there’s no reason we should force you to take a bundler running in your UI. We’re gonna fix that quickly.

Don’t disagree, but technically the docs are in the same repo. Not easily consumed though.

We removed bits from the readme as it kept becoming duplicated and eventually wrong. I think that’s the usual reason folks like to avoid it. DRY and all.

Yeah it absolutely could. Our docs aren’t great here and we may need to improve the APIs but it was important for us to not couple this to Sentry.

The idea is that any data source could stream to the sidecar and at the same time consume from it with a curated panel in the UI.

If you’re interested in poking around def hop in our Discord (https://discord.gg/sentry #spotlight) and let us know your thoughts.

That’s a good way to think about it yeah. It’s not 1:1, and also can be extended beyond Sentry, but that was our MVP.

Both. Fwiw lots of folks have yet to invest in OTel so the market is super open. We’re also trying to adjust our approach to leverage OTels community instrumentation when it makes sense. That means that ideally you’ll be able to invest in OTel if you want and we’ll just consume those spans.

The other thing to note: OTel doesn’t do everything and Sentrys error context is a big part of the value prop.

What’s an example concern? It shouldn’t anymore than Sentry already does

That’ll get you the sidecar but not the UI widget. I think we could:

1- serve the widget from the sidecar 2- add the CDN distro

This seems to be a super shared point of view. I’ll admit we were a bit fire-and-forget on the homepage and definitely agree with all the feedback that we need to explain what it is better.