Increment: How did npm start?

Isaac Z. Schlueter: I was one of the first people messing around with Node.js. I’d been mucking around in the server-side JavaScript land for a while. I really like JavaScript, I really like PHP. But what I liked more than either of those was being able to use the language in both places.

In the midst of this very small community of a bunch of people trying to figure out how to make server-side JS happen, Ryan Dahl came out with Node, which was just very clearly the right approach. I threw my chips in with that and got very involved in about the middle of 2009.

I was very accustomed [at Yahoo] to using a package manager as part of my development process. I just sort of packed together this thing that was basically what I was doing by hand, to use other people’s code, but coded in a Node program. That was September of 2009. This is the eight-year anniversary of its initial birth on GitHub. The first version that was actually really useful and usable happened in the beginning of 2010.

Around the end of 2013, it was running on borrowed infrastructure, and we had some pretty serious downtime because of some scaling problems. The community was just growing at a ridiculous pace. I think we were pushing a million active users.

I looked at the shape of things and said, “Look, we need to have some kind of way to have revenue for this thing so that it will be able to be sustainable long term.” There’s a [few] ways that you can put revenue behind an open-source project or community. You can start a foundation, you can find a home within an existing company or you can start a company, or you can just be independently wealthy.

OpenSSL got a lot of attention a few years ago because they were run by a foundation, they were underfunded, they were a critical part of internet infrastructure. And then, Heartbleed happened. Was that part of your thinking?

This was a few years before Heartbleed [in 2014]. I was more just looking at the shape of the problem. A foundation gets donations in either time, or money, or resources of various sorts from a bunch of different big companies. You raise, let’s say, five million dollars. The next year, hopefully you have delivered enough value for it to be worth each of these companies putting in one million or whatever dollars.

And they all decide to pony up again. This works great if your costs are relatively stable. One of the canonical examples is the Linux Foundation. Tons of companies depend on Linux, and the costs involved in building the Linux kernel are relatively straightforward. But it’s not something that grows exponentially. In npm’s case, we were funding a registry of apps for free. And that community is growing very quickly, and the community’s dependence on that service, and usage of it, is also growing very quickly.

Wherever you have costs that are growing exponentially, there is really no way to make that work with a foundation. I figured, I’m going to have to tie some source of revenue to the growth of this community and the growth of its usage of npm.

I talked to a handful of venture capitalists—ultimately we connected with True Ventures. We built our enterprise products and the first version of our SaaS paid product as well, and the private package support for solo users. We did another round led by Bessemer Venture Partners. We continued to improve the enterprise products and we added the support for orgs, and teams, and our SaaS products. We’re not yet profitable, but we’ve been—there’s a term—default alive. If things keep going as they’ve been going, we will be fine.

npm@5 would not have happened if not for hiring the people who built that new version of the product.

How does npm fit into a notion of keeping people from wasting effort?

I can’t with a clean conscience say that npm really prevents ever reinventing the wheel because there are so, so many wheels on npm. My hope is that it makes wheel reinvention easy and efficient, and keeps you from doing it unnecessarily.

That being said, there are a lot of things that have a high degree of overlap in the npm registry. Every time we mention like, “Oh, there are 550,000 packages on npm,” people are, like, “Yeah, but how many of them are for parsing email addresses?” “Okay, well, only a dozen of them are for parsing email addresses.” Maybe that’s more than we need, but they’re slightly different.

When we started the company [in 2014], we said, “Well, look. We’ve saturated the Node world.” But that’s maybe, what, ten percent, five percent of the total JavaScript ecosystem? Estimates vary from the low end, like 15 to 20 million, to the high end, closer to 50 million people. We thought, “How can we possibly get it to frontend JavaScript?”

This new thing Facebook has done is using npm as the place to put all your React components. And Angular is also using npm for a bunch of stuff. And there’s this new thing called Vue.js, which is also using it. And Choo is based on npm, and Polymer was using Bower, but they just recently switched to looking at using npm for all their components moving forward.

We showed up, we provided a pretty good solution, and [we] infected a generation of JavaScript developers with this mentality that this is how you do JavaScript and this is how you do modules.

We’re pushing nine million active users now. And the overwhelming majority of them are using npm primarily for frontend code, not for Node.js.

Because it was designed around JavaScript as the central piece, folks just started depending on it?

We strategically built a tool that was easy to use and flexible. There’s trade-offs involved: The more flexible your tool is, the less opinionated it is, and that cuts you off from certain types of product options that you could take. However, the benefit is that people do use your tool in novel ways—as much as that’s sometimes a very frustrating or confusing thing because they start doing really unusual stuff that you hadn’t planned on. The flip side of that is new users are able to use your tool in novel ways that you hadn’t thought of.

How does running npm as an open-source developer tools company differ from firms that focus on their own proprietary tools?

My goal, my reason for creating this company, was so that the npm registry would survive—so that npm as a utility, and as a piece of the roads and bridges of the infrastructure of the internet, and as software, and open source, would be able to continue and be supported.

Some companies have made quite a lot of money by having interests that diverged with a majority of their users or the community that they’re in. I don’t know if it’s right to say that it’s bad or evil, [but] it’s certainly antisocial to be at odds with your user base.

For a software company, and especially in open source, that type of approach of saying, “We’re going to harvest our community”—it really does not work. Long term, it’s incredibly shortsighted. Just to pull the most ill-advised example that I possibly could, we could say, “From now on, everybody has to register in order to use npm.” They have to create an account in order to download packages, and also, they have to pay a dollar a month in order to keep using npm.

