Sentry: From the Beginning(cra.mr)
cra.mr
Sentry: From the Beginning
https://cra.mr/sentry-from-the-beginning/
57 comments
I didn’t know about Sentry origins as django-db-log. This was a good read, I had the pleasure of interacting from a few people and Sentry and they really seem like a cool group of people.
Building stuff for primarily developers is not easy, and I think they are doing great in that front.
Building stuff for primarily developers is not easy, and I think they are doing great in that front.
Oh man, finding django-db-log was a game changer for me. The "errors as emails" was nice, but it didn't scale well when you had a number of Django sites to support. Having historical data about errors made my code so much tighter. Plus it reminded me of something I had built in ASP (god help us all) years before but hadn't figured out how to replicate well in Django.
> So how do you replicate that? I don’t have an answer
I like when a founder is realistic about things. Nice read.
I like when a founder is realistic about things. Nice read.
But he did add that perhaps the best way is to solve your own problem. As a founder, I also can only think of my own problems that I faced while working on projects and businesses.
A jealousy-inducing OSS fairy tale :)
> 2x the pain when you’re also on call at your day job
I know this is a side point, but I imagine people might be interested in the challenges of being able to work a second job while not annoying your employer. How did you manage it?
> 2x the pain when you’re also on call at your day job
I know this is a side point, but I imagine people might be interested in the challenges of being able to work a second job while not annoying your employer. How did you manage it?
> I know this is a side point, but I imagine people might be interested in the challenges of being able to work a second job while not annoying your employer. How did you manage it?
I ran my company (https://buttondown.email/) as a side project for ~three or so years before taking it full time and it was _similarly_ in a position where I could get paged for downtime or plumbing-related issues. My suggestions:
1. Honestly, choose a project where downtime or operational issues are less prevalent. This is a cop-out answer, but when you're evaluating potential projects it should be top of mind.
2. Be very up-front and honest with yourself and your employer about your commitments and your priorities. My personal rule was to only ever look at Buttondown-related stuff outside of what I considered my "core" working hours unless I was getting paged, and even then responding to pages would wait until my meetings or time-sensitive work was finished.
3. Set a schedule and rely on the schedule. For me this ended up being "side project hours are from 7-9pm M-F and 3-8pm Sat"; at times I wanted to do more and at times I wanted to do less, but the former path leads to burnout and the latter path leads to languishing.
I ran my company (https://buttondown.email/) as a side project for ~three or so years before taking it full time and it was _similarly_ in a position where I could get paged for downtime or plumbing-related issues. My suggestions:
1. Honestly, choose a project where downtime or operational issues are less prevalent. This is a cop-out answer, but when you're evaluating potential projects it should be top of mind.
2. Be very up-front and honest with yourself and your employer about your commitments and your priorities. My personal rule was to only ever look at Buttondown-related stuff outside of what I considered my "core" working hours unless I was getting paged, and even then responding to pages would wait until my meetings or time-sensitive work was finished.
3. Set a schedule and rely on the schedule. For me this ended up being "side project hours are from 7-9pm M-F and 3-8pm Sat"; at times I wanted to do more and at times I wanted to do less, but the former path leads to burnout and the latter path leads to languishing.
I wasn't as rigorous about it as you around having a fixed schedule, but I applied similar principles:
Avoid doing any work on my side project while at my regular job (unless it was needed by my regular job, e.g. on the open source front), and never let my responsibilities of my regular job slip or become a lesser priority.
The real challenge here: running an infrastructure service as a side project is what nightmares are made of.
Avoid doing any work on my side project while at my regular job (unless it was needed by my regular job, e.g. on the open source front), and never let my responsibilities of my regular job slip or become a lesser priority.
The real challenge here: running an infrastructure service as a side project is what nightmares are made of.
Will add to the list of potential topics. Its definitely a challenge, and does require personal sacrifice (e.g. its really hard to balance the demands of both jobs).
I wanted to go deeper on so many things, but I also didn't want this post to be 5,000 words long :s
My cofounder was in a similar but different position at the time. He was at GitHub and also had two young kids. I'm happy the outcomes are looking good for us, because damn was that period of life painful for all.
I wanted to go deeper on so many things, but I also didn't want this post to be 5,000 words long :s
My cofounder was in a similar but different position at the time. He was at GitHub and also had two young kids. I'm happy the outcomes are looking good for us, because damn was that period of life painful for all.
I’m not David but in the same situation before and there are from my experience two important parts: 1) having a good relationship and 2) setting clear boundaries. It’s not a given that it will work out but good faith negotiations are an important start.
It will be close to impossible in a mega corp with strict rules. For instance doing this at Apple is from what I have heard effectively impossible. On the other hand I know folks who left to a smaller startup and they took that job under the precondition that they can bootstrap their side hustle alongside.
It will be close to impossible in a mega corp with strict rules. For instance doing this at Apple is from what I have heard effectively impossible. On the other hand I know folks who left to a smaller startup and they took that job under the precondition that they can bootstrap their side hustle alongside.
One option (the one that I took) was to own both companies - in this case an agency that gave birth to the side project that became Flagsmith.
and without burning ones self out? or crossing ethical/personal boundaries?
I love side projects so much and hate the grind of day-in-day-out repetition, I just became a contractor.
One thing you can do is try and find AOR clients. For example, I have a very strong relationship with several other agencies and one even keeps a desk for me. Which at times feels like Im just working for them.
Then I can bail or chose to work on whatever. 2 years ago I joined a start up for some time. etc.
I love side projects so much and hate the grind of day-in-day-out repetition, I just became a contractor.
One thing you can do is try and find AOR clients. For example, I have a very strong relationship with several other agencies and one even keeps a desk for me. Which at times feels like Im just working for them.
Then I can bail or chose to work on whatever. 2 years ago I joined a start up for some time. etc.
AOR?
Usually Agency of Record. But anything that says "long term contract".
Perhaps “At Own Risk”, “Agent Of Record” or “Authorized Organizational Representative”?
or Available on Retainer?
Don't get jealous. Get inspired :). I do understand what you mean though.
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/
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.
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.
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.
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. :)
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 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.
> 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.
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.
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.
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.
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.
Fun fact: we acquired a company (specto) which used our open source symbolication infrastructure (underlying library to sumbolicator). Was a nice discovery.
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
https://news.ycombinator.com/item?id=36971490
https://news.ycombinator.com/item?id=36990036
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....
https://github.com/opbeat/opbeat_python/blob/master/CHANGES....
> Sentry abandoned open source
sentry from github works most of the time, but the setup process is such a PITA.
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 :)
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.
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.
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.
Hey, thanks for this! I was just looking into this a few minutes ago and didn't know there were open source options.
Looking forward to reading more of these, thanks for writing them!
Sentry has exceptional customer service (reached out multiple times and always get a prompt useful response or bug fix), and I'm happy to be a customer. I rely on their crash reporting for native programs for an open source game engine I work on (see profile), and without that observability resolving user crashes would be 1000x harder. And it couldn't have been simpler to integrate. Such a good service.
Sentry has exceptional customer service (reached out multiple times and always get a prompt useful response or bug fix), and I'm happy to be a customer. I rely on their crash reporting for native programs for an open source game engine I work on (see profile), and without that observability resolving user crashes would be 1000x harder. And it couldn't have been simpler to integrate. Such a good service.
Congrats on the wonderful journey.
Wondering how come Disqus allowed this to spin off into another company? Could they not claim that the code add belonged to them? Was it that everything was open source licensed that they could not claim rights, or were they just nice people?
Wondering how come Disqus allowed this to spin off into another company? Could they not claim that the code add belonged to them? Was it that everything was open source licensed that they could not claim rights, or were they just nice people?
I started Sentry before Disqus, and even if it wasnt disclosed as prior invention (PIIA might be something youve seen), I had the support of the founders to continue to develop on open source. Its also impotant to note that all the code is governed by the LICENSE, which was BSD-3. I think you've just gotta find companies that recognize the value things create.
I will say I drew a line personally: I only ever worked on projects that helped Disqus during working hours, so if I wanted to just build fun unrelated features (even on Sentry) I did it in my evenings/weekends. Sometimes that did mean contributing to Sentry, but it was to fix things that specifically helped Disqus (such as overloading the production services when we had an outage).
I will say I drew a line personally: I only ever worked on projects that helped Disqus during working hours, so if I wanted to just build fun unrelated features (even on Sentry) I did it in my evenings/weekends. Sometimes that did mean contributing to Sentry, but it was to fix things that specifically helped Disqus (such as overloading the production services when we had an outage).
Thanks for the explanation!
The ~15 year old application that I work on had functionality to record errors to its database and a dashboard in the admin tool. We eventually moved to Sentry.
That's both positive and inspiring for people working on open source projects. Thanks for sharing!
cec
My co-founder and I also faced a similar decision to what David describes in the earlier post about seed funding: From the start I was very much into the indie hacker mindset, but we came to recognize that there's an opportunity to make a significant impact beyond my initial ambitions, and so we are currently navigating the process of raising a seed round.