Open Source and Business

On today’s show, Mikeal and I talk with David Cramer, CEO of Sentry, and Isaac Schlueter, CEO of npm. Sentry is a developer tool for detecting application errors, and npm is the default package manager NodeJS. Both started as open source projects, which David and Isaac have built into businesses.

Our focus on today’s episode with David and Isaac was around building businesses in open source. We talked about why they decided to turn their side projects into full-time work, and how they experimented with finding steady sources of revenue.

We also talked about raising venture capital, working with investors and with community and different company approaches to developing open source projects.

So let’s get into the history of Sentry and npm before we get started. Both of you have pretty interesting backgrounds on how you built these businesses over a number of years. Sentry, David, I know that it started as a project that you built for work when you were at Disqus, and then it seemed like it was this side project, even though it was making money for years. It only went full-time a couple years ago, and you recently announced that you raised some venture capital. So in some ways it seemed, from reading about it, that you were reluctant to turn it into a full-time business. Can you tell us a little bit about that evolution, from going from a work project to a side project, to a full-time thing and why you decided to double down on Sentry?

Yeah, absolutely. So Sentry is pretty old, it’s about eight years I think, at this point. When I joined Disqus, they were using what eventually turned into Sentry. Terrible piece of code, so my first month there we kind of revamped it, brought it up to speed with the quality that we needed, and then kind of built it over the next couple of years. During that time it started getting traction.

I guess one thing that always fascinated me with open source was you can kind of share results with the world, they provide feedback; the communities are very interactive, and that traction kind of lead to us continuing to build it. That mean things like adding more support for other languages, for other platforms. Honestly, just adding things that we never needed ourselves at Disqus.

Then fast-forward a few years, we had built a little SaaS service on top of it, and it was making a little bit of money. The running joke when I kicked it off was, “It might cover beers.” So not a lot of ambition there. And here we are, about four and a half years since that day - we decided to go full-time last year, at the start of the year, so it’s been about a year and a half. The decision for us was we had a significant number of paying customers and it was really, really hard to have two jobs, so we had a decision to make. It was either to let Sentry kind of crumble, or take it to the next level.

One of the forcing factors for us was just in the last few years there’s been a huge amount of new competition in our space, and anybody who knows me knows that I’m not one to kind of let somebody step in and take over whatever I’ve been doing. So we really risked Sentry becoming obsolete if we didn’t double down on it at the time.

That also is kind of a lot of the reason we went down to venture capital, just to continue to compete and do well. But yeah, happy to dive into more specifics if need be.

[03:51] I’m wondering why you were so reluctant to just go full-time in it from the start when tons of people were using, big companies were using it, and people were paying for it. Why did it take so long to actually go full-time in it?

I’m fairly risk-averse, so I did not go full-time on Sentry until we were able to match salaries, and I was working at Dropbox before (Dropbox pays fairly well), so there was a little bit of that. It was also just, we didn’t really wanna go down the venture capital route. Honestly, it just wasn’t interesting to us; it’s a very different kind of company at that stage. Our goals now are very, very different than our goals were a couple years ago, but it is what it is.

At any time did the project kind of suffer from not having that kind of support?

I would say absolutely over the course of the years where it was purely a side project. I was building a lot of things at Dropbox during the prime of Sentry’s life, and juggling those two full-time gigs was really hard. So what it meant is the iteration speed at Sentry was greatly reduced. That’s kind of fixed today, but it took us a good year to really build up that momentum to start shipping things very aggressively again. And that was just because of the balance of building new things versus supporting new customers, versus supporting the infrastructure behind Sentry. Really tough to do when basically it was just me and my co-founder, who is a technical designer.

Isaac, does this sound at all familiar to you, or is your story a bit different?

It’s not that different. I created npm in 2009; it was a big part of the Node community for a long time. Obviously, it’s the thing that you do when you’re doing Node. And by the end of 2013 it had been my side project for a little around four years, and it was still running on donated infrastructure and just my side project while I was running the Node project Joyent.

It just kind of grew to the point where that approach no longer worked. We had about two months of… I joked that we had one nine of uptime and it wasn’t in the first digit, like it wasn’t in the tens place. Stuff would fall over and I would start getting messages and emails and tweets and angry GitHub notifications, and eight hours later I’d wake up and actually deal with it.

I had some help from some very noble souls who basically said, “Look, you can either start paying for this thing or take it somewhere else, because we can’t do this for free anymore.”

Around the same time, I was getting a lot of feedback about it from people working at pretty big companies, some of them saying, “Look, we really wanna use this thing, but a) we can’t trust it because it falls over all the time, and b) it’s all open source; we need a thing to host our private code and all the alternatives are kind of annoying to use and inconvenient, compared to how easy it is to manage open source code with this tool.”

That seemed like a happy coincidence of events there, and we raised some money from True Ventures and a couple of angels and started the company at the beginning of 2014. It really was a shift from… You know, it wasn’t a business with paying customers that I was really only working on part-time, it was something that I was doing literally the minimum required effort, because I was so busy with Node, and it was just falling into disrepair and that was really very sad to see.