Let’s say we lost half our users and we had $4 million in monthly recurring revenue right away. Great, hooray. We are not just profitable, we’re doing incredibly well. The reason why that’s incredibly shortsighted, even though we would probably make a lot of money right away, is that every single one of those people are now busy making other plans.

They would disappear and go invent something else themselves. I have no doubt about that. We haven’t solved cold fusion or done something truly innovative. What we’ve done is we’ve developed a community platform that’s extremely useful to a given community, provided that we keep it that way.

You knew I was going to ask you about the left-pad situation. [A module to pad out spaces on the left side of strings was removed at the request of its poster after a naming dispute, but it also happened to be part of some popular npm packages. —Ed.] Some people talked about it as, “It’s brought down the internet,” briefly. You noted at the time that a quick community response saved the day. What lessons did you learn from left-pad?

Left-pad was a really fascinating turning point: a shift from prioritizing the means and interests and, frankly, the whims of publishers over the impact to downstream users.

Now, when you first create a community, you need something to get people there, and the thing about early adopters is if you don’t have them, you don’t have any adoption. However, over time, as a community’s size increases and as the interdependency gets deeper and deeper, the means and the priorities have to change.

With left-pad in particular, we took two main things away from that. One is that our policy for handling disputes became much more codified, rather than relying on social capital, shared understandings, and a few people knowing what the priorities were.

The bigger technical impact is that you can no longer unpublish a package after 24 hours. So, if you publish something and it stays up there for 24 hours, you cannot unpublish it.

We will occasionally allow [unpublishing after 24 hours] if you accidentally publish your SSH private keys. Occasionally people will publish proprietary code by accident. What’s more frequent is someone publishes a test module that they did while they were in a coding bootcamp, and now they’re trying to find a job, and they don’t want it on their profile. What we’ll do is take the module and assign it to npm and deprecate it.

Sometimes languages are missing things—and JavaScript certainly is, even with all its improvements. Left-pad felt like a lot of people were using it, like oxygen, not realizing it was a module in that sense.

Almost immediately, people in the community said, “Oh, this thing is gone. Well, I’ll just put it back.” We were able to continually adjust and update our policies and our practices, and try to grow with the community. That’s definitely one case where we were not ahead of the curve, and I think all of the left-pads you haven’t heard about are the cases where we were ahead of that curve.

There are a ton of things that we do to try to keep this nice, smooth operation so that nobody has to notice that they’re using a ton of open-source code. My goal is for it to be like oxygen. And most of the time, that is exactly what it’s like.

You have some very strongly held opinions about the importance of diversity and inclusion, and about the way in which discussions and contributions are managed. What do those values bring to npm?

The core human problem is, like, how do we get a bunch of people to work together and make the right decisions together as a group, given the fact that we’re all a little different. We all have different priorities.

As a private company, we hire whoever we want. We decide what roles we want to have. We can decide what our values are. We decide what our culture is. But any company will have some actual values. They’re going to make choices, and those choices have trade-offs.

As a company, or as an open-source project, or just as a family, or a town, or any arbitrary group of people—either these values are explicit or they’re implicit. And these values tend to shape what your culture is, how you interact, and what your practices are.

We do put our company culture on display to some extent. Every once in awhile, we open a job req, and there’s somebody on the internet who says, “Well, it says that you value inclusion and collaboration, and that sounds like a place where I’m not going to be excited. I need a lot of noisy competition, and I want to be in a fistfight every day. So I’m not going to apply to this job.” When I see that, I just feel so good. I’m like, “Oh, thank goodness, because you would have such a bad time here.”

I think the facts are also on our side there. If 100 percent of your leadership team are white dudes, there’s a good chance that they didn’t get there on merit. There’s just a very good chance that they’re in [those positions] because of implicit biases and societal privileges. And I’m not confident that societal privileges are a good indicator of people who are going to make the best decisions for the company.

For npm, our number-one need to deliver is sustainability and a very careful approach to solving a very specific problem. And keeping the registry, and keeping JavaScript going really, really well.

In some cases, in some companies, it might make sense to work 18 hours a day, burn yourself out because you’ve got to ship this app. And look, it’s either going to work or it’s not. We need to make sure when they’re in some kind of an outage, people who are well rested and are ready to tackle that are able to bring their best mind to bear.

You have an opportunity to leverage a tremendous community of people, many of whom are not in the dominant socioeconomic or demographic group in their culture. A lot of [potential contributors] out there are women. A lot of people out there are queer people, or trans people, or people of color. If you’re keeping them out of your project, you’re just not able to leverage the benefits that they could bring to bear.

The wombat is your mascot—where’d the wombat come from?

If you flip the npm logo upside down, it looks like WDU. And at one point, CJ Silverio, now our CTO, tweeted [that we were called] Wombat Developer’s Union. Another early employee tweeted out, “Somebody give me an illustration of a wombat in a ninja costume, stat.”

A JavaScript developer and fan of npm, John Quach, replied with some sketches of a wombat. We purchased the rights to the wombat character from him.

You didn’t intend for it to be a wombat.

Yeah, basically. It was an emergent wombat.

npm adopted a wombat named Teacup at the Sleepy Burrows Wombat Sanctuary in Gundaroo, Australia. How is Teacup doing?

Teacup is doing quite well. We get pretty regular emails from the folks who are taking care of Teacup.