zeeg

Did you consider looking to see what they actually already do? There's a reason this works.

It’s not useful if it’s never read by agents - that’s the premise of the statement.

I'm not talking about RedHat, I'm talking about the perspective that "FSL / BUSL aren't effective enough". They solve the problem. O'saasy is just freeware at the end of the day, FSL creates more open source, and BUSL often has (though unfortunately the license doesnt require it).

The idea that FSL ~= Closed Source is entirely wrong and misunderstands the value that an open distribution gives. We have 10s of thousands of customers that run Sentry self-hosted. We regularly get contributations back to our core service - both in code and (what we prefer) other artifacts like feedback.

We were "Single Origin Open Source", which is extremely common whether people like to believe it or not. Its the entire premise of the sustainability issue in the industry. Thats not just an issue for commercial entities, its also most of the big open source software people rely on. In our case though we have a great business model that makes it entirely sustainable, and now have built a solid licensing mechanism around it that protects that, while ensuring our community is still successful.

Ive written about a lot of these kinds of things:

https://cra.mr/open-source-is-not-a-business-model https://cra.mr/open-source-and-a-healthy-dose-of-capitalism https://cra.mr/the-busl-factor

These same issues around single origin open source are why we started the no-strings-attached funding mechanism via Open Source Pledge (https://opensourcepledge.com), why we push Fair Source (https://fair.io).

Maybe others will find defensible models, but I'm skeptical. I also respect Adam, but last I understood it the model they were going after sounded pretty similar to trademark protection (which doesnt work).

The issue is these are mostly academic points of view. Sentry’s model on the FSL (and previously the BUSL) has shown to be working just fine at scale.

Whereas, for example, trademark protections have shown to fail easily.

So people can argue it doesn’t work, but so far we only have evidence to the contrary and Sentry is quite successful.

Clearly this is bait but we have done nothing but be supportive of small accounts.

It’s still $29, we still are extremely generous on forgiveness and sponsorships, and we still prioritize the long tail.

70% of our business is smb/mm, and if you knew anything about us you wouldn’t make the statement you said above.

If we have done something to show otherwise I would love to see it so we can address it.

Just want to say, absolutely this. Its an awfully confusing way to say: "if you make money, compile your own binaries or pay us". Have a feeling the confusion and FUD it causes will create more harm than good unfortunately.

No, its complicated and scales to servicing every customer in the world. Thats not the same thing.

Doesnt mean the complaints about self-hosted arent valid, but "literally has to scale to the most insane volumes of data" and "is not good software" are two different things.

We're building a cloud service at the end of the day - its a lot easier to optimize a multi-tenant install than it is a single-tenant install, and that complexity shows up in the self-hosted repo. Can't really avoid it.

If you - or anyone reading this - ever ends up in a situation where we came off as aggressive send me a direct email and I will take care of it. This is not something we believe in at Sentry, and while you cant manage everything, its important to us that we never become "of those companies" like so many other successful companies become.

david at sentry.io

fwiw I was always pretty transparent about our priorities:

https://blog.sentry.io/building-an-open-source-service/

We enable self-hosting because not everyone can use a cloud service (e.g. government regulation), otherwise we probably wouldn't even spend energy on it. We dont commercialize it at all, and likely never will. I strongly believe people should not run many systems themselves, and something that monitors your reliability is one such system. The lesson you learn building a venture backed company, and one that most folks miss: focus on growth, not cost-cutting. Self-hosting for many is a form of cost-cutting.

We do invest in making it easier, and its 100% a valid complaint that the entire thing is awful today to self-host, and most people dont need a lot of the functionality we ship. Its not intentional by any means, its just really hard to enable a tiny-scale use-case while also enabling someone like Disney Plus.

Any chance you can link me to the ticket?

Feel free to email - david at sentry

Define large workload.

Sentry runs large workloads and Postgres isn't a bottleneck. We have also never employed a DBA. Most users never need to shard their database, and at most can just partition datasets by tables for _extremely_ high volume workloads.

You just have to consider architecture and optimize things that are slow, just like any other software. Nothing is free at the end of the day, and nothing else gives you the flexibility that Postgres does, particularly these days with its growing high value extensions.

When you offer a subset of the product as open, and a subset as not open, its not open source. Pretty simple math for me.

This is not a comment on "which" OSI license they used for the open part, but I will not support people calling Open Core broadly Open Source, as its not.

This is the problem with the definition. If the product is trurly open source, call it that. If its not, thats ok, but don't. Core has no real definition.

I definitely would never call GitLab Open Source. I can't comment as much on the others. Sidekiq is actually how I think the world should work: its open source, and then they sell Sidekiq Pro. One is Open Source, one isnt. The issue is most people don't operate that way.

GitLab Community Edition is Open Source, GitLab is not. Cal.com isn't open source, but is the Cal product? I'm not sure. Given I started Sentry I can at least use it as an analogy. Early days Sentry was open source, but getsentry.com was not (which was our billing infra). No one would have called Sentry Open Core, because no part of "Sentry" was closed source. That's not true for most Open Core.

Postgres is not operated by the same people as Neon or Amazon, thats a fundamental difference. I was also not suggesting commercial cannot benefit Open Source (and would in fact quite the opposite).

In general I was not commenting if they're opposed, but suggesting an Open Core project is Open Source is not truthful. "Core" is a meaningless term, and if we suggest any Open Core project is Open Source, I can easily academically argue that the majority of businesses are Open Core, thus Open Source, and we'd all agree that's not true.

This project is Open Core, and thats fine, but Open Core is not inherently Open Source, and if we're going to care about that term in some contexts (e.g. with Fair Source) we need to care about it in all contexts.

I just wanna remind folks that Open Core is not the same as Open Source. I didn't look at specifics, but I was triggered by this comment:

Some people call our strategy "open-core" and that's technically right. Still, I'd rather say that we have two pieces of software: one that is open-source and another that is not. I think that's more honest because we're not trying to hide the fact that we're selling a non-open-source version of our software.

I'm not morally opposed to open core software - and any version of more open source is valuable open source to me - but I think its important we do not conflate the two, just as we need to not conflate other approaches like source available.

You have nailed their issues - packaging and their revenue model. If you align this well with your target audience the license would have not been a problem for them. Wrote about this a bit here: https://cra.mr/open-source-is-not-a-business-model/

No ones saying Fair Source is better than Open Source, but in your analogy one protects the commercialization of a project, and the other does nothing to protect the creators.

The clarity of what is and isnt permitted is something we'll be looking to make sure is enforced via the license, at least in FSL's sake. The intent is that if you're commercializing by say, providing support or integration services, that its totally valid. What's not valid is hosting a competitive offering using the source code. That is, with FSL you cannot spin up the project and sell it as a cloud service, but you can provide professional services to customers using said product.

If you decided to build something that tried to sneaky leverage the business model that funds development, that its so closely related to what the company would do, and then the company does it... well, don't do that? You'd be stuck on the old version. Thats the price you pay for trying to be sneaky. The license is effectively encoding a set of values/ethics in how people should run businesses, particularly when building on top of other peoples businesses. I think this is totally fine, so whenever people bring up these hypotheticals I just shrug them off, as they're an academic edge case that all but a handful of individuals will never need to care about them.

Also generally speaking, the case you're describing sounds more likely to be an integration say between your service and their service, or more specifically, your code and their service (say an integration between Sentry annd MyCoolTicketTracker). You could still sell that integration just fine, as its your code, not the FSL code. What you couldn't do is sell a cloud service that was MyCoolTicketTracker, that funnels to a privately hosted Sentry, and then exposes the functionality of Sentry into MyCoolTicketTracker. At that point you're commercializing Sentry itself, not your services.

FSL is strict on two years. We certainly would not promote a version that’s variable. You could make one, but it’s our job as a community to say “no!”

This isn't how Sentry works though.

1. You have a burst of errors - typically this happens first month when people dont understand their volume, or they had a runaway bug.

2. We rate limit/throttle you for your billing period. We also provide some tools that we'll eat various cost for periods of time (such as Inbound Filters and Spike Protection).

3. You never have to "contact sales", but you're certainly welcome to email support, and they almost always will forgive your volume.

It sounds like you want us to pick up the cost, which sure, sounds great as a customer, but we're trying to build a long term sustainable business. We can't just accept infinite data and not charge for it. All of that costs money, and while in some less common scenarios you can dedupe client side (we do), mostly they have to hit our servers, and that has a cost associated.

What's the concern here? The pricing is transparent, and yes we've adjusted it over the years to be more in line with our costs. We still charge you per error just like we have since I started the business, and we're very honest about that. If you scrolled down you would see a full transparent pricing calculator for all of our product offerings.

wrt Enterprise, you seem to not be the target person. Its primarily about access to humans. Terms, liabilities, SLAs, services, etc. If you are FAANG scale, yes it is about price negotiation as well. When you are in the buying cycle at a company that needs these kinds of things you are well accustomed to this kind of thing.

I have written quite a lot on my personal blog about our decisions and been very transparent. In particular, the decision on switching to BUSL orgininally I talk about here:

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

Its worth remembering that licenses are just part of the packaging of a product - part of the distribution model. Sentry is successful because we quickly found product market fit, continued to iterate, and made an affordable and well crafted product. Our distribution model - and in general our approach to affordability - is key to that, but the freedoms of open source software are less so.

For clarity, VC has never had anything to do with it, but we are certainly ambitious. Our singular goal from a product point of view is adoption, and we ensure that via accessibility and affordability. From a competitor point of view I personally think we've done better than most could dream of wrt marketshare. Companies like SigNoz don't compete with us today, and projects like GlitchTip don't even register on the market. Our competition these days is the fuzzy areas of the APM venn diagram like Datadog, New Relic, etc.

FWIW, if Sentry had stayed GPL 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.)

