Get in touch

Postlight joins Launch by NTT DATA! Learn more.

This week Paul Ford and Rich Ziade talk to Laurie Voss, chief operating officer of npm, the JavaScript package manager that gives 7 million programmers worldwide access to hundreds of thousands of packages. They discuss how npm works and the details of its past, present, and future — as well as how removing one tiny piece from it can break the entire internet. They also discuss managing a large community of users, where the 0.1%’s complaints always seem to outweigh the 99.9%’s praise.

Transcript

Paul Ford: Hi, I’m Paul Ford. I’m the co-founder of Postlight, a digital product studio at 101 Fifth Avenue in New York City. And I am joined by the other co-founder!

Rich Ziade: Rich Ziade.

Paul: Rich, it’s good to see you here today in the office where we come every weekday.

Rich: It’s amazing to see you always, Paul Ford.

Paul: And I would say that today, well you know what, before we get to our guest, who I’m really excited to talk to, it’s someone who I truly enjoy on Twitter and in their professional capacity, but before we get to them, we should tell people what Postlight does. What does Postlight do?

Rich: You know —

Paul: What? What?

Rich: We ship stuff.

Paul: OK. That’s great. That’s a good marketing message. I like —

Rich: Sometimes you gotta design it first, and then you gotta think about the problems.

Paul: Sometimes you gotta use a platform, often using a technology — often, really you’re on the backend writing a lot of JavaScript code.

Rich: Mmmm…sometimes.

Paul: Writing a big server in JavaScript and then you get to the front end and you’re writing more JavaScript code.

Rich: We’ll get into the sausage-design process, the sausage-building process, and we will ship that sausage.

Paul: That’s right. So in terms of sausage shipping, we have a great guest today who is named Laurie Voss.

Laurie Voss: Hello.

Paul: It is very nice to have you here. Thank you.

Laurie: Well thanks for inviting me.

Paul: Let’s tell the people who you are. You are the chief operating officer of npm.

Laurie: That is correct.

Paul: What does npm stand for, Laurie?

Laurie: npm doesn’t stand for anything, as a 15-year-old that I once got into an argument on GitHub will tell you. It used to stand for Node Package Manager, we’re pretty OK with admitting, but it’s now the package manager for all of JavaScript, and we didn’t want to rename it JPM. So it just means, it’s just npm now.

Paul: So let’s tell the people what this thing is, because I think a lot of people, it’ll be very new for them. So when you are writing JavaScript code, that is code that makes a computer do something, you don’t want to rewrite everything that’s ever been before in order to make your JavaScript do something. So a good example would be, I don’t want to…come up with a new way to, what’s a JavaScript thing that you might do? I can’t even think.

Laurie: You wanna put a web app together and you don’t want to have to do the router.

Paul: OK, what’s a router?

Laurie: You don’t want to have to write the code that understands what URL should go where, you just want to write the code that does what happens when you get there.

Paul: Great. So I write something, I want the slashes and the words that I put into my URL to like, I want to be able to just kind of identify them in a simple way, and then tell the computer to do something else, like go pull something out of a database and —

Laurie: Exactly.

Paul: So writing that code, it’s true. You have to, like, ah, here’s this URL, I’ve got to break it up, I’ve got to do all this stuff.

Rich: I could write it myself.

Paul: Could, could. But that’s a bad idea. That’ll cost you hours and hours and hours and hours of your life, and it’ll be buggy and bad. So you wanna maybe use a nice open-source package.

Laurie: Exactly.

Paul: And that is what is built into kind of the JavaScript ecosystem: people take it for granted, but it’s, uh, you just go there and you type npm install, and then the name of, like, some package, like “router.” Just boom, boom, boom. npm install router. And then 50 million things happen on your screen, after you do that. But when it’s done, there’s a library installed, and you can just go ahead and start programming against that library, and you now live in a world in which all of your code can use this router. And all the things that router was built on top of.

Laurie: Mmmm hmmm.

Paul: And that, to me, is what npm does. That’s what I think of npm as.

Laurie: That is what a lot of people think of npm as, and it’s certainly what npm thought of itself as for the first few years of its life.

Paul: Now when was npm born? When did it come into the light?

Laurie: Isaac invented npm in 2009, which was roughly at the same time that Node itself was being written.

Paul: Is Isaac a person with only one name, or is there another name?

Laurie: IsaacSchlueter, who is our CEO and he’s sort of known on the internet as “isaacs,” to the point that people address him as “isaacs” in real life all the time [laughter] and they’re like, “We have to explain that the ‘s’ is actually, you know, his surname.”

Paul: Now were you there with him at the beginning?

Laurie: I knew him at the time. We’ve known each other for a very long time. But I was not involved in the, in the early parts of npm. I was basically sort of looking at his shoulder going, “Can I build websites in it yet?”

Paul: Oh, OK.

Laurie: And he was like, “No, it’s not ready.” And I was like, “Let me know when that happens.” And that was in 2013, he was like, “All right. It’s ready. Go.”

Paul: So you were a programmer out in the Bay Area up until that point?

Laurie: Yeah, we both worked at Yahoo at the same time, and we knew each other from Yahoo. We had extensive lunches at Yahoo, where we, you know, we enjoyed each other’s company a lot. So we kept in touch even after we both left Yahoo, so when he was, like, “I need to turn this thing into a company, otherwise it’s gonna collapse under its own weight. Who do I know who’s run a startup before?” I was his first choice.

Paul: OK, so what goes on here, you start this nice service for all the other programmers, because there’s a need. It’s like, hey, we need a way to download — and the thing that we should, we should back it up even a little bit further, which is that one day, some people took the engine of JavaScript that’s inside the Chrome web browser, pulled it out, and said, “You know what? This can run anywhere. It can run on a server.” And that was called Node.