So it seemed like the obvious choice was to start a company around it so that I could justify hiring some full-time, dedicated ops people and actually build some products to address the needs of companies that were using it to manage their JavaScript modules.

[07:57] Since then, we’ve grown to about 25 people now, we have two products and they’re growing pretty well. It’s a ton of work running a company, but at least it’s actually full-time, front and center work. That’s been sort of nice, to be able to focus on it.

I think we touched a little bit on your projects being open source, and that it was important to you. Do you think at all about how that might affect running a business while having an open source product and whether it might be a little more difficult?

I think for npm it’s always been pretty clear to me that the client itself, the CLI program is not what people are ever gonna pay for. They’re willing to pay for the service that enables the workflows that they’re using, but there’s no benefit really to not having the npm client be open source, or even most of our infrastructure, because really what they’re paying for is access to this gigantic community and a service that’s always going to be up and running.

If it was easy, I would have been able to do it without starting a company, and I think that that’s sort of the thing that puts us in that sort of strategic position in order to run a successful business. I have really no worries whatsoever about it being open source, and honestly the investors that I’ve talked to, some of them get it, some of them don’t. The ones that don’t are never gonna be a good partner anyway, so I don’t really care too much.

How about you, David?

Yeah, it’s kind of the same on our side. Sentry is an infrastructure service. A lot of people run it themselves. I would say they’re not overly thrilled with that idea, but due to the nature of data that Sentry works with, it’s kind of a requirement that we work on premise. But we get enough small businesses and even some larger ones that use our SaaS service, so it was kind of a natural fit, and it’s really allowed us to balance it out. The way we see open source is that it’s a thing that’s allowed Sentry to be accessible without us having a massive company backing a product.

I think that was especially great early on in the project’s lifecycle, and today in terms of marketing and other aspects it’s very valuable for us to continue to grow. Honestly for us, we think of it a lot like a traditional freemium model. We don’t offer free accounts on our SaaS service, but if you wanna use Sentry for free, you can just run the same code that powers our SaaS.

So Sentry and npm both started while you were at companies, or developed a lot while you were at Disqus and Isaac was at Joyent. Can you tell us a little bit about the relationship between the company and the project? Did having those projects help the company that you were at, or were they involved at all?

Yeah, so at Disqus, like I mentioned, the first month I was there we kind of kicked off Sentry. We kind of had the “happy accident” that it was pre-licensed, because we just built on additional code, and the founders of Disqus were totally on board with open source.

So I was able to get some help building out Sentry for our needs at Disqus, but I made a pretty clear point to never just build random features on top of Sentry during my time at Disqus. I would work on it in the evenings and things like that, but we would also build out features that we needed to make it better. I think the company saw a lot of value in it, not just Sentry but in open source in general. It helped us on recruiting fronts, it kind of gave some confidence to the technology team that what we were doing was useful, and I think in general it was a good situation for both sides, and today we still have a very good relationship with the founders of Disqus.

And there was no tension when you left… Because if it was a recruiting tool, you have to imagine that that recruiting tool kind of goes away if now there’s a Sentry company and they’re not the Sentry company, right?

[11:50] Yeah, I mean that’s how the world works. When employees go away, you can no longer use them as recruiting tools. There was no tension that I’m aware of when I left. I still keep in touch very closely with at least one of the founders, and on good terms with the other.

As far as npm and Joyent, I think I got the job at Joyent in part because I had written npm.

Not in part, I mean in whole. [laughter]

Yeah, basically Ryan Dahl was like, “Hey, come work on Node. I need somebody to help with this thing that Joyent is paying me to do”, and I happened to be jobless at the time when he said that, so it worked out. But no, I always maintain that npm was my thing and not Joyent’s thing.

Honestly, I think it’s sort of tricky – I don’t wanna speak for Joyent, obviously; it’s a whole different company than it was when I got hired, and it was a whole different company when I left than when I got hired. It’s a whole different company now. But I think for a lot of the time, the view of npm was that it was sort of this thing that’s attached to Node.

Maybe it’s just like egotistical, but my point of view has always been Node is the thing that enables npm, and I was mostly trying to keep Node going good and working on it, because I think it’s important for the broader JavaScript community, and I think that npm is a central part of that.

Obviously, I’m biased; this is my pet project, and it was my labor of love long before it was my company, but there was no bad blood as I was leaving. I honestly don’t think they really cared that much. It’s not like they ever hired people to work on it, or anything like that, and it was never seen as a Joyent product.

There was some discussion early on, like “Why don’t you sell npm to Joyent and then we’ll put a team on it?” I think we were several orders of magnitude away from one another in what kind of value we assigned to this thing, so it was not likely to work out. Again, I don’t say that in any kind of disparaging way towards Joyent; they kind of saw it as a thing that enables Node, so they weren’t gonna throw a huge team of 50 people behind it or anything, whereas I kind of saw this as a product that works really well, but it had to be run in a very particular way. Joyent being first and foremost operating systems and infrastructure type of company, I think it just kind of didn’t have the right sort of DNA to be that supported for this particular product.