We never were once GPL, or remotely copyleft.

Is this an AI generated comment?

For the interested, might have finished a POC thats unfortunately not totally generic, but achieves what I'm after:

https://github.com/dcramer/peated/pull/171

Requires some duct tape for tanstack/query, but seems to work. Still doesnt _feel_ like a SPA due to the way transitions work, but it eliminates redundant network requests.

I want one fundamental thing: the ability to ask library authors to implement span annotations in their projects. Today that ask comes with way too much baggage. The SDKs are often extremely complex ("bloated", other's words, not mine), and on top of that, most of these library authors don't use or care about the standard. The latter can be fixed w/ funding, the former is what I'm concerned complaining about.

What I mean by that in practical terms is very easily articulated when we look at something like bundling of logs. We've had standardzed formats, adapters, and transports for logging for decades. Could they be better? Sure. Aint no future though where someone builds an SDK and no one ever again innovates or has an alternative path to achieving it. The same is true for everything, logs are just an an easy thing to pick on.

Take that a little further - why do I need a logging SDK bundled with a tracing SDK? I mean that very literally - why _must_ they be bundled? What do we get out of it?

You can argue that "just dont use the other parts", but thats an academic argument at best. In practice that just means you've got an overloaded SDK with a bunch of bias associated with it - in this case (in my opinion) a bunch of companies who don't really innovative pushing legacy telemetry concepts on the masses. That might not sound like a problem, but a developer can barely make sense of the docs, and even at the most basic level, I shouldnt need to make an argument about software branching complexity to other software engineers. They're simply trying to do too many things.

What that ultimately boils down to me though is: what problem is it solving? Tracing is a serious value add to _most_ stacks these days that requires immense amount of coordination to solve. It's not maintainable (easily) through patching other's code, which goes back to why I personally agree w/ OpenTracing's original pitch. However, why, with that goal unsolved, did we attach a bunch of other loosely-but-mostly unrelated problems to the spec? At the very least, problems that dont apply universally to the same audience. Why did we need a spec that bundled all of these problems, and continues to try to bundle more?

So I go back to the core problem: we want universal span annotations implemented across the ecosystem. I dont see what OTel is doing as the most effective way to achieve that goal, and I dont see the other goals they're trying to solve for as ones that are actually that important to most developers (and quite frankly, I could not tell you what many of those goals even are).

A lot of the development of OTel looks like two things:

1) Startups wanting easy access to telemetry, often without any product differention, thus, stakeholders who I dont find totally relevant to the conversation. I'm sure that comes off as me being an asshole, but its how I feel.

