David here from Sentry. Just saw this ended up on HN. Happy to answer any questions about how we approach open source, the business, or anything else about Sentry.
David, I've wanted to tell you for a long time: thank you. You probably don't remember me -- I was an admin on the wowdev wiki, way back. GitLab and Sentry are my two favourite examples of successful open source companies. Sentry, the tool and the company, are both really awesome - it's been crazy useful to us at HearthSim and has served me personally really well since its first versions.
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.
It's really tough. Even basic problems are extra painful because of the limited tooling on GitHub.
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.
> 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).
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.
Skimmed it a while back, but didn't realize it had centralized views. I will say our biggest challenge is mostly around PRs and community issues. We use a big ol' Excel sheet for sprint planning (inspired by my Dropbox days). You can use GitHub's global views for some of it, but they dont show mentions, and no one has the time to try to assign every little thing to the right people.
What if another company takes open-source Sentry and start offering hosted versions of it, competing with Sentry.io and in the end putting Sentry.io out of the market? Would that make you regret making your software open-source?
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?
There's only two things we really consider as protection of our product and brand:
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 see that copy-pasting and using Sentry's name is, but if a competitor credits you, but still offers the hosted service, would you consider it 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)
Unless you want to maintain a fork we could very easily make life difficult ;)
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.
Opbeat forked the clients not the server. The client forks are fun because we are still credited in their licenses. Most of our competitors have their clients open source so that is not really a concern anyways.
Generally you license the code so competitors have a disadvantage e.g. with GNU licenses, they may have to open source any changes they make. As the copyright holder, you can do things with the code that they cannot (since you don't have to follow license restrictions), i.e. create premium features.
Thats a common situation, but we explicitly refuse to do that. I have a strong opinion that it doesn't represent what open source should be, and thats absolutely free software. I do understand that some things are considered necessary, but we're trying to prove thats not the case.
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.
What do you think about using a license that forces freeing any changes to what you shared but doesn't affect anything linking to it dynamically or statically? As in:
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.
Definitely not a license expert here. Lots of legal folk I trust would stand by "Apache and only Apache" for releasing FOSS, and I think one of the core reasons is patent protection. We may re-license Sentry at some point to Apache just because its a more understood model and as a growing business that may one day be important. It's also nice that it provides good out of the box tools that are widely supported (e.g. the CLA).
You should definitely check out MPL too. I was told it's like LGPL for static linking. As in, commercial integrators can use it without releasing their source. Only have to release improvements to sentry itself in that model.
How can you possibly know they've made changes to the software?
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.
How can I know? The same way as I know the vendor based their firmware on
Linux, so I am entitled to receive a copy of source code. Meaning, I can't,
technically.
I am thrilled to see more companies doing this. One of the key points that's not mentioned in your article, is that this provides incredible confidence to anyone who wants to design and build around your service. If you go away, or if the price becomes unreasonable, or for any other reason they have to, they can simply run their own copy.
It's really awesome to have an open source option for error tracking, we use it at GitLab and its been great. Kudos to the Sentry team, and thanks for entertaining my conversations on twitter every once-in-a-while :)
The most basic question: if people can host themselves, why do they pay for your service?
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?
There's a lot of things, but at the end of the day its marketing, and ensuring you challenge your customers to think about what really matters:
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.
If SaaS is cheaper, then that's the only argument we need. But it isn't clear that SaaS is cheaper.
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.
You're either ignoring the cost of engineering time, or you're underestimating the engineering time your clients might spend running their own instance.
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.
We started to pay for Sentry a few years back since it was both cheaper and easier than hosting it ourselves.
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 curious, what was the biggest cost, storage, CPU, RAM, bandwidth or matinence? Any kinda breakdown you could give?
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?
I'll echo what @robinwassen said. It's almost always going to be engineering time. We are going to have lower hardware costs at scale, but we are also going to charge a premium there (to operate our business, of course). It just ends up being more and more engineering hours the more you utilize things like Sentry, which often correlates to how successful your business is.
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.
That part isn't. Not so much because we care about it being closed source (a bit), but more because there's little to no value in it being open sourced.
Billing is all based on Stripe, so its not super heavy by design. We basically just synchronize the data that's in Stripe. That's changing a bit as we work towards a new model, which requires a lot more internal systems to coordinate, but generally not too complex still.
Hi David, I trialled the hosted version a month or two ago and it was slow. Specifically: The time it took for an exception to be reported via the API to that exception showing up in the web interface was too long (a minute maybe). It made trialling the product a little bit tedious. I ended up with rollbar for that reason. Would it be faster if I self-hosted Sentry?
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:
It's much easier to start open source, rather than tack it on after the fact. Depending on your business, it could also be a huge advantage. For us, being open source means companies like Uber and Airbnb, whom have ample engineering expertise, can still use Sentry. In another world they might have rolled their own. This opens up a big opportunity that you can take a number of business directions:
- 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).
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?
This is definitely a conversation we've had. In our mind, we think SaaS is the right way for our business to work. It lets us continuously ship, scale more easily, and in general provide great customer service and experiences.
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.
Open source is not necessarily free software, but often is, as that link clarifies:
> Nearly all open source software is free software, but there are exceptions.
The distinctions made in your citation make it clear that Sentry is both open source and free. I don't think there's any incorrect terminology being used here; can you point to a specific misuse?
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.
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.
Although the licenses and in some cases even the software is the same, the communities are very different.
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)
I have read it. They use a misleading definition of "free software":
> 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.
The FSF's definition of "free software" has been around for far less than the adjective free, and when some software is provided for no fee while being proprietary we're still stuck using the same word. How would you have wanted him to write that sentence? Insert "for no charge" or "gratis" everywhere?
