How do you monetize an open source project?

That’s quite literally the million dollar question. The answer? Well, it depends.

Sentry’s been through quite the pricing journey over the years. I’d eventually like to write more about some of our incremental decisions, but in this post I want to focus on the early stages of the journey. We learned a huge amount around our early pricing decisions (successes and failures), as well as what is likely unique about our model and what can be applied to others.

There used to be a company of similar size to Sentry called Exceptional (or Hoptoad, or Airbrake, depending on which PE cycle we were in). They were the first company to market with an “error tracking” service. The difference between them and Sentry, at the time at least, was they focused on Ruby, and we focused on Python. So of course when we launched the cloud service, the first thing we did was look at the pricing model of the competitors. This looks fine was our approach, as we mimicked their packaging model. I believe the only real difference is we decided to charge less money.

We didn’t know how it’d work out. We didn’t know what our COGS model was (Cost of Goods Sold). We just knew we needed to make money to pay the server bill. $7 seemed like an ok way to do that. That might seem wild these days, especially with the costs of cloud providers, but that’s only because you’ve never tried running things for the lowest cost possible. This is an important segue I want to cover before covering pricing and packaging in more detail, as its something most people fuck up in the early days of their companies.

You see, Sentry was a side project, and the key decision we made was it must generate a profit. We weren’t some venture backed service that could throw away a ton of free services. We had to fund the cost of the hosting as quickly as possible. That meant charging every single customer for services rendered, and charging enough to come out at least a little bit ahead. Napkin math probably would tell you our margins were something like 10% back then, but it turned out that was totally fine, and easily fixable along the way. However, the way we got away with not spending any money was due to vendors providing us services through incubator programs.

The first few months of Sentry we hosted the platform on Heroku, which they generously gave us a monthly credit offset to help cover the costs. That was actually super important as Heroku was anything but cheap, especially to run an infrastructure service on. Unfortunately Heroku was tough to scale the service on as they had fixed constraints on the size of their VMS. We used Python which is notorious for its memory footprint, and that didn’t play nice with the limits Heroku applied. We made some money at this point, but not nearly enough to cover true managed hardware, so we began looking at alternatives that fit our budget.

For a brief period of time we ran some extremely budget server. Literally a single server. We’re talking about something that probably cost us $100/month, but included dual CPUs and enough memory to get you by. At some point we spun up a second of these to isolate the database from the application server. This was truly the wild west of running a managed service, and the risk was not lost on us at the time. We knew it was going to quickly be a problem, but we also knew we wanted real hardware, so we looked for affordable alternatives from reputable hosts. That led us to SoftLayer, which was eventually acquired by IBM, but was trusted by a lot of startups at that period of life.

SoftLayer, similar to Heroku, had its own incubator program. For the first year they gave us $1,000 in credit/month. On top of that they had an amazing turnaround on pretty beefy hardware. It was so affordable that I remember having to convince people that it’s actually way more worthwhile to vertically scale than it is to go horizontal. That is, we could easily buy a database server with 512GB of memory, which is far easier to manage than eight database services all partitioned. The only real problem is every once and a while someone would accidentally unplug servers in the datacenter. That’s a pretty standard problem, or at least was with SoftLayer, but hey at least we were making money?

So in the first year, we’ve managed to figure out an affordable situation for hosting, but we’re still charging $7 as our entry price. If you’re not super familiar w/ Sentry’s billing mechanics, here’s a quick crash course:

• You send us errors
• We charge you for those errors

There’s no other fees associated with it. That was true then and is still true now. No per-seat pricing, just usage-based. Except at the time, we didn’t quite charge you per error. You’ll recall I mentioned we were inspired by a competitor’s pricing model. Well it turns out that model was deeply flawed. You see, instead of charging say $1 per error, they charged $1 for a rate limit. That is, you would pay a fixed cost ($7 for Sentry), and get something like “5 errors per minute”. If you sent more than that they’d simply get discarded.