Laurie: Indeed.

Paul: And so suddenly you could write Ja — you could run JavaScript anywhere and it made for a good language for serving web applications, as well as running them in your browser. But if you needed this code, if you needed, like, some backup libraries, there weren’t any that you could easily go and find and download. This was always a problem with the JavaScript world. Then Isaac S —

Laurie: Mmmm hmmm.

Paul: Goes and solves this and because this thing was gathering so much momentum, his life is actually ruined because he solved this problem for people. [laughter] And so he calls his friend Laurie. Is that, like, a good way to put this story?

Laurie: There’s a lot of history to how, how Node came about that I can go into tedious detail on, but that’s the basic ideal. Ryan Dahl was more interested in the fact that Node, um, allowed him to write asynchronous code than he was in the fact that it was JavaScript. JavaScript was just sort of accidental.

Paul: I’m gonna, I’m gonna just jump in here, because asynchronous code just sort of means lots of things are happening at one time. If I try to make it any more specific than that, I will cause an enormous conflict and rift in the universe of engineering.

Rich: The podcast will be pulled.

Paul: Yeah.

Laurie: That is, that is fine.

Rich: The censors will pull it.

Laurie: But what I think sort of, um, powered the growth of Node was not the fact that you could write this pattern of asynchronous evented code, as it’s known, but just the fact that it was JavaScript, and so many people had to know JavaScript anyway, because it’s, you know, the only language that runs in the browser. Everybody needs to write web software these days. Everybody ends up learning JavaScript.

Paul: And it’s installed on billions and billions of devices.

Laurie: Right.

Paul: And computers.

Laurie: If you’re a programmer that’s just starting in your career, you have to learn JavaScript, and then you’re like, well I could learn some second language, like Ruby or Python or, you know, any other language, or I could just keep using JavaScript and write it on the server as well, and why would you bother? Why would you bother to learn a second language if you don’t need to?

Paul: Well that’s a question that maybe we’ll push aside to a different time. [laughter] But let’s assume that JavaScript is the perfect language for everyone at all times [laughter], which is a strong, strong assumption, although some people might argue, if you’re at Postlight, and so you come on and Isaac S. is tired, things are rough, he’s got engineers telling him that he’s not doing a good enough job and complaining to him and asking him for things. What do you start doing?

Laurie: Um…well the first thing I told him was can you get me some money, so I can hire some engineers, because there’s no way that I can do this by myself. So…

Paul: So you’d built a startup before. What had you built?

Laurie: I built a company called awe.sm. [laughter] The best part of which was the name —

Paul: I’m sorry to laugh. I mean, it sounds…great. [laughter]

Laurie: If you’ve, if you’ve heard of, if you’ve heard of bit.ly, we were like bit.ly except we had a ton of sort of analytics involved, and that was kind of the downfall of our company, was like, we would tell you whether your social media campaign was making you any money, and the answer was always no.

Paul: Mmmm, OK, so you just delivered bad news.

Laurie: Right.

Paul: So kind of non-awesome.

Rich: Not a great model. [laughter]

Laurie: People would sign up, get this report that said, “Your job is useless and you should be fired,” and then they would cancel the product. It was not — it did not do well.

Paul: That is a bad product, overall. [laughter] Like, the market fit there is pretty rough.

Laurie: Yeah no, it was really not successful.

Paul: So you had been involved inawe.sm.

Laurie: Yeah.

Paul: Or had you started awe.sm? What was the…

Laurie: I was the co-founder atawe.sm.

Paul: Co-founder at awe.sm OK, so you’d — you’d been through the mill, you had money walk in the door, you’d dealt with engineers, and you’d scaled something up to the universe.

Rich: Ran a baby business.

Laurie: Right.

Rich: And saw the stuff that comes with that.

Laurie: Exactly.

Paul: OK, so you show up and it seems like around the, I mean, it was already blowing up.

Laurie: Mmmm hmmm.

Paul: And now what used to be called the Node Package Manager but now is called npm is just, like, a substrate of modern computing. It is everywhere. It’s big. How many — like, how many people are downloading packages as we speak. What’s gonna happen today?

Laurie: About 300 million packages today. There’s about 7 million npm users worldwide, which somebody pointed out recently means one in every 1,000 people alive is an npm user, like, even including the people who don’t have internet access, which is a wonderful stat.

Paul: Wow. OK, so you’ve got literally billions of JavaScript files flying around, coming out of npm onto peoples’ hard drives, so they can do things with them.

Laurie: Exactly.

Paul: OK so what makes npm different? Like I can give you, I can write you some JavaScript, put it on a website, and you can download it and put it in a folder and use it. What does npm actually give me?

Laurie: So this is a, this was a realization that we sort of came to quite recently, in the life of npm. Like, npm is a package manager, but npm the tool is more than a package manager. It’s much more of, sort of, an application workflow than it is just a way to download and install packages. Like —

Paul: Wait, let’s compare those two things. So a package manager keeps track of packages, and how they connect. And so if I ask for, like, package X, but it requires packages A through M, plus a couple, you know —

Laurie: Right.

Paul: P and Q, it’ll go get all those for me.

Laurie: Exactly.

Paul: And then put ’em all in one place, and I don’t have to ask for 20 files, I just have to ask for one.

Laurie: Correct.

Paul: And that’s the dependency graph, is that the right term?

Laurie: Yeah, that’s…

Paul: OK, so there’s a dependency graph that connects all those things together. And that’s what the package manager does.