Again, I really have nothing disparaging to say about them, it’s just there are different types of companies and different types of teams and different skill sets, and it just was not really ever gonna be a good fit, I don’t think. So that’s a big part of why I made the decision to move or to leave.

We also explored the option of putting npm in a foundation or creating a foundation for it, and really just focusing on the community/open source aspects of it. The reason why I didn’t go that route is that it works out to being about the same amount of work for fundraising to create a foundation as to get a startup off the ground. You still have to go and make a pitch to a bunch of people and get them to put money in the foundation. The difference is that there’s a different set of motivations and different sorts of companies that put it in for different reasons. A VC is putting money into something that they think is going to be a profitable enterprise that they’re either going to get a positive return on their investment. A large company generally invests in a foundation because the success of that foundation is in their interest. Let’s say they depend on Linux, and they wanna make sure that Linux keeps being healthy because they use it so much, so they’re gonna put some money in the pot to kind of keep this thing alive.

[15:55] Another reason why they tend to do that is because it’s a nice marketing boon. You see, “Oh, IBM supports WordPress. IBM must not be so bad, because I love WordPress.” And because of the sort of background and very developer-centric role that npm occupies, and the fact that I hadn’t spent four years marketing it, I spent four years making it something that people could use, developers loved it. But there was no real buzz around it, and there wasn’t a huge marketing benefit to having IBM put a bunch of money in npm, or any company for that matter.

So setting up a foundation for it would have been at least as much work and not as much benefit. And then getting a foundation to say, “Look the real challenge here is that we need a private service, and it needs to be a thing that people pay for, because if you don’t pay for a thing that’s guarding your privacy then how can you trust it?” So we needed to build a business around it anyway, and doing that under the auspices of a foundation is just a much more challenging thing to kind of figure out how to fit.

So yeah, in the end we’re still on good terms, we’re actually still a Joyent customer, for we use a couple of their services. Obviously, we use Node very heavily; we’re part of the Node Foundation. It’s all generally peaceful and good.

And the last question, was there any concern around – if you’re talking about foundations versus businesses, that being a business and a startup, especially taking venture might be perceived as being at odds with what the community wanted, or just changing your incentives.

Yeah, I think that there is always going to be some concern around incentives anytime you’re dealing with people, and the less well you know them, the more concerned you’re gonna be about their incentives. When somebody’s your friend, you can kind of have a little bit more of that sort of natural primate trust that comes from being in the same tribe.

But in general, there are some really interesting things about the JavaScript community in particular. The JavaScript community in particular is pretty pro-business and they’re pretty open-minded about things like that. It’s a sort of interesting melting pot, because almost every application touches JavaScript, touches a frontend at some point. So you have developers who think of themselves as Rubyists, Python developers or Java developers, but they still need to use JavaScript. So there’s a sort of liberal attitude about a lot of these things, and I think also just sort of the place in history that we are made it a little bit of an easier sell.

WordPress already sort of crossed a lot of these bridges for us. There is a bunch of other examples of relatively healthy open source projects that were in some way tied to a company or to a foundation, or just some sort of hodgepodge - a foundation made up of several companies. So having a profit motive - for a lot of people I think actually makes it easier for them to see what your incentives are. They can look at npm and say, “This is the product you’re selling. Okay, I get it. If I need that product, I’ll maybe come consider it, but I can see that you’re not trying to sell my email address. You’re not trying to sell advertising space on the command line, or weird tracking beacons or whatever.”

It’s all open source, it’s all very clear what we’re doing. We’re trying to be as transparent as possible, which I think is key when you’re interacting with an open source community.

David, what are your thoughts on that? I mean, Sentry obviously has a very different community. How did they respond to the venture announcement?

[19:45] The venture announcement - it’s all been like “Thanks”, “Yeah, good luck!”, “It was awesome!” We have a few people - we’ll call them the Hacker News crowd, who always question everything. [laughter] But yeah, in general it’s been good. The reason we kicked off the SaaS fundamentally was people wanted to pay for stuff, and I think that mentality easily caters to a VC-backed company. The biggest response we got from people was like, “Oh, I hope Sentry doesn’t change”, and this is just often from people who are more a little bit ignorant about how businesses work; of course things are gonna change, but it doesn’t necessarily mean change is bad.

We’re very different now than we were a few years ago. Mostly the product’s significantly better and we’re able to do a lot more, and we’re able to make it a lot more accessible. But you have a lot of the negative nancies that are like, “Oh, Sentry charges $10/month now. They’re gonna start charging New Relic process.”

So we had a little bit of that, but from our actual customers and our actual users, everybody was thrilled.

That’s great. I like where this is going a lot. We’re gonna take a short break and then when we come back we’re gonna talk a little bit about how these projects make money, and I think I’m just gonna ask outright how much they both make, as in salary. [laughs] No, I’m not gonna do that. We’ll be right back, everybody.

And we’re back from the break. Now let’s get into how y’all make money. How do Sentry and npm the companies make money? Really quickly, and then we’ll kind of go from there.