2) Big vendors trying to push consolidation on the customers, all competing with the exact same products (think Datadog and all its copycats, again often with no product innovation). This isnt totally a problem except it amounts to them pushing fragmented legacy concerns (such as outdated logging concepts) downstream.

All I want is great quality of data for both developers of libraries and developers of applications - those are the customers. I dont see those customers being serviced the best they could be, and I dont see the goals being met _because_ of the distraction, lack of focus, and as far as I can tell, lack of vision of the project.

I think anyone who's working on OTel, if they genuinely had the best interests of the developers in mind, would be hard pressed to answer why Sentry's support isn't an extremely desirable thing given our market reach. The people that care about the project want us involved (and if you're reading this, thank you for constantly pushing us), and I want us to also be involved. So far though we're constantly struggling to actually get an uninstrusive implementation in place that can work with our product, and what I'm asking for would solve for that, but to me looks like a cultural problem and not a technical problem...

The issue is we currently dont see a great incentive to fund a bunch of piecemeal standards that arent relevant to our product, and many library authors are not going to naturally invest into this. Even more say, many of these authors that I've talked to have no excitement what so ever about the standard, or worse, an active distaste. People can say they're wrong, but frankly, that doesnt matter. You dont succeed by thinking someone else is wrong, you succeed by building what your customers wnat.

