How Sentry Thrives as an Open Source Software Company
When I tell people that Sentry is open source, they nod, understanding that this is known to be a good, noble thing. Then, they have questions. Many questions. “You mean open core?” they ask. No. Open source. “So you sell professional services?” No. Head scratching, then a pause. “Then… how do you make money?”
In truth, these are not bad questions. The business approach to open source is changing, and Sentry is a steadfast representative of that change. But it’s been a while — 2.5 years, in fact — since we talked about how open source is a crucial part of our model (and how that enhances Sentry as a business). And sometimes, our approach creates a natural and healthy debate for us about how to prioritize resources. A productive tension, if you will.
So, how exactly did Sentry evolve as an open source software (OSS) company, and how does (or should) this change as we grow?
Some background for the as-yet-uninitiated (everybody else, feel free to skip ahead): You can use Sentry for your app monitoring needs in a few different ways. You can use the open source version of Sentry, which is free, by pulling it down from GitHub and hosting it yourself. Or, you can use the SaaS version we host for your convenience, from (again) free, all the way up to Enterprise.
As a result, Sentry’s business model doesn’t match what industry people have come to expect from open source businesses. Most folks seem to anticipate that open source companies will pursue a Red Hat-esque professional services model or an open core approach popularized by companies like GitLab. Or, they expect to see a business that sells proprietary software and leverages open source, community-maintained tools as “building blocks” of that proprietary software. (Goofy stock photos aside, this post is one of the few we’ve seen that represents how we see the current market.)
The professional services and open core approaches have worked for other open source companies, but we’ve chosen a different path.
Our founders didn’t expect Sentry to become the most widely-used error monitoring application for developers when they started working on an open source project about a decade ago.
But as more and more people started using Sentry, our team realized that it can be a huge pain to maintain Sentry on-premise. And so, after fielding one too many requests for it, we started providing a hosted version of Sentry in 2012 to ease maintenance pain and make Sentry more easily accessible. The only part of Sentry that’s not open source is billing code, the code we use to manage our production infrastructure, our marketing materials, etc. (which, we promise, you don’t want to see anyway).
Layering a SaaS model on top of Sentry has provided a lot of benefits. Most obviously, we gave developers the cloud version of Sentry they’d asked us for. A healthy SaaS business also allows us to directly invest in and manage more long-term, complex investments in Sentry, such as compliance and security features needed by larger organizations, which will allow more developers to use Sentry.
And, you can take a look at the code — everyone else has. On occasion, (even) we are surprised by the extent to which businesses value the ability to audit our codebase and submit pull requests to enable organization-specific use cases. (For example, Riot Games recently updated our Unity SDK.)
The benefits of this growth — and with serving users both on-premise and with SaaS — have come with additional tradeoffs, however.
For example, while all Sentry features are available via our open source, on-premise master branch, it’s been a while since we’ve cut an open source release — as some of you have pointed out. We’re working on fixing that ASAP. (And, in that vein, if you’re an engineer who wants to work on open source all-day, every day (well, during normal business hours, at least), we’d love for you to join us as an Open Source Engineer or apply for the Sentry Open Source Grant.)
The reality is that, given our business model, sometimes people want to use our free open source version. Ultimately, this can leave us in the position of being our own biggest competitor. And we’re okay with that. We want you to use a solution that’s right for you.
In short, our growth in the past two years has resulted in a lot of change, including hard internal conversations and micro-decisions about how we spend our resources. We don’t have to add wacky licenses or close our source code to succeed as an OSS product. We see OSS as our (not so) secret weapon, innately tied with our past and future success.