Yeah, so Sentry is a simple SaaS service. We actually have a tiered business model… Nearly all of our revenue comes from SaaS. More than our SaaS customers, we have free open source users and also those free open source users happen to be the largest companies. There’s some tradeoffs to be made there…

Longer term we’re looking at how we monetize the enterprise without creating what I call crippleware - that is like an open core product. We’re trying to prove that we can be successful without that, and I think we can. So we’ve started exploring some of that, but fundamentally the SaaS is what’s gotten us off the ground.

For npm, we have two main products. One is npm Enterprise, which is a standalone registry that you can spin up really easily inside of your company’s infrastructure, and it integrates with SAML or LDAP or whatever special snowflake authorization/authentication system you might have.

Then we have a private modules SaaS system that you can use for organizations and teams. We shipped private modules for individuals and then about six months later added the organizational and team features, and what’s really interesting is you can see from the registration graphs and the new customer signup graphs that the individual product was not the product, it’s not what people actually want. The folks are willing to pay or are paying for organization and team features. That’s about evenly split between our SaaS and enterprise products right now. In all of our early customer conversations when we were trying to figure out exactly what we should go build, what we found was about half of the people said, “No, no, no… We’re never gonna be able to put our code anywhere other than in our infrastructure, and multi-tenancy is absolutely a no-go for us.”

[24:06] The other half were like “There is no way that we’re gonna install a thing. We only want a SaaS, we only use SaaS.” It’s kind of interesting how that’s born out in practice almost as if that was a perfectly represented example; it was almost exactly 50/50.

As far as the open source users, we have about four million people using our service on a regular basis, four million humans. By several approximate measures that you can try and figure out, that’s about what it works out to. But much fewer than that are actually paying users, which is sort of fine. I think there’s actually something sort of morally good about – if you’re using something at a company and you’re using it for proprietary code and that proprietary code is gonna go make money, you should be paying for a service that supports the open source community; that’s doing things that are ultimately benefitting all of us.

I know that the companies that you’re inspired by… I know that npm gets compared a lot to GitHub, some of what you’re describing with Sentry reminds me of Travis a little bit. Are there other models that you’re going after?

I think GitHub is the one that we definitely get compared to the most. We’ve basically created our business model almost exactly from them. The funny thing is actually our org’s product, we’ve always charged per seat, because it just seemed like it was the easiest thing to reason about, even though that was a departure from how GitHub did it, where you paid per private repo that you have on GitHub.

The most frequent pushback or complaint we got about it is “Why can’t you just charge us like GitHub?” and then GitHub changed their pricing model to be per seat, and… Now we do charge you just like GitHub, it’s great.

The other company that I think is a pretty interesting or inspiring model is Wordpress, or Automattic, to be more specific. Just because they’ve taken something that was a vibrant open source community and really in some very creative ways have spun it into an extremely successful business.

For Sentry, early on we straight up copy-pasted somebody else’s pricing model, and I think they put about as much thought into it as we did, so we’re still working on fixing that.

But in terms of other companies, I actually think GitLab is very interesting. They are in a way similar to Sentry, where the entire product is open source. It’s licensed very differently, but they try to ship both. They have an enterprise offering and then they have the SaaS service. You can interact and contribute to both of their codebases, and it’s very compelling. But yeah, just like npm, we very much look at other tools and developer services in this space, GitHub being one of the big ones. We also look at a lot of infrastructure tooling, how does New Relic price, and actually we look at those more so like “This is not what we wanna do.” But there is a lot of variance in how things work, because often in the open source space you end up with a kind of support and services model, and I think I can probably speak for both of us in saying that that’s absolutely not what we wanna do. Those companies are Elastic, and potentially Docker, depending on which direction they go. And then a lot of the older database companies.

It’s funny to hear both of you say that you basically started by copying someone else’s model and then tweaked it as you went along. A lot of people that I’ve talked to who have open source projects, they’re interested in monetizing them. They’re sort of like, “I have no idea where to start. I have no idea what a business looks like and I don’t have any great models for this.” How did you both learn and figure out how to run a business? Was it just watching other companies and learning?

[28:09] I don’t actually know how to run a business… [laughter] That’s not exactly true. You just have to very aggressively learn as you go. I think that as far as pricing model, just to get to your first question about copying and pasting somebody else’s pricing model and then tweaking it a little bit, honestly I think that’s kind of a sensible way to go. I know this is sort of a controversial opinion, but I sort of think that the more time you spend worrying about your pricing model, chances are that’s time you should have spent going to market.

It definitely pays to stop and do some slow thinking about it, and it’s been really interesting to hear about some of the thought that went into GitHub’s original pricing model and now how they’ve changed it for their organization’s SaaS. Any pricing model is applying a tax to some particular behavior. If you look at it that way, charging per private repo is saying “There is a tax on your private namespace, and the bigger that namespace gets, the more things that are in it, the more you pay us. But you can have as many people as you want involved in those projects.” So that was obviously sort of a play to make sure that they’re growing their user base as aggressively as possible.