Laurie: Right.

Paul: OK, so what’s this other thing?

Laurie: So the thing that npm does that sort of started as a byproduct and has become almost the primary feature is that it is a way of putting your application together. So you have a package JSON file, which is just, like, a text file written in JavaScript language at the root of your project, and it says, to start with, what packages do I need to make this piece of software run, but it also says stuff like, this is how you start the software, this is how you stop the software, this is how you test the software, and it builds all of those into the package format, so if you’re working on a team, if there’s, like, ten of you, this thing that used to be sort of ambient knowledge, like, how do I run the tests, has stopped being ambient knowledge and is baked into the code, so you just run npm test and it tests the software for you. So if somebody changes how the tests work, which happens all the time, instead of, you know, one by one everybody getting slightly annoyed and sort of looking over their shoulder and going, “OK, how do I run the tests now, Bob?” Bob can just change what that, what npm test does, and suddenly it works for everyone.

Paul: Whoa. That’s, so Bob has almost unlimited power, whereas before he had no power. [laughter]

Laurie: Yeah, one of the, one of the things about npm is that it’s not really magic, it’s just, all we do is reduce friction. Like, the reason people build software in, in Node and in JavaScript these days that involves a thousand small modules, is not because npm forces them to, it’s because npm allows them to. Like, if you had to individually download all of these modules and put them in the right place yourself, you could do that, it’s just that npm does it in 30 seconds instead of the hour it would take you.

Paul: Sure.

Laurie: And so because you can, people do, is basically what we discovered.

Paul: So it’s just, it’s software being software. It’s doing the job for you.

Laurie: Exactly. And one of our sort of key tenets as a piece of software as we try not to be opinionated. We try not to say, “Do it this way and no other way.” We try not to say, “This is the right way, and we’re gonna make it hard to do the other ways.” We just find out what people are doing and say, “OK. We’ll make that faster.”

Paul: How many people are at npm now?

Laurie: Uh, we are….exactly 20 people, but we have job offers out to two, so ask me again next week.

Paul: OK, so this is a growing concern, with as many as 22 employees. [laughter] What do the different people do? Because as far as I know, people are uploading JavaScript that they wrote for free, and you’re letting other people download it. So…22 people, what do you need them for?

Laurie: So 13 of them are engineers. And what they do, the majority of them are doing is keeping the registry up. The registry grows by 10% every month. Um…

Paul: This is a good point. This thing is actually quite a beast.

Laurie: Right.

Rich: Good lord.

Paul: This —

Rich: 10% a month?

Laurie: Right.

Paul: This is a, I mean, many of our listeners aren’t gonna process the size and substance of the platform that you are hosting starts to get into the orders of magnitude of, like, a giant internet company, like a Google or a big ad server or something. You’re hosting a lot of stuff.

Laurie: We’re, we’re a little short of a Google, but we are pretty big, and 10% month-on-month growth, like, compound interest is a thing that, that monkey brains are very bad at visualizing?

Paul: Mmmm hmmm.

Laurie: So 10% growth is, you know, you double every six months.

Paul: Right. So where, where is this hosted?

Laurie: Uh…the bulk of the heavy lifting is done by a CDN called Fastly. We could not exist without them.

Paul: We’re big Fastly fans!

Rich: We love Fastly.

Paul: They had me come give a talk, which I liked. They paid me some money for it, but also we’ve used them for lots of stuff. That’s a very good product.

Rich: Note: Fastly is not a sponsor of this podcast.

Paul: Yet or so far. [laughter]

Laurie: Yeah, they’re awesome. In the early days, we would break them a lot [laughter] because we did complicated things, but they’re just rock-solid now. We like them a lot. And the, the actual origin servers that the, that the CDN is using, are all on Amazon.

Paul: OK.

Laurie: We avoid east-1, because east-1 is danger and death.

Paul: That’s a zone, so people know, like —

Laurie: Yeah.

Paul: east-1 is a big Amazon center, but it has lots of zones.

Laurie: Right. So we keep out of the big dangers at Amazon data centers, but we’re all on Amazon.

Paul: So a lot of caching, like these are files that ultimately people are downloading.

Laurie: Exactly.

Paul: So you’re able to put them into the Fastly cache and that way they are quick, easily available. So I’m downloading lots of stuff for free from npm. I love it. I never give npm any money. [laughter] That’s fantastic for me, it’s an incredibly good relationship that I have with npm that I hope lasts forever. But it’s probably not sustainable, because they two things you just mentioned cost quite a bit of money, and there’s another thing you have called engineers.

Laurie: Right.

Paul: That cost a lot of money. Oh by the way, what do the other people do besides engineers?

Laurie: We have a small sales and marketing team and we also have a growing support team. We have four people whose whole job is they sit there and answer peoples’ questions about npm, even if they don’t pay us any money.

Paul: OK. So again, not the greatest business model. [laughter] But…OK, so I’m assuming there’s some plan for these 22 people to be able to have, you know, careers, food…

Laurie: Exactly.

Paul: Lives.

Laurie: Um…

Paul: And you’re the chief operating officer?

Laurie: Yeah, I’m the one responsible for the business model, so I should really know, right?

Paul: That’s right, because, you know, the CEO, you know, that’s Isaac S., right?

Laurie: Yeah.

Paul: OK, so he’s off kind of, like, leading…

Laurie: He’s thought-leadering and philosophizing about the nature of software, and I’m like, “How do we pay for it?”

Paul: Right, they’re just throwing a stack of spreadsheets onto your desk and going, “Figure it out, Laurie.” [laughter]

Rich: But there is a business model here?

