Building an Open Source Service
blog.sentry.io
blog.sentry.io
I get that for large companies it is perhaps better to just pay for the software as a service than to have an internal team dedicated to run it, but for small and super-small companies it is perhaps better to host it -- while accepting some (little) maintenance work and some risk of crashes for the low price.
So, if I'm building some software that will be used mostly by small teams, how can I make it open-source and still make money by offering it as-a-service?
1. You, as a developer, care about open source and want to fund it.
2. You, as a business, don't want to run more infrastructure.
3. You, as a business, care about expenses (and SaaS is cheaper).
4. You, as a developer or business, want the latest and greatest version all the time, and on-premise is not tailored to that.
(there are certainly more, but this is just some quick ones that come to mind)
For us a lot of these things come more easily as Sentry requires Serious Infrastructure(tm) unless you're a tiny little side project. If you are a tiny little side project, you can just use our SaaS for free.
Now on the counter side, the biggest reason you host it internally is compliance. Thats not usually legal compliance these days, but its more about controlling liability, or because you (usually incorrectly) think you are better at securing systems than other people. This has been shifting for a while with the rapid rise of AWS, and the time is absolutely right to focus on SaaS.
I run a small SaaS thing for which I charge $19/mo from a dozen clients. Each one of these clients could run it for $7 on Heroku. Someone could easily write a "Deploy to Heroku" button in no time.
I also thought about the free plan Sentry.io offers. That, as you said, eliminates all the small projects need to host themselves, but (I'm guessing) it isn't something that all companies can afford: offering so generous free plans.
I want to open-source it, but I'm afraid I'll lose all my income.
With the numbers you give, running your service themselves would save them $150/yr. That's 2-3 engineer hours per year to keep it running, keep it updated, keep it secure, and troubleshoot if things go wrong. If they spend more than 2-3 hours per year, they spent more on the engineering time than they would have paying you. This is even ignoring questions like "can that $7 heroku box handle the same load as your $19 plan?" or "do your clients even know how to set up/manage Heroku?"
Of course, people underestimate this effort/its potential complications, and overestimate their own abilities, so they often think this is a worthwhile tradeoff, but in reality it's usually not.
Might be cheaper for a lone hacker to self host on a VM running multiple applications. But if you are to host Sentry on a separate VM the cost quickly exceeds the SaaS service.
The reasons for self hosting are probably more related to compliance, security and direct database access than cost.
Just trying to figure out what made SaaS a good value vs hosting on site, were you able to get rid of a server & the associated power & maintenance costs?
On top of that an isolated dedicated VM and database probably cost about $20-30 per month.
To be honest I have not done any in detail breakdown, the main factor was that we did not want to spend engineering resources when we didn't need to.
Scrappy lean startup who has no resources and no traffic? Great you can bring up our docker container. Growing company? VC backed startup? Large corp? We offload all of your cares for a trivial cost, which is especially important since we're monitoring a core chunk of the 'health' of your business.
I guess this is probably not an issue for Sentry as it is now, but imagine some small company with a new software-as-a-service, super useful and loved everywhere, but without a well-established "name" in the market yet. Does the same answer still apply?
1. It's a big project, we are the experts (and the only real committers to the service). We also control commit access, so unless you want to maintain a complicated fork it's just not in your best interests.
2. We own the trademarks. This doesn't always help, for example this is literally a copy paste of our previous homepage: http://getsentry.cn/welcome
That said, there are companies out there who absolutely violate the 'spirit of open source' and use our code for other commercial entities. While we're not preventing them from doing that, I promise you we (and many of our users) absolutely look at that in a negative light. In a lot of ways, we're trusting that the fact that our advocates, who are developers, are also willing to do the right thing.
As you mentioned, this isn't really a threat to Sentry these days, but it was a fair concern two years ago. I think you really do have to put trust in the fact that most people aren't evil.
I have the impression that someone doing it would have a better image even with people loyal to Sentry: "well, these competitors here are not bad guys, just Sentry users like us, the only difference is that they are offering hosted Sentry for lower prices!".
(I'm not talking about the legal stuff, I'm completely ignoring it)
I don't have a concrete answer, but if it happens you just gotta work around it. Not much different than having a dozen competitors trying to do the same thing as you.
I think it's very easy to see you, as a commercial business, wouldn't want to put all of your livelihood on a project that has 150k lines of code and you know very little about. That's obviously not true for every project, but if your project is so simple there's no reason I couldn't just reimplement it anyways.
It kind of is, with Opbeat as their competitor which forked off from Sentry, but Opbeat have also kept the code that came from Sentry free.
It's also something that can limit the adoption of your product. I've worked with companies in the past have either refused to use allow GPL software, or would have a significant audit process you'd have to go through to be able to use it.
http://zeromq.org/area:licensing
Additionally, patent license provisions for using the shared code seem almost mandatory given the patent trolling we're seeing of both suppliers and users of whatever they manage to get through a patent clerk. All the FOSS licenses should try to include some protection there against beneficiaries suing derivatives.
Only with AGPL, and only if the competitors expose APGL-licensed software for interaction directly.
Suppose they've started offering Sentry-with-a-twist, how can you know they modified Sentry code? They may as well have written a separate software running in a different stack, but interfacing with Sentry and with the users and providing the twist.
What were the positives and negatives of going open source earlier?
- a hosted offering (effectively what sentry.io is going for)
- paid on-premise support (we offer this as well to select customers)
- on-premise enterprise offering (open core)
I'm not a big fan of the distraction of doing both on-premise and SaaS (thus our stance), and I really would love if we never have to build crippleware (open core).
Sentry is a fantastic tool; use it every day.
Is the plan/user/payment management also open source?
I mean, if I were to start a small SaaS service written in Python, could I use your code to bootstrap the "boring parts" of it?
Thanks!
At Automattic we do a lot of Open Source development. You can even see my PR introducing Sentry to our frontend: https://github.com/Automattic/wp-calypso/pull/2107 (Unfortunately removed, we are running custom solution right now, but thats another story..)
How are you dealing with discussions across your team on Github? Sometimes, we have to link to some discussion that is not happening in the open because of this or that business reason and we have to provide a context for colleagues but not everyone else.
At other times we want to encourage external contributions but some decisions happen outside of GH and contributors don't feel included.
Have you come across similar challenges?
One major problem that is still ongoing is code review. How we act on our own mandatory code review requirements as well as make sure we are responding to community issues and PRs.
Another big issue was the number of repos and lack of good centralized views. We've sort of simplified this by moving things into monorepos (e.g. All our plugins are going into a single repo).
The major missing piece for us on GitHub is being able to assign to teams vs just mentioning, and automating tools to guarantee those assignments exist.
The last bit is private discussions (e.g. Stop our competitors from stealing all of our ideas). We keep all of those big product design concerns in Dropbox Paper until we begin implementation. That's not only for keeping them secret but also because it's just easier to collaborate.
Also curious to learn more about your custom service and choice. Wanna drop me an email? david at sentry's domain.
Have you evaluated zenhub? We started using it and can't ever look back. Allows us to have as many repos as we have but still track everything centrally.
It should never be slow, so it's possible there was a misunderstanding in how something was working, a bug in an SDK, or we were simply having a really bad day.
Comparatively, Rollbar publishes some similar numbers, and suggest they are slower: http://status.rollbar.com/
While being as real-time as possible is nice, we internally have an SLA of 10s for end-to-end as we feel thats appropriate enough for a success metric. I will also say we did a lot of work around this recently to improve our 99th percentile. Part of that is our recent improvements around source map processing times:
https://blog.sentry.io/2016/10/19/fixing-python-performance-...
Great article. Wanted to throw out an alternative scenario: what if you arent a hosted saas trying to get lots of users but instead sell to enterprise with a focus on selling something like a distro (think like flavors of linux)? If it matters we are in machine intelligence mainly dealing with bank and telco.
We are open core with an oracle style licensing and support model. We have found this to be a great business but I always love hearing alternative opinions on this. Gitlab follows this as well.
Have you thought about an "enterprise version" with features that dont matter to startups?
That said, if the SaaS model isn't enough, we'll certainly explore other opportunities, but we're trying very hard to keep it FOSS without creating a separate version intended for different customers. It's not because it has to be that way, but for us we don't think its needed.
I do think theres a lot of software that won't move to SaaS any time soon, but that line is going to keep shifting.
Don't get me wrong, I think open source is great and far better than proprietary software, but we should use the correct terminology.
> Often the first thing you think of when you hear Open Source is “free”. In the software world, free software is often associated with being the inferior choice. That’s especially true given that historically, many businesses offer an inferior version of their product for free
Free software has a well-established definition, and that's the definition that should be used. Especially in an article that aims to educate people about the benefits of open source and free software.
> Nearly all open source software is free software, but there are exceptions.
Yes it is, or it's intended to mean the same thing, and that essay you linked to acknowledges several times that it's the same thing (or nearly the same thing).
Open source and free software are kind of like climate change and global warming: two terms that refer to almost the same thing but have different political slants.
http://jordi.inversethought.com/blog/5-things-we-have-forgot...
The reason I insist so much upon this is that I want people to remember that in order to qualify as "open source" it must provide the same freedoms as free software. How and why it provides those freedoms is a matter of philosophical differences, but in the end results in nearly the same set of free and open source licenses. It is very rare and unusual for the OSI and the FSF to disagree on licenses.
The Open Source community is creating high quality technology for techies to build great things.
The Free Software community is trying to protect end-user rights.
Those are very, very different things. Both have value, and they often overlap, but claiming they are the same is in my opinion quite disrespectful to the motivations of the people doing the work.
Free Software advocates will as a result tend to prefer copyleft style licenses that protect users, while Open Source people usually prefer liberal "business friendly" licenses that let them do whatever they like with the technology - including creating proprietary cloud-based or closed-source products (which deny the end-user rights the Free Software folks want to protect).
(edited slightly for clarification and to be less judgemental)