Once you have a big user base, once you have a big community, growing that community bigger is not gonna benefit you more. At this point, GitHub is probably close to nearing saturation of all the open source development that happens on Earth, right? GitLab is obviously a big one, there is also Stash - there are alternatives, but GitHub is the one that’s sort of the dominant player in that space. The benefit to them of having that be the tax was probably no longer the best thing for them to be doing.

On the other hand, if you say “We’re gonna charge per user in your paid organization”, now the tax is on having a bunch of people who are not participating in the open source world. Participation in open source remains free, but you want an organization to be on your product and you want them to be using it in the same way that it’s used in open source. You don’t want a company to come in and say, “Gosh, we don’t wanna have to upgrade our plan, so let’s just stuff more stuff in this one mega-repo that has all of our code in it”, because it’s just not how it’s done in open source.

Applying the tax that way ended up having some weird, perverse incentives.

That being said, GitHub threw something together, they thought about it for a little while and then they went to market with it, saw how it did and saw what the impacts were. I think you can really easily get yourself into analysis paralysis around that decision and avoid ever building something useful. Yes, there is a lot of science and a lot of art around pricing models and stuff, but whatever; it’s fine. Figure out a way to charge it, work out a model that shows you getting profitable eventually, and then see how it does. It’s one of those things where the less thinking you do about it, in some cases, the better.

Yeah, and I think from my side the best advice I have is make money on whatever you’re doing. This is not my first time I’ve attempted doing something on the side, and the lesson I learned each time was if I have to keep showing out money to keep things running, I’m not gonna keep it going, no matter how interesting the product is.

[31:56] From day zero, we’ve never put money into Sentry. We bootstrapped it, we got sponsorship from a couple companies, Heroku and Softlayer, both hosting companies, and from there we were always cash flow positive. Now, we weren’t paying ourselves any money at the time, but that didn’t matter because we were employed elsewhere. That’s really allowed us to take the time to figure out the business side, and that’s not saying we figured it out. By no means are we done. But it really allowed us to grow organically, and especially for open source… And anybody who’s asking those questions, it’s gonna be more like an individual or side project-esque kind of thing, and I think that’s a very good way to go about it. See where you can cut costs, see where you can get free sponsorship…

For example, Sentry gives away free service to open source projects, and I think that there’s a lot of companies that will help you out and really help you get off the ground. That varies, because clearly for a SaaS service it’s a little bit more straightforward, but I definitely think looking at what other people do and how they’ve approached problems is the most valuable thing you can do.

I’m incredibly jealous about the luxury of having something that was cash flow positive from day one. We pulled the business together around this ship that was more or less on fire at the time, and had not been cash flow positive. But it’s improving.

Don’t worry, the first thing when you take VC funding is to burn it all. [laughter] We’ve since fixed that…

Sometimes when you say the term “open source business”, people are thinking about old school enterprise companies. Then I look at Sentry or npm and I’m like, “Oh, these are the cool, new, shiny open source businesses.” I don’t know whether that’s just because y’all are just like newer businesses that they feel shinier, but I haven’t tried to pin down whether there’s something that’s actually changing in the way that people think about open source businesses, whether it’s more SaaS than enterprise stuff right now, or something. Are there any trends that you’re seeing around what an open source business is now, versus in the ’90s or something.

I think the biggest difference is that the internet exists now, and it’s a real thing. People do things on the internet; they have SaaS systems, they do stuff online… It’s less of an assumption that what you’re buying is the kind of unlocked version of the crappy open source thing. I think you call it crippleware… You see that a lot in databases and to some extent in operating systems traditionally. The real value in an open source world, and the value in an internet-connected world is in communities and in not having to have the teamwork in your company to build a lot of these things.

We use a ton of SaaS at npm. We use AWS, we use Joyent, we use Fastly… It would be completely impossible to build this business without leveraging all of those same things. I think when we imagine the stodgy old enterprises, even those are increasingly either selling services or selling very large support contracts. If you’re somebody like IBM or Ericsson and you’re selling something to a humongous, multinational oil company or the Department of Defense, or the water and power of Europe - these massive deals for huge infrastructure projects, like… Okay, yeah, that still happens. That’s gonna keep happening. But I think when we talk about open source business, we’re talking about a handful of different things that are somewhat dependent on what type of open source thing we’re talking about.

[36:10] Totally.

npm is a business built around a workflow which has been pioneered in an open source community, so we’re not really selling our open source thing; what we’re selling is some tools to make it easier to use this open source workflow, which is a little bit of like a subtle thing to wrap your head around. I think Sentry is a similar kind of thing, it’s an open source product; you can use it, you can have it. What you’re really selling is the service, and that’s a thing that is like “Yes, of course I will pay for that, because the alternative is I pay even more for it.”

Yeah, even the term “open source business” is not really actually a term; it’s like a business that might have a component to it that’s open source, but how that is monetized, or whether it’s even relevant to the business itself seems to vary a lot. A lot of companies now that are saying they’re an open source business or they open source a certain aspect of their products, and they do it for recruiting and they do it because they’re trying to build a platform and attract all these developers to it and whatever. Those things are I think very different from what npm or Sentry does.