This model was deeply flawed for a variety of reasons, but one such reason was a complete mismatch between operating costs and value delivered to the customer. A customer could easily send us 1,000 errors a minute, and the cost to handle that level of volume - even when you’re discarding data - quickly outweighs the price we were charging. While there are ways to fix that, we used this opportunity to look more holistically at the problem. The problem then was the same problem Sentry sees today to some degree: you dont really need to see every error to get value out of Sentry.

Our first fixes to this were simply human led. We allowed customers to buy higher rate limits (e.g. 10 per minute, 20 per minute), and sort of just trusted that they would. It worked! Well sort of. Some people just opted for something that actually fit closer to their usage pattern, but not everyone did. In fact, I’ll give you a story of two customers at the time.

First, an extremely popular mobile email application. They were paying for our largest plan - I believe something like $200/mo - but sending data that was certainly one or two orders of magnitude above that. They loved the product, but we didn’t have a way to charge them more than $200/mo at the time. Remember, this was a side project, we weren’t running around with sales people, invoicing customers, etc. We optimized everything around people’s ability to self-service.

Second, an extremely popular marketing tool. They were on the same plan, and sending an equally excessive amount of data above what they were paying for. They were far less adamant about the product, and on some days I didn’t even want them as a customer. If there was a minor blip in the service, they were the first to complain. Reminder, this was still a side project at the time so I had a day-job. That meant it was often stressful for Chris and I to deal w/ customer support, and way more stressful dealing with outages.

Both of these customers had such extreme volumes of data that it had a tangible infrastructure cost associated with hosting them. We had one customer who loved the product, and one who didn’t. We knew the best thing to do was to find a way to be able to charge them more money for the amount of data they sent. So we set off to build that and then followed up with each customer.

To our surprise, the customer that loved the product didn’t want to pay more. The customer who was constantly complaining immediately jumped on the opportunity. What’s the lesson to take away from this? I’m not sure, but when I was a teenager I worked at Burger King, and there was an anecdote I will never forget: for every customer that complains, there are nine more with a similar experience. I’ve cemented this in my philosophy around development, to the point where I now believe over rotating on negative feedback is actually just biasing towards the customers who truly see the value in what you’re offering. The customer that was complaining really valued our product, whereas the customer that was happy was simply content.

Aside, if anyone from either of these companies is reading this <3, ya’ll helped us get to where we are today.

Eventually we were able to charge customers some real money to improve margins, to give us more breathing room. That leads us to the next early learning experience: $7 might as well be $0.

Once we were able to capture value from larger customers, even $200/month, it became quickly obvious that the low end would never generate that much money. It was still an important signal that people valued the product enough to pay for it, but it simply didn’t add up to anything. When we raised Seed Funding, we had nearly 2,000 paying customers, but only $600k in ARR. I’ll do the math for you: that’s $25/mo per customer. That’s not a scalable business. A core reason this was such an issue is because our value capture mechanism with pricing was misaligned. If you ask a customer how much they want to pay for a product, the answer is almost universally going to be “less”. You have to find the right middle ground that creates enough cashflow for you to keep investing, but also isn’t price gouging. We eventually settled on charging per error, which is what Sentry still does a decade later.

Now you might be wondering, what’s this have to do with Open Source, and how does it help me monetize my own project? The answer is, it has nothing to do with it, and it depends.

Open Source is not a business model, it’s at minimum a licensing model, and at most a set of beliefs. There’s no one right answer on how to monetize an Open Source project, because that’s like asking “How do you monetize a Python application”. For us, the answer was to build a cloud service. We’re an infrastructure tool, thus there’s obvious cost and complexity with running it. People would prefer to avoid that complexity - and they’re tolerant of the risk of offloading it - thus they’re happy to pay for our hosted services.

If you liked this article, I’d appreciate a share. Feel free to also reach out on X, I’m @zeeg. I’d especially be interested if there’s something you found helpful, or something you’d like to hear more about.