Laurie: Yeah, if you are familiar with GitHub, and I feel like most people are —

Paul: They are.

Laurie: Then you will recognize our business model. GitHub’s completely free for open source and everyone’s super happy about that, and if you do closed source software then you pay for it. And npm is exactly the same. If you have open source packages and you want the whole world to get them, then you can upload them and we will distribute them for free. But if you want to restrict who can access them, if you only want to keep them for yourself or you want to keep them within your team, then we have a SasS service that does that. And we also have, like GitHub, we have an enterprise product, which is a piece of software that you install on your own hardware, within your own firewall, and it is a very small copy of the registry that does everything the registry does, only privately.

Paul: Are most of your customers very big companies, very, or, or, like, who is a customer here, if you can’t name them, that’s OK, but like, what kind of companies?

Laurie: We are a 50/50 split between the two, so 50% of our money comes from a very large number of very small companies, like four or five people each. And the other 50% comes from a very small number of very big companies. Off the top of my head I can’t remember who has given us permission to mention that they are customers of us. I know that the BBC did.

Paul: So what did they get? They have lots of engineers. They’ve had people, you know, building BBC websites forever.

Laurie: Right.

Paul: Right, or not forever, but since the web started. And so they’re writing a bunch of JavaScript, and like, what is the advantage for them of using npm as opposed to, like, just having a GitHub repository with all their own little libraries in place?

Laurie: The relationship between, I mean, you can if you want to, put your private modules in a GitHub repository, but it is significantly slower, and just less convenient. It doesn’t work the same way. One of the features of npm is this thing called SemVer, or Semantic Versioning, which means that the way that you version your packages is a sort of social contract between programmers about how dangerous it is to pull in a new update. So, you know, a patch update is always supposed to be safe. A minor update is supposed to add features. And a major update is definitely gonna break things, that’s the contract of npm. And that’s a super-useful way to build software —

Paul: And I can figure that out, just by looking at the number, if I’m a programmer, I can be like, “Ooh, not that one. Not today.”

Laurie: Right.

Paul: Let’s get through the weekend and then see what they did.

Laurie: And again you can build it into your package JSON. So npm will automatic — you can tell npm if it’s totally safe, always bring it in, or you know, I’m feeling lucky, if it’s a new feature bring it in, and npm by default will never bring in something that will break you.

Paul: OK, so there is, this is a secret code whereby engineers communicate to each other as to how risky something is.

Laurie: Again, it’s about reducing friction. Like, they could solve this problem by having a meeting every time they commit a new line of code to their codebase, and say, “OK everybody, this one’s gonna break you, and that one isn’t gonna break you.” But if you just build it into the format, if you build it into the version thing, 10 people have to have 10 times fewer conversations, and 100 people have to have 100 times fewer conversations.

Paul: It’s worth noting here too, right, this is, these are people who are working and assuming a decentralized, asynchronous communication pattern, right? Like, they, they can’t have the meeting, because either the organization’s too big, or they don’t even know who’s gonna be using the code.

Laurie: Exactly.

Paul: OK. All right, so what, what is next, now?

Laurie: Well we just recently, uh, released a thing called free Orgs. So…

Paul: Is there a hyphen in there?

Laurie: No.

Paul: It’s just F-R-E-E-O-R-G-S?

Laurie: Exactly.

Paul: Because you guys just love vowels. [laughter] You’re just like, let’s get them all together. FREEEEORGS.

Laurie: Exactly.

Paul: OK, but it’s not pronounced fjorgs?

Laurie: No, it’s, Orgs was the product, and we made it free. We took a price cut of, of, we took the price down to zero for open source people

Paul: OK, so Orgs, I’m assuming, is short for organization.

Laurie: Exactly.

Paul: OK.

Laurie: Again, it’s like a GitHub organization: if you have a bunch of people and they need to coordinate, you want to be able to do things with a certain amount of granularity. You want to be able to say, “These people can publish this package, but these people can only install this package. These people can’t even see this package.” That kind of stuff.

Paul: So these are, it’s…people need rules in order to do certain kinds of things. Like, GitHub has, like, that makes sense. That’s one of the things that happens a lot in the open source world, is that you say, “This is the free and easy version that everybody can use in our beautiful community.”

Laurie: Mmmm hmmm.

Paul: And then for people who have to follow rules in order to succeed, because their company or their government says so.

Laurie: Mmmm hmmm.

Paul: Here’s this version.

Laurie: Yeah, it’s…it’s much more about the, the granularity of control, and so we have —

Paul: Less just blindly fascist.

Laurie: Right.

Paul: OK, good.

Laurie: We’ve had Orgs for paid customers for a while, and the big open source projects, they are essentially, you know, startups without money, right? They have, you know, 20 people working on this piece of software. They have the same collaboration issues that a startup would have.

Paul: Often millions of users.

Laurie: Right, but they didn’t have the feature set that companies have. So we said, if you’re working on open source software, you can have an Org and all of these feature sets and it will be free.

Paul: Great. OK.

Laurie: So I also think it’s worth having a little aside here about how GitHub and npm interact, because it’s a thing that not a lot of people understand, like, are they competing?

Paul: Because they’re both meritocracies? [laughter]

Laurie: Dear lord, let’s never use that word. [laughter]

Paul: Just a little aside there…I’m not gonna even go into that.

Laurie: Yeah.

Paul: Anyway, that was a little fun laugh for everybody who gets that joke.

Laurie: Yeah.

Paul: OK, so…

Laurie: GitHub is, in our opinion, the way that you collaborate on software to build the software. It’s the way that you develop software. And npm is the way that you distribute the software. So you don’t want to put, you know, if you have to transpile code from one format to another, you don’t want to check in the compiled code to GitHub, that’s gonna be annoying and, like, inflate your GitHub repo for —