Yeah, I agree with this whole ship that makes it more accessible - cloud services fundamentally - but I think the thing that really would make you think that npm or Sentry are these hot new open source ideas is because of the market that we’re going after. Both of us focus on the developer market. Not necessarily directly the enterprise market… We go through developers to get to the enterprise market, and that’s a significant change; that never used to exist. It never used to be that a developer at a big bank could run npm or Sentry internally and really drive the decision “We’re gonna pay for this.” It used to always be passed top-down. I think that’s the major change that we’re seeing, and that’s why there are companies like us and are going to be more companies like us going forward.

I think that’s a really great point. It kind of coincides with a lot of other things around more like bottom-up everything, instead of top-down.

Also, you mentioned you’re not sure if “open source business” is even a real term; that does not stop anybody from using it. [laughter] It absolutely is a thing that people say, and even use it in kind of ludicrous ways. Like, how can you open source-ify your business, which is a….

Oh, god…

It’s a real sentence I’ve heard a real human being utter. It’s challenging, right? I mean, not every business makes sense, and the role that open source plays in some businesses might not make sense. There’s a lot to be said for proprietary software; there’s a lot of proprietary software in the world, and we use a lot of it. But I think increasingly what’s happening is where almost anything that you would give to a customer is probably mostly open source, and anything that you’re gonna charge for is probably behind, running on your own infrastructure anyway. It’s just easier to build a business around that, I think.

Alright, we’re gonna take a short break and when we get back we’ll dig a little bit more into the open source side of things.

And we’re back with Isaac Schlueter from npm and David Cramer from Sentry. Let’s get into the open source side of things with both of your businesses. For the projects that you’re stewarding as a company, do you think of your projects as something that the community builds and you’re sort of another actor in that community? Or is it something that your company is building and then open sourcing to the community?

Sentry has never been kind of a community-built project, and we’re totally okay with that. Even today, which is probably not great for a CEO, if you look at the contribution graph, it’s like I wrote nearly everything, and I think this is valuable because it allowed myself to drive the direction of the project, which is atypical of a lot of open source projects where they kind of end up like this hydra going a bunch of different directions and you really have to wrangle them in.

That’s been very beneficial to us. That said, on the other side what we have done is we really pushed a lot of “Here’s how it’s extensible, here’s how you can integrate or send data” and things like that. And what we saw early on is a lot of people were interested in that side. It’s much more accessible than a complex infrastructure project is, it’s much more appropriate for their situation. So what that means is we started building the project around the Python community. Somebody from that community went and started working at a Rails company, and they’re like, “You know, it would be really nice if I could send my Ruby data to Sentry” and it’s like “Oh, we have an API for that”, so they built our first Ruby client.

Somebody else was like, “Hey, it’d be cool to be able to use GitHub to create issues from Sentry”, so they went and they built the GitHub integration. That’s really where a lot of our power has come over the years. For us especially, that’s been a very compelling story because while we might be very good at what we do, we definitely are not experts in every language and every platform, and we barely know what kind of tools exist in the ecosystem anymore. So opening it up to allow contributions where contributions make more sense has been really good

But then we also do now and then get bug fixes from companies. Back in the day, when this big gaming company started using Sentry, they started contributing these really compelling performance patches that were very specific to their needs but were very interesting. Fast-forward today and we still have that same idea. Square has recently started contributing a bunch of small fixes here and there whenever they run into any issues, and often what that is it’s because they’re running something in a slightly different situation - in this case they’re using a MySQL instead of a Postgres database, and they have a very specific issue that comes up… We’d probably fix it for them, but the fact that it is open source and the fact that it is accessible really just brings in the contributions. But they’re never anything that’s really driving any kind of product features, and that’s actually worked out extremely well for us. I think it helps because it caters more towards a classical business, rather than a big open source ecosystem.

I’m interested to hear Isaac’s take on it, since npm is literally an ecosystem.

[43:49] That’s always been a little bit interesting with the npm client, because it was… There are a couple of different things to talk about when we talk about our participation in open source. There’s the npm project itself, the CLI project. There’s the massive number of open source modules which are published and shared and installed on the npm registry, and then there’s the broader open source JavaScript community which sort of includes Node, React, Amber and all the rest.

The npm client is open source - it always has been - but for a very long time it was essentially a single-author open source project, which is a very simple governance style. The governance was, “I make all the changes, and if you have an idea, I’ll either take your pull request or not”, but it was essentially just run by me.

That’s since changed significantly. We have a team of people working on it - there are three individuals working on it today, and quite a bit of their actual day-to-day work is spent on communication with our open source users. We take issues on the open source GitHub issues list, they have a semi-regular call that they do as an open hangout where people can suggest things for their agenda to discuss for that week, and they do regular releases with release notes, and are very responsive to the community.