That is why I would like to see the project focus on problems that people actually have, and do it in a way that doesn't create tradeoffs for developers. To me those problems are the ones that aren't achievable without this level of coordination. They are not shimming another log or metrics collector in place. Those things might be relevant to some people, and thats fine, but we dont need one be-all-end-all project to encompass all sorts of fuzzy semi-related problems.

I may or may not be making sense here, and I'm happy to chat about it more, though HN is probably not a good venue for that.

Guess I am unqualified to say that folks who say metrics, logs, and traces are the definition of telemetry is mistaken.

Says who? Sentry has many other types of telemetry and we’ve existed long before OTel. Who are these all knowing humans who say this is what telemetry is? Are they also going to build every collector for every kind of past current telemetry?

The whole idea that some marketing bs has translated to technology fact is why we’re in this mess.

Can you give more context on what you mean around sampling. What does an OTLP endpoint have to do with it?

imo Honeycomb pioneered this, and its the right baseline. There are limitations to it of course, and certainly its been done before at BigCo's that can afford to build the tech, but its extremely powerful.

The main argument for metrics beyond traces is simply a technology implementation - its aggregation because you cant store the raw events. That doesnt mean though you need a new abstraction on those metrics. They're still just questions you're asking of the events in the system, and most systems are debuggable by aggregation data points of spans or other telemetry.

As for logs, they're important for some kinds of workloads, but for the majority of companies I dont think they're the best solution to the problem. You might need them for auditability, but its quite difficult to find a case where logs are the solution to debug a problem if you had span annotations.

I actually meant trace ID and parent event ID (and ID was inferred). Parent comment is correct in that trace ID isnt technically needed, and is in fact quite controversial. Its an implementation level protocol optimization though, and unfortunately not an objective one. It creates an arbitrary grouping of these annotations - which is entirely subjective, and the spec struggles to reconcile - but its primarily because the technology to aggregate and/or query them would be far more difficult if you didn't keep that simple GUID.

It does have one positive benefit beyond that. If you lose data, or have disparate systems, its pretty easy to keep the Trace ID intact and still have better instrumentation than otherwise.

It is! But to prove your point, OTLP is actually just the transport protocol (Open Telemetry Transport Protocol). Its one of _so many things_ its trying to address. All of those things might be probems, but not everyone has those same problems (vendors, customers, and lib authors), and bundling them all into one umbrella just screams for me.

I actually have no need for a standard metrics implementation, just as an example. I never have, and I'd argue Sentry (as a tech company) never has. We built our own abstraction and/or used a library. That doesnt mean others don't, and it doesnt mean it shouldnt be something people solve, but bundling "all telemetry problems" into one giant design committee is a fundamental misstep imo.