Paul: And messy, yeah. It gets very messy quickly.

Laurie: Right.

Paul: OK.

Laurie: So you put your, you put, you know, your beautiful, clean source code into GitHub, and you work on it there, and then when you’re ready to build and you’re ready distribute, you put that into your npm package, and when you build your npm package, you exclude your tests and your documentation, because no one’s ever gonna see it, you don’t need to distribute that stuff, they don’t need to download it every time.

Paul: This is a really good point. Because of technologies — I’ll name one which a lot of people won’t know about who listen, but if they are in this world, they will: webpack. Webpack is a great example. Webpack takes all your JavaScript and a lot of other assets and puts it into a big old bundle that may not be human-readable in the way that your sourced JavaScript was — almost probably, definitely isn’t.

Rich: But it would be very efficient and…

Paul: Exactly.

Rich: Smaller and…

Paul: Well it’ll be one big blobby file with incredibly long lines.

Rich: Right.

Paul: That’s what happens a lot.

Laurie: Mmmm hmmm.

Paul: And so actually putting that on GitHub is essentially a liability. You just have this, like, crappy looking thing that no one needs to ever see that is built by a computer, not by a human.

Laurie: Right. Because when —

Paul: GitHub is about tracking human artifacts.

Laurie: Exactly. In GitHub you want to be able to have, you know, the rule of thumb is can you do a useful diff of a change, right?

Paul: Mmmm hmmm.

Laurie: On GitHub, you want to be able to see, I changed this one thing, and the little line went from green to red, or, you know, we added one character to this thing, and I understand what that is and I can say, “That is cool.” If the change is this gigantic binary file changed into a second gigantic binary file, you don’t want that in GitHub.

Paul: So in your world, you communicate change through semantic versioning.

Laurie: Exactly.

Paul: And it’s much more about risk than about actual, sort of, collaboration in that way, right?

Laurie: Correct.

Paul: It’s about managing your risk as an organization that’s gonna take in code that you didn’t right yourself.

Laurie: Exactly.

Paul: And put it into your own project. So you communicate through the semantic versioning and some of the programming around npm what that risk is, and then whatever the final deliverable is, which is sort of a blobbly — could be a blobby mess, you’re gonna handle that for me.

Laurie: Exactly.

Paul: And so, so when I’m using npm, what you’re really delivering is this, like, again, it’s lower friction, as you’ve pointed out, but I’m able to assess and understand my risk at adopting new, often very complex, interdependent sets of code, and also just go ahead and get that code after that risk has been assessed, and just slurp it into whatever I’m working on.

Laurie: Right. And it’s been surprisingly successful, like, when, you know, when npm was started, people were like, “Oh, I might have as many as 10 libraries in my package, and that sounds like a lot to manage,” and now people routinely have, you know, package trees that consist of 1,000 packages, right? They’re only directly depending on 10 of them, but, you know, those, they each have 10 and they each have 10. And to everyone’s surprise, it just sort of works. You know, the instances of a package breaking and breaking everything in the universe are much, much rarer than you would have expected had you, you know, built this in 2009 not knowing what it was doing.

Paul: But for a long time, you had the monopoly on this. Now there’s some new competitor? Collaborator? Something. There’s a new thing called Yarn.

Laurie: There is a new thing called Yarn.

Paul: What does Yarn do that’s different from npm? It’s a command, but…

Rich: Does Yarn stand for something?

Laurie: Uh, no —

Paul: Nothing stands for anything in this world.

Laurie: The programmer who wrote Yarn is obsessed with kittens, so he was writing —

Rich: That sounded like a jab.

Laurie: So he called it Yarn.

Paul: No, I don’t think “obsessed with kittens” is actually a jab in our world anymore.

Laurie: Yeah, no, no, everyone’s obsessed with kittens.

Rich: Oh. So how long has Yarn been out?

Laurie: Well first I think it’s useful for a lot of people to understand what Yarn is, because we use the word “npm” to refer to two very different things that are closely related. npm is a registry, which is this cloud service that we’re constantly scaling, and it is also a client. It is the thing, the piece of software that runs on your computer and talks to that registry. So Yarn is an alternative client. It still talks to our registry —

Paul: Oh!

Laurie: Uses the same registry —

Rich: Oh, I didn’t know this.

Laurie: A lot of people don’t know that.

Paul: Oh, look at that.

Laurie: So Yarn is just a different way of interacting with the same registry.

Paul: So they replaced the npm command?

Laurie: Correct.

Paul: But not the npm registry.

Laurie: Correct.

Paul: What keeps track of all the dependencies between the different tools?

Laurie: What do you mean by dependencies?

Paul: So when I go and download, it then goes and downloads three more things, which then go and download three more things each.

Laurie: Mmmm hmmm.

Paul: And then eventually 64 or 72 billion things come on to my computer.

Laurie: Right.

Paul: Is that just the, is that just, like, npm going, like, “Hey, I got this one. Ah, it needs this one.” Or is that, all that information held somewhere else?

Laurie: Um…it is, it is literally, when you look at, when you try and download a package, the registry serves you a piece of metadata that says, “This package depends on these three packages,” and then the client, whether it’s Yarn or npm, downloads those three packages and says, “Oh. And they depend on three and they depend on three and they depend on three.”

Paul: But the registry keeps track. It doesn’t simply, it extracts that information and gives it to you. It doesn’t actually — you don’t look inside of the JavaScript code to determine the dependencies in real time? Or do you…I mean…?

Laurie: We…

