Sentry: From the Beginning
cra.mr
cra.mr
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.
Building stuff for primarily developers is not easy, and I think they are doing great in that front.
I like when a founder is realistic about things. Nice read.
> 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?
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.
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 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.
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.
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.
You can still run it for your company for free, if you feel like managing all of the infra it requires.
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 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.
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.
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. :)
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.
That's because open source is generally not sustainable - it's reliant on being funded by other means of revenue generation.
Why wasn't it sustainable?
https://github.com/opbeat/opbeat_python/blob/master/CHANGES....
sentry from github works most of the time, but the setup process is such a PITA.
Generally speaking though we deploy our git repo to prod multiple times a day. So if you contribute changes, they deploy fast :)
edit: Just wanted to add, I say this as a happy Sentry paying user for more than a decade now.
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.
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.
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.
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.
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 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).