That transparency has caused an increase in the number of pull requests and the quality of bug reports that they get, but they’ve also been working on making the codebase itself a little bit more accessible, which is a big and somewhat overlooked challenge in any open source project. I think the social structures around most open source projects make it so that you never really address that, because all of the people who are working on it obviously are the ones who are capable working on it, who are not intimidated by the codebase and who think it’s totally fine… Whereas newcomers can look at this, the way that it’s structured and the way that the architecture isn’t really well explained and say, “Gosh, this seems kind of hard. I don’t know if I really wanna get involved.” So they don’t get involved, they don’t get a voice and so it never changes.

I’ve seen this in literally almost every single open source project I’ve ever been connected to - npm, Node, PHP Core project, the Linux Kernel… Although the Linux Kernel probably does a better job of this particular aspect than most projects. It’s still pretty daunting, though. You can approach it in a couple of different ways, by breaking things up into smaller modules, breaking things up into sub-projects that people can contribute and be a part of, but it’s still just an ongoing, difficult, unsolved problem to make a codebase accessible.

But in terms of our role in the community, that’s been a little bit more challenging. I feel a personal weight of responsibility to make sure that this community is a functional community and to make sure that our users are able to use the service and not be in too great a conflict with one another, and able to actually get what they expect out of it. As the community has grown, we’ve gone through several different stages where different sorts of governance approaches have made more or less sense.

In the very early days actually, Michael wrote the first version of the registry, which had no authorization or authentication whatsoever. It was like, “You wanna publish a thing? Alright. You probably know what you’re doing if you know what this thing is.” That didn’t last very long. That had people taking advantage of it almost from day one, so we scrambled to add some authorization in there, but it was the simplest possible thing and now we’re kind of grown up to this stage where we have private code, where we have teams, and you can specify which team has access to which modules, to read access, write access and so on.

[48:08] Also, as a community, you go from the state where literally everybody has met everybody else. Where everybody was one or two degrees of separation from each other, to the point now where there’s more npm users than in some major American cities. This requires a different sort of policy, it requires different practices in terms of having things more well-documented and a little bit more regimented in how we approach certain types of conflict.

While on the one hand it’s a little bit troubling to have a for-profit company - or any entity, really - in this position of authority and control, at the same time anarchy doesn’t really serve anybody. Anarchy just means that the loudest voices have the most control, and that’s really not any better. I feel like there does need to be some sort of governance structure, and a body with a dedicated interest in keeping this community healthy is in charge of keeping this community healthy. Otherwise it doesn’t happen, and you end up with a tragedy of the commons really quickly.

At the same time, we try very hard not to abuse our position and to be as transparent as possible. Some of the things we do there - we have a support team, which if you email support@npmjs.com you will talk to them. They’re not there to do your Node homework, they are there to resolve issues that you might have with the service if there’s no other outlet that sort of makes sense. It’s sort of the frontlines of our support for the community.

We also have a lot of time and effort and money and energy spent on keeping the service running, which is sort of the core thing that keeps the community healthy. We try very hard not to abuse our position as much as possible. We are trying to run a business, but the actual purpose of this business is to keep the community alive and running and healthy. My main goal with starting a company is to keep the npm registry running forever. I think that’s in the interest of most of our users, so I can sleep okay at night because of that.

If two people want the same thing or are fighting over something, the one that you don’t agree with is gonna be very upset at you about it, and there’s sometimes just no way around that.

Do you think it’s possible for a company to actually be in a community or part of a community, or is it always sort of this outside patron that is kind of facilitating the rest of the community? Because this is in some ways like talking about protecting the npm community… For either of you, do your employees represent Sentry, do they represent npm when they’re communicating within the projects, or is it like they represent themselves?

I think that all too often we talk about a company as if it’s a single entity, and despite what politicians and Super PAC say, companies aren’t people; corporations aren’t people, they’re legal entities with interest, but they’re just sort of a bunch of people working together for some kind of common interest. That’s essentially what the company is - they’re a social fiction designed to make money. That’s not a bad thing inherently, but it can get things a little bit twisted when you start saying “Well, the company says this” or “The company says that.” It’s like, “No, you say that. You’re just hiding behind this weird logo.”

[51:44] The brand of npm I think is very strong. Like I said, I have a large personal interest in continuing that and making sure that we’re a force of good. I think mostly that can very easily become a virtuous cycle or a vicious cycle, depending on how you spin it. Most of the people who work for me have, as far as I can tell, also considered themselves part of this community individually, and would continue to be part of it if they stopped working here. It’s just that this is the job that they’re doing and they are doing it because they believe in it and also because we pay them.

It’s kind of weird… I think frequently where you tend to get into trouble is when you try to have a company pretend that they’re part of the community when it’s pretty clear that they’re not. If they’re saying, “Look, we’re using Node, we’re a part of this community, so therefore you should like us, because you like Node.” It’s like, “Maybe I don’t. Maybe I don’t agree with what you’re doing.”

I think it’s actually kind of rare that there are companies like npm or Automattic or Sentry where not only are they just kind of involved with this community in this sort of abstract sense, their products and services literally depend upon it and their success depends upon the success of the community, and the people working at the company consider themselves part of the community.