Paul: Help me, Laurie.

Rich: I mean, that’s the magic.

Laurie: Yeah. The serving…

Rich: It’s gonna take care of things.

Laurie: The serving of the packages and the serving of the metadata are done separately. The information about what versions you need is, you know, a tiny piece of text, and the actual package is a tarball file, so, uh, the clients are downloading both.

Paul: Did you know they were gonna ship Yarn before they shipped it?

Laurie: It was really funny. Because… [laughter] they were working on it for about a year.

Paul: Uh huh.

Rich: Wow.

Laurie: And the, the JavaScript community is full of people who have known each other a very long time and are all friends, and so, like, of the, you know, eight or nine people who were working on this project, four or five of them, sort of, very, sort of shadily, sort of backchanneled to me via DM or via email or in person, they were like, [whispers] “We’re working on this thing, but we can’t tell you…” I was like, “Well…thanks. The other three have already broken the code of silence and everyone has told me that you’re working on this thing and I wish that you’d just tell me that you’re working on it so that I can acknowledge that I know and that you’ve all told me at the same time.” So but they did officially tell us about a month before they released it and…

Paul: Well because they also, you — I mean, they need you.

Laurie: I mean, we need them. We are genuinely super happy that a company like Facebook and the three or four other companies that are contributing in a big way to Yarn decided to take some of the support burden of supporting 7 million users off of us. They had a genuinely different use case. They addressed it with a piece of software. And now those people who are angry at us aren’t angry anymore. That’s great.

Paul: I mean, this is the — this is the archetypal open source ethos, but it’s funny because what they’re doing, of course, is acknowledging that there is territoriality in our world. They wanted to make sure that you wouldn’t get too upset.

Rich: You actually hold — you wield a lot of power here.

Laurie: We do, and we wield it very, very lightly.

Paul: So there’s no point where you just turn to each other mad with power, and sort of just —

Rich: No, I’m thinking more like, we’ve tweaked the way the registry works, how the conversation happens and —

Paul: Well there was tremendous drama when the left-pad function, somebody pulled it out of the registry.

Laurie: Indeed.

Paul: A little tiny — little tiny bit of code that a lot of people depended on.

Laurie: Mmmm hmmm.

Paul: And they broke the internet.

Laurie: Yeah. Um, the thing about…and left-pad was a great example of it, the thing about having power in the open source world is that it’s the softest kind of power, you only have it as long as you agree not to wield it, right?

Paul: People are ready to take it away from you.

Laurie: Right.

Paul: Yeah.

Laurie: The only reason npm has the power that it has is because npm has the trust of the community right now. The very first time we do something that violates the trust of the community, the community will go elsewhere. That’s, that’s…

Rich: It’s very fragile.

Laurie: Right. It’s something that we spend an enormous amount of time thinking about, and we…never pissing off our users is absolutely at the forefront of our mind whenever we are doing anything, which is why —

Rich: And users —

Laurie: left-pad was such a scary thing to happen.

Rich: And can we talk about users for a second?

Laurie: Sure.

Rich: Because I’ve had a bad experience with a large user community. They want to be pissed off. There’s a subset of that population is just looking for something to get pissed off at, and when that wrath unleashes, it’s something. So it’s hard. You gotta stay ahead of it, and you gotta be just kind always to everyone and everything that’s happening.

Laurie: There’s definitely a sort of bell curve going on, right?

Rich: Right.

Laurie: You know, 1, 0.1% of people will always be extremely touchy about one thing, and when you have 100 people, that 0.1% is invisible, and when you have, you know, 7 million people…

Rich: It’s a real…

Laurie: That’s, like, 70,000 people. They’re just hanging around being pissed off at everything you do. There’s…there’s no way with a community that large we could satisfy everyone —

Rich: Exactly.

Laurie: So we try and do our best.

Rich: And they’re incredibly vocal, right. They go out of their way to be heard.

Paul: I gotta say, though. You know, given that you’re the COO of this organization with that kind of user base in this community? You’re looking great. [laughter]

Rich: Yeah. The love is there!

Paul: You’ve got very good posture for someone who has 7 million people who probably have opinions about your work.

Laurie: The thing about it is 99, like I said, 0.1% of them are —

Rich: Yeah.

Laurie: Get very angry —

Rich: It’s the 700.

Laurie: The 99.9% of them, the other, the other 6 million and change, they’re all really nice.

Paul: Yeah, it’s important to keep that in mind —

Rich: Every one!

Laurie: Most of them!

Paul: They tend not to drop by and tell you how great you’re doing, while the other ones shriek like eagles in your ears.

Laurie: You would actually be surprised. We have a channel in our Slack called “joy” which is literally just where we dump emails and tweets and things that make us really happy, when people just sort of spontaneously send us, like —

Rich: That’s great.

Paul: That is great.

Laurie: Declarations of affection, like, it does happen, all the time.

Paul: I mean, you’ve earned it. It is a magical tool that helps me get my work done, when I decide to do something in JavaScript. I always regret doing something in JavaScript, but I’m always glad that npm is there. [laughter]

Rich: Speaking of declarations of affection, why are people suing you?

Paul: We saw this in a tweet, that you’re getting — you’re getting weird legal letters.

Laurie: That is an excellent segue. Um…again, the law of large numbers here. We have 440,000 packages in the registry now.

Paul: And pretty good SEO. I’m imagining —

Laurie: Really, really good SEO.

Paul: OK.

Laurie: And this means that if you are, you know, a particularly zealous trademark or copyright lawyer and you search for, you know, you just naively search for the name of your product, you’re gonna find a package that has that name as well.

Paul: Sure.

Laurie: Sometimes it is somebody genuinely has written a piece of software that conflicts with your company, and in that case, as left-pad shows, uh, like, things get really sticky really quickly because, you know, trademark law is a box of spiders.

Paul: Sure. So I could, if I named my package “nescafe,” I could get in a pickle.

Laurie: Right.

Paul: Or create a pickle for you.

Rich: Especially if Nescafé…

Laurie: I mean…

Rich: Is in this space.

Laurie: I’m not a lawyer and I’m not gonna make legal declarations about when it is and isn’t a bad idea, but it gets incredibly tricky, and…

Paul: And people should know: people name their packages whatever the hell they want, and a lot of times it’s like, kind of, Yarn is named after, like, what kittens love to play with.

Laurie: Yeah. Some of the time the package is called that because it genuinely has something to do with that company, but most of the time, the package has the same name because it was just a common name.

Paul: Mmmm hmmm.

Laurie: And this is something that gives, I can say from experience, your average lawyer, or possibly your below-average lawyer, a lot of trouble. So one of the things that we have discovered that npm the company does is provide a surprising amount of sort of pro bono legal service for package offers where we get nastygrams from copyright and trademark holders going, “THIS PACKAGE IS BEING ILLEGALLY DISTRIBUTED,” and we have to explain to them that, you know, there is a, you know, a web framework called Express, and you have a magazine called Express, and those two things are not related, even though they have the same name. So…

Rich: This is predatory. I mean, it…

Laurie: It’s not so much predatory as inept.

Paul: It’s almost semi-automated, even if humans are doing it.

Rich: That’s an optimistic view of lawyers. It’s pretty predatory.

Laurie: They’re just doing a keyword search and sending it to literally every URL in the universe.

Rich: Yeah.

Paul: Which is predatory, actually, but…

Rich: Which is predatory.

Paul: Yeah, because it’s so cheap for them to do it.

Laurie: Right.

Paul: Right? They just go, you know, someone very inexpensively could find that address and send the lawyer over —

Rich: Yeah. I’m not a trademark lawyer, but I’m fairly certain that McDonald’s can’t go after the McDonald’s shoelace brand. [laughter] Because —

Paul: Well there’s a lot of —

Rich: It’s about confusion. It’s about dilution —

Paul: There’s a lot of stories like that.

Rich: Yeah.

Paul: But there is, there is clarity, like, Express and Express probably don’t — the law is probably pretty clear that those two aren’t aligned, but then again, why not send you a scary letter, because…

Rich: Scary letters are cheap.

Laurie: Yeah.

Paul: You might, you might show up and say, “What’ll it take to fix this?”

Laurie: And the reason that we do this is actually as a result of left-pad, because left-pad was the first — it was the sort of inflection point, it was the first time we’d been large enough for this specific form of conflict to happen, with somebody who didn’t immediately say, “Oh, I guess it’s your trademark. Fine.”

Rich: Got it.

Laurie: It was the first time somebody went, “No, I’m gonna fight you to the absolute death on this one.”

Rich: Yeah.

Laurie: And we didn’t have a process and we made, hands-down, a bad call there.

Paul: What did you do? I don’t even remember, to be frank.

Laurie: This company called kik said, “Hey, there’s this package called kik. Give us the package.” Azer, who owned that package at the time, said, literally, “No. Never.” But significantly less politely than that.

Paul: Mmmm hmmm. [laughter] Well engineers, you know…

Laurie: And…

Paul: That’s what it is.

Laurie: And the bad call we made was we said, kik has, you know, 60 million users, we should give it to kik, because no one’s using this other package.

Paul: Was there a lawyer involved in that?

Laurie: There was not a lawyer involved in that.

Paul: Oh. So this way you learned. [laughter] Hell of a lesson.

Laurie: So…

Rich: You live and you learn.

Paul: You know, Rich is a lawyer: the best thing about this company, is that I have a lawyer immediately to my left —

Rich: I have other qualities, but yeah, it’s one of the things I’ve used…

Paul: It’s great that you do product, but the thing that’s like the most useful is… [laughter]

Rich: Appreciate it.

Paul: Yeah, like the contracts go out and there’s no worries. It’s so good. Anyway, so. Lawyers are magical.

Laurie: Yeah.

Paul: They’re terrible but they’re magical.

Laurie: We have one now.

Paul: Mmmm.

Laurie: His name is Kyle and he is magical.

Paul: Hey, Kyle! [laughter] We love you, Kyle.

Laurie: Yeah, so Azer got mad at us for taking the package away which, like I said, bad call, shouldn’t have done that. And so he deleted all of his packages.

Paul: Ooooh.

Rich: Ahhhh.

Paul: Azerrrrrr….

Rich: See this is —

Laurie: Including left-pad, and that was how it happened.

Rich: Ahhhhhh.

Paul: And that was, deep-down, the DNA.

Rich: That is the backstory.

Paul: OK. This is a problem of scale, right?

Laurie: Right.

Paul: Is that, just, suddenly —

Rich: You’re gonna run into stories like this.

Paul: Well you also, you, you jump the barrier from a insular technology-focused community and suddenly, because of SEO, because of how things work on Google, and because of how the legal system works or doesn’t, you become part of the larger cultural sphere, and then you have no choice to participate —

Rich: Yeah.

Laurie: Right.

Paul: Because it’s punitive if you don’t actually get a good strategy.

Laurie: Right. So now, now just as a matter of course, we try and make the lawyers go away, and we try and prevent the lawyers yelling at people who are just open source authors trying to get through their day.

Paul: Good.

Laurie: And that’s been pretty effective but quite expensive.