David, how about Sentry? Are they Sentry employees or are they themselves?

It’s very different for Sentry, just because we’re not a community. npm has tons and tons of users and they interact heavily with their own code, their own projects through npm, whereas Sentry it’s like you’re using our product, the product that we built. I very much believe that everyone at Sentry is acting on behalf of Sentry, but as themselves. Their interests are Sentry’s interests, that is the company and the project; we think of them as kind of one and the same. But it’s not a community as a whole. It’s very much like, “Hey, we’re all of the same mindset, we all wanna build this thing. This is our singular voice and how this thing is gonna be built.”

Does this affect how you think about recruiting? Are you looking for people that are…? I mean obviously, probably people that have already been involved with Sentry, or care about it, or think about, but do you that sort of like strengthens that unified voice if you’re hiring someone who is already involved with the project and already feels like they’re a part of it?

It absolutely does. I think we’re a slightly non-traditional company, at least in the VC-funded startup world, in that the entire team is engineers right now. Most of the team has contributed to Sentry or runs Sentry, or at least used Sentry before joining the company. So it helps that a lot of people… It’s not even a vested interest, it’s just they had a genuine interest in Sentry before coming onto the team, and that helps a lot with how do we build the product, how do we think about the product, how are each of the members of the team individually involved in the product.

It’s been very valuable for us to have that. I would say that everybody has a different idea for the small branches of how Sentry should work, but everybody has the mindset that this is super valuable what we’re doing, we agree with the direction we’re going, how can we contribute to make that a reality? I think there’s different tradeoffs and different challenges for a community-driven project versus – I kind of consider us more like a BDFL situation. There’s absolutely value in the community and I think it’s something we’re going to explore as time goes on, but we’ll see.

So far, what we’ve done has worked well for just building a singular project.

How do your investors think about the whole – having to work with communities or just outside users that might have a say in your projects, that aren’t actually a part of the company.

[56:00] Speaking for Sentry, I’m not sure the investors really consider it much. I think a lot of the trust… Like, when we talk to them, the mentality is like, “You’ve done very well to get where you are. Whatever you’re doing must be right. How do we push it to the next level?” So I think there’s a lot of explicit trust even there. This might be very different for npm because again, we are a very focused, single project; I wrote most of the server itself and pretty much everything is now built by us, the company. But it definitely just comes down to, “You guys are clearly the experts at doing what you’re doing. There must be something that’s correct there. We’re not gonna tell you what you to do, since realistically you should know better. We’re betting on you, at the end of the day.”

I think as far as the community interactions and advice from our investors, they… I don’t know, I don’t wanna say they don’t care; I mean, certainly they’re very excited that we have so many users. Both of our investors, if you look at their portfolio companies, what they tend to go for are companies that have some kind of a network effect, where the more people use this thing, the more other people will end up using this thing. True [Ventures] is in Automattic, they’re invested in a bunch of other SaaS companies, BVP, they just saw some really big success from Twilio, which just recently went public, and they’re sort of very focused on developer-lead enterprise products with some kind of a community or network effect, and open source just sort of plays to that strength really well.

That being said, as far as managing the community, they’re not really experts in that. I think they are betting on us being experts in that. Obviously, we’ve built this huge community, we have this huge type of funnel; they’re mostly just concerned with how well we can turn those eyeballs into dollars, so to speak, to fall back on awful dotcom parlance.

It’s funny hearing both of your… I think it’s important hearing both of your experiences, because they are very different types of projects and they way that you’ll run them and monetize them and manage the community is naturally very different. I think it just speaks again to the fact that not every open source project is the same; it’s almost like weird that we use this term that tries to encompass all these different cultures, where actually each one is quite different.

Do you think that building businesses like these is different from building other types of startups at all? Is there anything about having the open source side of things that makes it different from any other startup wisdom that you might hear?

I think for npm it kind of makes it a lot easier. One of the biggest hurdles is getting people to use your thing, and I guess it’s a little bit suspicious to say that it’s easier… I mean, we’ve traded one set of problems for another, but there are certainly some very big problems which are fatal problems for many companies, and we just sort of haven’t even had to worry about, which is sort of a luxury.

For Sentry it’s fairly similar… There’s things that we could not have achieved without the open source aspects, at least not at our scale. For us, cross-platform is a true fundamental strength and requirement of our product, and there’s no way we could have done most of this without the community. But I think at the end of the day, outside of that, Sentry looks just like a normal company. Again, that’s very different from npm, but it’s interesting for us because – we don’t necessarily publicize it super well on the website, but we often get questions like “Is Sentry open source? Do I have to pay you? What does this mean?” Because we have for example an enterprise version, which is fundamentally just a support contract.

So there’s still a lot of challenges around conveying what open source means to your users and how that affects your business and things like that. But I think it’s just another channel that you treat differently at the end of the day and each business does that differently. Open source is just one factor that influences that. There could be many other factors, depending on the industry or the type of product.

That’s a great idea to end on. Thanks for talking with us, David and Isaac. We really enjoyed this.

Yeah, thanks for having us.

Thank you!