Paul: Yeah, that’s not easy, and it is expensive.

Rich: You just are at the profile that you are at.

Laurie: Right.

Rich: That’s, that’s what comes with it.

Paul: No, but that’s a good thing, not to just pass on the legal fear.

Laurie: Yeah.

Paul: Because, you know, once you get practiced at receiving legal letters, they’re not a source of panic. You know, I’m sure if you get a letter at this point, you’re like, “OK. Here we go. Here’s what we do.”

Laurie: Yeah, I mean, at this point, they, we have, like, template responses going, “That is not how trademark works.” [laughter]

Paul: Right, but if you pass that along to a talented 19-year-old who uploaded some interesting piece of JavaScript and accidentally called it, I don’t know, Transformers 3…

Laurie: Right.

Paul: They’re gonna melt.

Laurie: Yeah.

Paul: It’s terrifying to get that…

Laurie: Yeah, I mean —

Rich: A lot of this is fear tactics.

Laurie: I mean, let’s be clear, sometimes people do, you know, upload genuinely copyright violating stuff to the registry, and we take it down as soon as that happens.

Paul: Sure. No, this is the thing, you’re fully in compliance with the law, with all of this, but…

Rich: It’s just…you’re willing to do that work. You’re taking, you’re taking a lot of stress off of the community.

Laurie: As a result of the incredibly traumatic experience that was left-pad for everyone involved.

Paul: This is a tricky thing, though, right? Because essentially this big open source project, once it gets to this scale, you are now a service layer for an entire community, whether you want to be or not. So it’s great to hear you embracing it.

Laurie: Yeah. It is worth saying that it is kind of weird that the whole JavaScript ecosystem now depends on the existence of a company. It is strange that open source does that. I mean, it’s not unique.

Paul: It’s true, because the other registries, I think, for other programming languages, like, you know, the CPAN for Perl and the RubyGems and so on.

Laurie: Mmmm hmmm.

Paul: They, they’re distributed and they’re not entirely owned by one entity. Or they’re managed in a more abstract way.

Rich: You are a commercial business.

Laurie: They’re all, they’re all managed differently, and the thing that we know about them is they’re all pretty underresourced.

Paul: Yes.

Laurie: And…

Paul: Always have been. They fall apart very quickly.

Laurie: Right. And we are also 10 times the size of the next biggest one. So…

Paul: What is the next biggest one?

Laurie: They next biggest one is Maven.

Paul: Oh, sure. For Java. Sure.

Laurie: Yeah. I’m not sure, I think we might be only twice as big as Maven. But we’re, the other ones are much smaller.

Paul: Regardless, you’re very big. And there’s also, there’s tremendous velocity here that there isn’t with other languages.

Laurie: Right, so we, you know, we considered and have repeatedly considered, you know, what if npm was a foundation, what if npm was a nonprofit, and it just doesn’t work. This keeping up a piece of infrastructure that is this big and growing this fast, you just can’t do it relying on the kindness of companies to, to donate hardware on time to you. The way to make it sustainable is to make it self-sustaining, so that’s why it’s a business and not a foundation.

Rich: The GitHub story.

Laurie: Right. Which is the other thing, right? It’s not like we are unique in this, like, an enormous amount of the open source community relies on GitHub existing at all times.

Rich: Sure.

Laurie: And GitHub is exactly the same business model.

Paul: Last question: what’s the hardest part of your job?

Laurie: [thoughtful sigh] There are a lot of hard parts of my job. [laughter] I think probably the people, though. We have 22 people and running a company, even of 22 people, is a surprisingly challenging activity. Everybody has, um, you know, everybody has feelings, and as a company, we try to take those feelings a lot more seriously than any other company that I’ve previously worked at.

Rich: This is, ladies and gentlemen, the first time a COO has ever said the word “feelings.” Ever. [laughter] So if you’re looking for the headline of this podcast, Paul, there it is. “CEO DECLARES FEELINGS.”

Paul: COO.

Rich: COO, sorry.

Paul: CEOs actually have to be pretty good about feelings? [laughter]

Rich: Yeah…

Paul: It is true. You get trained up on feelings. They get sent to, like, seminars.

Paul: Well humans are harder. That’s true.

Laurie: Yeah.

Rich: Yeah.

Laurie: And as we have, our CTO CJ says, uh, software is just typing, but humans are hard.

Paul: True. It’s very true. All right. Laurie, thank you.

Laurie: Thank you.

Paul: Please come back and visit us sometime. It’s nice to see you here in New York City.

Rich: Yes, and congratulations on this…

Paul: This is a tremendous success.

Laurie: Thanks.

Rich: You know, young startup, it just feels like, oh my God, here’s another turn, and here’s another turn, and you should sometimes pause and just look at what you’ve created, and say, “Wow. This is great.”

Laurie: [laughter] Thank you very much. We appreciate it.

Paul: We should probably become a customer, at this point.

Rich: We should. We really should.

Paul: Yeah. It might be time. [laughter] We’ll bring it up with our head of engineering. All right, well, Rich.

Rich: Paul.

Paul: We gotta get back to work, but let’s let people know a few things about Track Changes, the podcast of Postlight a digital product agency. First of all, if you wanna get in touch with us, what do you do?

Rich: Hello@postlight.com.

Paul: That’s an email address. If you wanna give us five stars on iTunes, you can do that, but it’s up to you. Live your life. And we gotta get back to work.

Rich: Let’s do it.

Paul: And thanks to Laurie for coming on to the show.

Laurie: Thanks again for nviting me.

Paul: Aw, it’s good to see you.

Rich: Take care.

Paul: Bye.