The Changelog: Software Development, Open Source - Federating JavaScript's language commons with Entropic (Interview)

Episode Date: August 2, 2019

We're joined by C J Silverio, aka ceejbot on Twitter, aka 2nd hire and former CTO at npm Inc. We talk with Ceej about her recent JS Conf EU talk titled “The Economies of Open Source” where she laid our her concerns with the JavaScript language commons being owned by venture capitalists. Currently the JavaScript language commons is controlled by the npm registery, and as you may know, npm is a VC backed for profit start up. Of course we also talk with Ceej about the bomb she dropped, Entropic, at the end of that talk — a federated package registry for JavaScript C J hopes will unseat npm and free the JavaScript language commons.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by DigitalOcean, the simplest cloud platform out there. And we're excited to share they now offer dedicated virtual droplets.

And unlike standard droplets, which use shared virtual CPU threads, their two performance plans, general purpose and CPU optimized, they have dedicated virtual CPU threads. This translates to higher performance and increased consistency during CPU intensive processes. So if you have build boxes, CI, CD, video encoding, machine learning, ad serving, game servers, databases, batch processing, data mining, application servers, or active front-end web servers that need to be full-duty CPU all day, every day, then check out DigitalOcean's dedicated virtual CPU droplets. Pricing is very competitive, starting at $40 a month. Learn more.

Get started for free with a $50 credit at do.co slash changelog. Again, do.co slash changelog. From Changelog Media, you're listening to the Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, we're joined by CJ Silverio, a.k.a. SiegeBot on Twitter, a.k.a. second hire and former CTO of NPM Inc. We're talking with Siege about her recent JSConf EU talk titled The Economies of Open Source,

where she laid out her concerns with the JavaScript Language Commons being owned by venture capitalists. Currently, the JavaScript Language Commons is controlled by the NPM registry. And as you may know, NPM is a VC-backed for-profit startup. Of course, we also talked with Siege about the bomb she dropped in Tropic at the end of that talk,

a federated package registry for JavaScript that she kind of hopes will unseat NPM and free the JavaScript comments. So we are super excited to be joined by CJ Silverio. You may know her as SiegeBot or simply Siege. Hello. Second hire and former CTO at NPM. And you're here to talk about something new and shiny

and not even out there yet. Don't use it yet, but it's super exciting. It's Entropic. Siege, thanks so much for joining us. Oh, it's a pleasure to be here with y'all. It's a pleasure to be talking JavaScript too. Absolutely. So you kind of dropped a bomb at JSConf EU

and have one of the most watched videos from the conference talks, which was published on June 3rd, all about the economies of open source. We're going to dive all into that. But can you give the elevator pitch or the brief synopsis? Everybody will link up that. You should definitely go watch it, especially like the last five or six minutes where the bomb gets dropped. But see, if you can, I just loved it. I wish I was in the room because everyone was so excited. You were excited. That was an amazing moment. I wish I was in the room because everyone was so excited. You were excited. That was an amazing moment.

I have never had a conference speaking moment like that before. Literally, when I got up, I had no idea how the crowd would react to the news. And when I heard the reaction, I was as surprised as anybody else. In this talk, I talk about NPM. I talk about JavaScript's package manager. I talk about its history, including a bunch of history that most people involved in JavaScript now might not know. Because it started in 2009, and the bulk of people using JavaScript on a daily basis never needed to know where it came from. It was just a fact of life. You start using JavaScript today, you're using NPM.

Well, how did NPM get there? Why is NPM there? Okay, it's a company. Why is it a company? How does it make money? What are its goals and motivations? And because I was an insider in part of the story, I could talk about that part of the story. It turns out that when you run something at that scale, it does cost money to run. And it's probably not a consequential number when you talk about giant businesses, right? Like it's, I think, Lori Voss, the chief operating officer at the time figured that you could run NPM, the company for 99 years for the amount of money Uber burned in a single quarter. Oh, wow.

Which is like, like, so scale, right? That tells you it's actually pretty small on the cost scale. But it's still a notable amount of money as far as human beings are concerned. You know, when you're talking about tens of thousands of dollars a month, well, you know, $30,000 and up in AWS bills and network bills,, that's notable, right? You have to have a story for how you're going to pay to run a package registry that every single JavaScript developer uses for free. Free is relative. You type npm install react or create react app. You didn't pay anything for that,

but it still cost money to happen. So how does that work? Right. Oh, we don't have to think about that. It just works. It just does. Yeah. For a little while.

For a little while. The fairies and bills get paid. Yeah. You leave out a little dish of milk and then the JavaScript. Once a year. This is JS milk right here. You know, I worked on the technical side of that, right? So, you know, we often came up, you know, people who worked at NPM would talk about how that happened.

So, you know, everyone understands, yeah, there's technical work that has to happen in order to bring that JavaScript to you. But then I felt it was time for people to look at where the money was coming from, why the money had to be there, and what the consequences of that are. Because we as a group, as a community of JavaScript developers took all of our comments, all of these open source packages that we want to share to each with each other, and we handed them over to a company that's VC funded. And, you know, obviously I was totally okay with this, this at the time. I like, I knew, I knew, okay, VC money comes with a hook, but I thought we'd be okay. I think the talk at Nontropic, the project come from my realization that I was fundamentally wrong. I made a mistake, not in like really working hard to make Node succeed, to make JavaScript go. That was fantastic work that I am so proud of. companies. I've worked with famous people and people on their way toward fame and brilliant

people who I've learned from. NPM team was just fantastic people. They were great human beings to work with. And I'm extremely proud of them and the work we did together. But I think it was in the service of the wrong cause. Not JavaScript, but the underlying profit motive was the wrong thing for that particular task. What was that profit motivation? I go a lot into this in the talk, but the motivation, it turns out like when you take VC money, you are suddenly in it in order to give the VCs a payoff. This is like a completely open transaction. Like when you take money from VCs, you should know this is generally how they approach it. This is how their funds work. Absolutely. This is what their timeline is for getting a return on investment. And you

can't like opt out of that. Once you've handed over a chunk of your company to them in exchange for this money, they in fact want that payoff. And you have handed control of your company to them in exchange for this money they in fact want that payoff and you have handed control over your company to them in exchange for that payoff sometimes that's exactly the right trade-off to make i'm working for a company right now that like vc funding makes perfect sense um external funding makes perfect sense because the money has a is a very clear thing you can do with it it has a very clear way to accelerate the business and there's a very clear thing you can do with it. It has a very clear way to accelerate the business. And there's a very clear exit story that makes sense, aligns with VC goals. And for something like a language ecosystem, this is not a short-term project. This is not a go big or go home project, right? It's not a, we're going to grow, we're going to be the biggest

possible, we're going to make a lot of money, we're going to have an exit, or we're just going to go bust, and we're going to be on that Tumblr blog of like my incredible journey, where you shut down everything, right? You can't do that. You can't do that with the thing that all of JavaScript needs to keep running. So I mean, there was a moment in time, and again, the talk goes through that you do a very good job of going kind of step by step through the history. There were some there that I definitely learned. Even Adam and I have been along for the ride,

so to speak, both as users of NPM and as people who are having these conversations. We've had Isaac on Founders Talk, we've had NPM employees, current and past on a lot of our shows. So we've been along for the ride, but definitely worth getting the full history. And there was a point in time where it's like,

this thing can exist for free without somebody stepping up and putting money in. And so like at that point, it was like, well, there's different ways of doing that. And the way that it went was VC Capital. And that really brought MPPM for into the you know for years it sustained it for years but it brought all of us alongside it and centralized the commons that was the moment I got involved actually and I probably wouldn't have been involved without like

like some way to pay my salary or at least that amount of all-consuming work for I is something people don't do for free you should never expect them to do for free. That's the way to burn people out. NPM, at the time it was founded, the very end of 2013 was when those first discussions happened. The very beginning of 2014 is when the company started moving as a company. During that period, NPM was just a tire fire. It was down. It was down,

it was like nine sixes of availability. It needed serious attention and serious operational work to stabilize it. And that is not something, it's hard to get that from human beings. It's hard to have people on call 24 seven without paying something for their time and attention. And the trade-off, the trade-off is really interesting because most of the language systems haven't done this, right? CPAN has chosen a very different approach to this, but RubyGems is a volunteer-run thing. And your expectations for RubyG gems are very different from where your expectations for npm are the scale that npm reached was possible because they had a team of professionals working on it and moving it from from a single like couch db to the system it was right to the system that it is now today when you say the expectations for RubyGems is different,

do you mean in terms of support, like speed of downloads? Because RubyGems is free to the end user, just like NPM is. Right, it's all of these things. NPM support was, for a while, legendary. The NPM support team was just fantastic. A bunch of really very empathetic, customer-centered people who did most of their time was spent supporting open source users, not paid users.

And the attempt was to give that really excellent, high quality level of support to everybody. You can't do that if you're not paying salaries because you're like using somebody on their free time and you're like the service level agreements kind of like, you know, you never really sign up for that with MPM. But people came to expect that they would get a really nice professional supportive, helpful answer from a professional support team. And the uptime, again, you know, when something is run by volunteers, you have a level of forgiveness that like they might not be awake at 3 a.m. in their time zone. But MPM, because it was a company, because it could afford to run operations 24-7, we had a team of contractors in Eastern Europe helping us on the times that we were asleep.

Because all that support was there, the expectation became that it would be up, that it would be fast, that you would get professional-level support because it was a company. It could do this. And this, I think, let it reach a scale and a ubiquity and an unthinking use level that it's harder for languages that didn't do this to reach. So we have a lot of listeners in the javascript and npm ecosystem and i'll just say for many years npm was kind of a

bastion of javascript and the ecosystem because of a lot of the support i mean the people that were there are awesome and it hasn't been until the last maybe six eight months maybe a year where we started to see the what's the the kinks and the chinks in the armor i don't know we started to see the problems uh come about but for those people who are maybe, you know, writing go day to day or not, not in that ecosystem, can you describe a few of the things where we say, this is, why is this a problem? What are we seeing where we're thinking maybe we made a bad decision or you said specifically you, you would have made a different decision back then maybe. Right. The idea that, that you might lose thing, or that this thing is in the hands of someone

whose incentives are not aligned with yours. Node, for example, is part of the OpenJS Foundation. It was its own foundation for a while. This is a community resource. It's the platform definition, the implementation of the platform, the direction that it goes in. This is essentially a community project. It's funded by corporations, but not by any one corporation. And they all have their goals, right? And they sometimes are at odds with each other, but mostly the turtles, there's no one turtle that like, you know, wins. They're just climbing over each other.

That metaphor is very insulting to them all. You're all more turtles. Maybe insulting to turtles. I don't know. That was very interesting. But the point is that there are checks and balances, and in the end, where the community needs to go is where it goes. And here we have this important, critical part of the ecosystem,

our shared code base, the things we give away to each other to reuse, to build the web with, isn't part of that foundation. It is in the hands of a company that needs to return its investment. Now, what are the things it's going to do to return that investment? Do you really want advertising in your NPM from your NPM client? This is something that VCs would occasionally very also proudly suggest to us. Yes, have you thought about putting advertising in the client? And the answer is always, lol.

Yeah. Right. Well, we've seen a few package maintainers starting to try such things like this, and there's lots of backlash. Developers don't like it, and then there's a lot of conversation. Well, it's a free thing.

You've got to support the maintainer, blah, blah, blah. There's a whole thing there that will breeze over. But yeah, for VCs, for sure, it's a straightforward thing you gotta support the maintainer blah blah there's a whole whole thing there that will that will breeze over but yeah for vcs for sure it's a straightforward path right for that exactly we're in this cycle of people needing to get paid salaries to do find jobs like needed to be done yeah with npm to get to the skill it's at yeah and we've got to find some way to get the money and the way that NPM thought to get the money to do this great adventure was through venture capital. But that had some obvious downsides to it. But then there's also some obvious upsides to venture capital, which is large amounts of cash,

hiring the right kind of people, accomplishing a mission. But you got that payback process happening. Right, there's a new master, basically. Exactly. Exactly. And if you do your job as a company, if you come up with a product that pays the bills, if MPM had found a way to monetize the public registry, we wouldn't be having this conversation.

Everything would feel differently. But they never found a way to make their biggest expense turn into income. Right. a way to make their biggest expense turn into income like it's all of those trillions of downloads that nearly exponential download graph represents cost right we're able to with with engineering like solid engineering work i won't say brilliant engineering engineering work i think it was solid straightforward engineering work of the kind you can feel good about. That turned it mostly into linear costs in response to that exponential growth. But still, costs continue to rise. Yeah.

I mean, that was the goal of the new CEO, right? So we had Isaac on Founders Talk. Adam, you talked to him. This was a year ago, maybe more. And he was bringing on a new CEO. And it was his job to find a way to turn those costs into profits, right? And that's been where we got really rocky after that. Yeah, it did. He was interesting. He's an interesting character. Is he still there? Is he still the CEO today? He's still, surprisingly to

me, still the CEO, yeah. He questioned assumptions in a way that I actually think was useful and healthy. Like, you know, he walks in and says, why do we have to run the public registry? Now, that's a perfectly legit question to ask about the company. It's kind of an earth-shaking question to ask if your vantage point is JavaScript. Yeah, for sure. Let's just turn this cost thing off. Yeah.

You know, I don't think anyone ever floated to turn the cost thing off. would be give the costing away. But it kind of rocks the foundation of the whole reason the company exists. Why does NPM the company exists to run the public registry? Why did everyone who went to work there work there, it was to run the public registry. That was a very mission driven group of people, right? And I was totally driven by the mission myself. Public registry was why I cared about my job. It was a way to have a really high impact on the world and on developers, like when your work is used by every single web developer in the world. That's amazing. It's just such a lucky thing to have in your career, that feeling. So let's return to the end of the talk now, because we've talked about some of the problems with NPM and I want to set the stage. I want everybody to go watch, especially the end, because it's so much fun. I will admit as a, as an interested listener, but somebody not

there and I was just watching it, you know, along for the ride, step-by-step, I started thinking, I understand step-by-step what she's saying. So far, it sounds like mostly just stating the problem. You know, I'm'm like i'm not gonna say you were overly complaining but like i was starting to feel depressed i'm like yeah this is like just problems problems problems and then you said i'm not a fan of hand wringing i don't like the do nothing answer and you said i believe in open source it's good for us to give code away to others and you announced entropic oh yeah that was. That was the bomb drop for me. And this was awesome.

Tell everybody what Entropic is for those who weren't there or haven't watched it yet. Entropic is an open source federated package manager and CLI for JavaScript. It doesn't have to be for JavaScript. I have goals of solving package management problems for other languages someday, but JavaScript first. We set out to make something that would make it possible for everyone to run

their own registry without needing to shoulder the full burden of being a centralized registry for all of the JavaScript ecosystem. You can mirror or support as much traffic as you need to. You mirror the part of the registry you're using. There might be a lot of these. They federate data with each other. I was deeply inspired not by Mastodon's API, but Mastodon's the concept of ActivityPub and how you can have something that replaces the centralization of Twitter with something where I can run a Mastodon. I do run in Mastodon instance, and my friends are on it. And we participated in this wider ecosystem. And I don't have to be Twitter sized in order to do that. I thought, why can't I do this with package management?

The other thing that we had, Chris, my partner in this project, Chris Dickinson and I, we're now joined by Kat Marchand, but Kat wasn't part of the project at the time of the announcement. Chris Dickinson and I had spent the previous four years, more or less, running NPM's registry, coping with the scaling challenges inherent in it. And we had a very good understanding of the set of problems you have to solve in order to do this at scale. We had a very clear idea of the problems with NPM's data model. Something quite like living with something and needing to make it go big to understand exactly why it was a bad idea.

You never know when you start it. And, you know, we knew what was wrong with the API. We knew what a good API would look like. We had some very clear ideas about how to make this, like, achievable for normal human beings who didn't have enormous AWS account and bandwidth to burn. So we said, okay, let's do it. We were there for the mission.

Let's keep working on the mission. Let's keep working on the mission. Let's make it so that whoever does this next doesn't need VC level money to make it work. So that you can take control of your data. If say, Substack, I love talking about Substack because he's such a fascinating human being. have you ever had him on the show he's james holiday have we had him not yet not yet what's wrong with us yeah it's pretty active in early node right and he's got all these little like he and dominic tar have all these little modules they're like dominic on the show yeah yeah dominic is another great example of like i want to hand him back control of his stuff. I want it possible for Dominic to run his own entropic instance and just federate his stuff to the world and maybe even sell access to it if he wants to make money as an open source author. I think that should be a thing he should

be able to do. I want the Node Foundation or the OpenJS Foundation as it is now. To be able to run an instance themselves that has the heart of JavaScript in it so that they're safe, they've got control of their destiny, the thing that's important for them to run and important to every Node user is something they can run themselves. Yeah, I just wanted people to have, to be able to run a registry themselves.

And I thought, it's an ambitious goal. Writing a syncing algorithm that works has been really fun. Chris's brain has been melting out of his ears, but I think we have it. Well, let me just give you props on bringing a solution, bringing code to the table and saying, here it is world, here's all the problems, but we're working on it.

We're going to solve it. It was a, it was a mission statement for me. It was like, here's why I'm here. Here's why this matters. Okay. I'm not just complaining. Here's what I'm doing. This episode is brought to you by GoCD. With native integrations for Kubernetes and a Helm chart to quickly get started, GoCD is an easy choice for cloud-native teams. With GoCD running on Kubernetes, you define your build workflow and let GoCD provision and scale build infrastructure on the fly for you. GoCD installs as a Kubernetes native application, which allows for ease of operations, easily

upgrade and maintain GoCD using Helm, scale your build infrastructure elastically with a new Elastic agent that uses Kubernetes conventions to dynamically scale GoCD agents. GoCD also has first class integration with Docker registries, easily compose, track, and visualize deployments on Kubernetes. Learn more and get started at gocd.org slash kubernetes. Again, gocd.org slash kubernetes. so your announcement talk was late may early june-ish 2019 and you brought code but you said don't use it it's not ready yet props on bringing a solution to the table it's very much in development how long have you been working on it by then? And when did this idea begin and the code start to go? So this will shock you. Chris and I had been working on it for about four weeks at that point. We didn't write a single line of code until the day after

his last day at NPM. He kind of pinged me and said, we should talk about stuff. And I'm like, I'm not going to say a darn word to you until you're out. And I had a design document for an approach at this. And the Saturday after his last day at NPM, I sent him the design document. And he sent it back to me with like only exactly one sentence, still the same in it. He rewrote it for you? Yeah, he rewrote the whole thing for me. I believe the sentence was, and we'll still use Semver,

but probably standard Semver instead of NPM Semver. It's the only sentence that stayed the same. Is it worth diving into the difference between NPM versus standard Semver? I didn't know there was a... The twiddle and the hat, I believe, are extra features. Yeah, and Rust interprets them differently it's it's always like a the things that are always the worst are standards that are almost but not quite almost standards yeah so he rewrote it and yeah he wrote it in there yeah and then i came back to him a

couple days later and said okay how about this but plot, we federate it. And he says, okay, what does that mean? And I said, okay, let's walk through the implications of that. So we started walking through what happens when these things aren't centralized, like when they're exchanging data back and forth. And at this point, we actually had missed working with each other quite a bit, so we started this frenetic four weeks of hacking together where we wrote an awful lot of code that we threw away, but it was just getting back into the groove of writing code again,

especially back into the groove of writing code together again. There have been people like this in my career I've enjoyed writing code with. It's always such a pleasure. I enjoy writing code with Chris. We have radically different styles. Chris hates semicolons. I like semicolons. That seems like a non-starter right there. I mean, how can you actually work together? It's really funny. We ended up with a code styles format for Entropic that we're essentially trolling each other with it. Like passive aggressive semicolon usage.

Passive aggressive semicolon usage for me. And then he torments me by standardizing on two spaces to intent. Well, I'm glad you guys are sweating the important things. The interesting insight that we both have is that these actually aren't important things and they're so unimportant that both of us are willing to compromise on it. So we had four weeks of like, just, we wrote a version, we wrote a working registry in four weeks. It wasn't the API we wanted to have, but you could install through it and it would store packages and it would then install from that locally. And then we said, okay, that was really easy. Almost too easy. Probably, you know, it's like lots of features missing and it would probably fall over in a stiff breeze. But like, all right, that was a good warmup. Now let's talk about federation.

Let's talk about what you have to do in order to have more than one of these and they're synchronizing. And let's talk about what the API really should be. This was the fun part. It was like getting back into straight up engineering and design together for the first time in a while. So the current, the NPM's data model is based on this tarball, right? You take a package, take a bunch of JavaScript code that's sitting in this

directory, and you just, you have these rules for designing what goes into the tarball, and then you put it into tarball, and then you ship the tarball around. The tarball is the unit of communication. There's metadata on top of that, right? There's like the package JSON, which is a big vague document. It's like package metadata and metadata for each package version. And these are the fundamental building blocks of the existing NPM API. And we said, all right, what if we write our own CLI for this? What would the API be? And what does this actually let us do with the data model? These are the important things to get right, I think, because implementations are kind of less important

than getting these building blocks solid. If we have modeled the data of what should be in a JavaScript package correctly, and if we have documented an API that's good enough, then our implementation of Entropic shouldn't matter. You should be able to go and write your own. So that's like where all the work is right now is like taking what we wrote and throwing it away with something that's like the right thing for the future okay so the tar ball why is why is the tar ball not good i can tell you why yeah i mean you're asking me but i'm sitting here thinking tar balls are cool

you know yeah pass them around unzip them yeah untar them unzip them but the thing is is that all right you have a package js party package you have a fix, you make a change to this package, you publish it again, you may have that bug fix may touch one file, like you've you've got a three line change in this one file. So you make a tarball, it's got all the same stuff in it as all the previous tarballs, except for this one bug fix. And then that's the unit of data that gets shipped around. This is, this is like,. This is inefficient, obviously, because most of that data is exactly the same. The API doesn't let you talk about it as anything other than a tarball.

This is the core idea behind Kat Marchand's Tink project, which is like, what if we talk about it in terms of files instead? This is still not at rsync level, where you're talking about blocks and files, but it pushes things in the rsync direction where the unit of exchange is much smaller. Files are pretty good. Files are probably good enough for this. Complexity versus time and space tradeoff, as usual.

Like rsync is pretty awesome, but do you really want to have rsync be your package management stuff? Maybe. or sync be your package management stuff maybe. Chunking it up at the unit of files lets you also do things like the secret of Tink and of Entropic, which is content addressable storage, where you store files, but you only ever store any file once. Just do a SHA-256 hash of its contents, and then that's the address. So you can get that same thing out by reference. Yeah, so a version of a package just becomes a list of hashes this is where the content comes from this is where you

put it on disk if you have those files already you don't have to transfer them maybe so when installing your patched version of js party the only thing you have to grab is that new one file because your new package is just a list of those hashes and only one of them is changed. Yep. That's cool. And this really, this again, like going back to the data model, going super nerdy insider baseball here on the details of

the NPM data model. But this is like, you can hear how excited I am about this. This is the fun part for me. Packages, if you ever just like type NPM info in a package package or if you get a package json you curl it for the npm registry it could be really huge it could be megabytes large because it's effectively unbounded right you've got the package the top level package information what's name is what's description is all that stuff and then you have per version data

and a per version data data because it just grows unbounded because you can have infinity versions for a package. I used to hate it too. There were some NPM packages that had over 5,000 versions on them.

Eventually, these users would split off into a new package just because it became so unwieldy to download a package. This speaks to the same anxiety I expressed back when we were talking about blockchains Adam. It's like all you do is add to the like you just add, add, add. It's an append only log. I hate that.

There's no trimming, there's no truncation like come on. Come on people. Sharding anything. Unbound is bad. This makes total sense when you're designing something in 2009 you've got 10 users right and you've got like oh my god i've got 40 packages this is epic some of these packages have three versions like you don't think ahead and you shouldn't think ahead because thinking ahead means complexity and an awful lot of work that you

probably a lot of yeah yeah yeahature optimizations, all those things. What about, so just, and these weren't decisions that you were making, but you've mentioned CPAN. I'm thinking about MIRS. Like, there are other projects

that have come before. Yep. And now you guys have an experience of building a whole thing and, you know, scaling it. And so you and Chris have all that experience

of NPM. But are you also looking around and saying, like, how did RPM work? How does CPAN work? How do these other things work yeah cpan is absolutely another inspiration right because it's like it's a it's a network of volunteer sites that together make sure that all of pearl's packages are mirrored i in the end if entropic is successful i would like that to be the solution like where

there's like you know a hundred of these around a hundred of these around maybe some companies that want them have them internally um and but all of javascript is redundant and safe across a network of these things that can cooperate with each other yeah cpan's huge inspiration uh anti-goals would be things that like coco pods has a perfectly great solution for itself that is like relies on github being there i guess the same thing is true of uh like the brew package manager is like it depends on a central github a git thing which is i think okay given their scale it doesn't satisfy me very very much though because it relies on that centralization.

Essentially, CocoaPods relies on GitHub, now Microsoft, continuing to be generous and just supporting open source, which is, to their credit, they've been great. They're doing it. Well, let's pause and talk about that because that's kind of, I don't know if it's an elephant in the room, but if you talk about the problem with centralization,

at least package registry diversity is better like two is better than one and now github is getting in the package management game yeah yeah well i i think when i wear the hat of somebody who's like running an engineering team here for this the company i'm working for i think oh yeah actually it makes total sense because team management is a huge thing. And GitHub, we're already using GitHub. This is just an incremental step. It makes perfect sense. Aggregation theory says that everything that GitHub does here in this space, I'll just go right in and start using it because it's easy.

Right. So Entropicropic obviously a different model from from all these models but centralization has its advantages too so we can talk about federation problems i mean there's security issues there's convenience issues there's hosting issues the problem of like i mean even with mastodon you have the opportunity for all these other instances but like Mastodon.social is probably like 80% of the... I'm just making that number up, by the way. It's a huge instance.

People tend to centralize anyways because it's the easy way. These are things you're thinking about, right? It's discoverability is easier when everything's centralized. You have control. Twitter can make a change to how Twitter works and it's immediate across the whole deployed base

some people have features other people don't there's a huge barrier to entry NPM can yank a malicious repo or a malicious package this right here is super important NPM also is a centralized place every published package goes through adam baldwin's suspicious beautifully suspicious hands i love that i love that description i'm not really sure that's a it sounds like a compliment

it absolutely is a compliment to tell him you said that i hear you have beautifully suspicious hands. We've had Adam on Jay's party. He's a great guy. He's totally a great guy. He's an expert. And because it's centralized, he can look at every package that comes in and he can crack it open. He can look for like... NPM audit's a great thing, right? Right.

That was a big deal for the security acquisition like a year or so back. That was a big deal at the time even too. What was that that was going on, Jared, at the time? An exploit? Yeah, it was either an exploit or the case where it might have been left-pad, potentially. No, event stream, probably. Yeah, event stream was later.

There was an ESLint vulnerability. Somebody's account got compromised during that time. And there was, there was also during the year, a whole string of incidents of coin hive being just embedded in things. Oh yeah.

Coin hive. It got to the point where like any package that mentioned coin hive or depended on coin hive, I'd look at it suspiciously. Like, are you on the level? So, you know, you know you know all these instances way better than we do because you you were dealing with them directly how does um when you look at entropic and

being federated as it relates to security what is your how do you approach security in the entropic world okay so what kind of security is the first question? Let's talk about kinds of security. There's like tampering with contents. Like, are you getting what somebody intended to publish? There's that question. Kind of like a reproducible build kind of scenario? Yeah, or just like, did someone tamper? Like, John David Dalton publishes Lodash. Are you getting what John David Dalton intended to publish?

Was it John David Dalton who was doing that particular publication of Lodash. Are you getting what John David Dalton intended to publish? Was it John David Dalton who was doing that particular publication of Lodash? These are security questions that you absolutely have to answer. Who's doing it? Are these the same bits they published? Have they been tampered with? And then you have another set of security questions which are like, are these bits intended to be good? There's a difference between the accidental bug where, oops, Lodash has a prototype pollution bug in it somewhere.

Okay, that's a security issue. It's not an intentional security issue, but it's nonetheless a bug that has to get fixed. Vulnerability, right, yeah. In the software itself, though, not in the registry, right? Yeah. A bad version goes in because that person wrote a bug. That's right.

And that's like unintentional and will forever be with us. Yes. And then there's like the malicious vulnerability with like EventStream where a maintainer with bad intent gets control of a package through completely legit means and then publishes bits with a bad intention. Right. And those bits were legitimate too because that person had gotten the access in legitimate ways, was not hacking, so to speak. They may have used social constructs to hack.

Yeah. Social engineering, yeah. But they had authorized access to publish to NPM, so it wasn't like they were even committing fraud, so to speak, even. That's right. And that is super hard to defend against. You might be able to detect it after the fact by looking at the bits that were published and saying, oh, these point to nobody should ever be publishing to a paste bin.

But those are the things like the advantage of the centralization the advantage of vc funding action time to that yeah it's a reaction time because you can afford to pay out of baldwin and a team to be looking at these things all the time but there are other there are other fundamental um security questions that i i felt while i was at npm that npm didn't have good answers for. And it was difficult to make progress on them because of resources. Things like package signing. Everyone wants package signing. And it's actually tricky. What is package signing? What are you signing? What are you signing it? What are you defending against when you sign a package? These are the

questions, by the way, that I'm working on right now within Tropic. Because the data model is different. We have a top-level package metadata and then an immutable version metadata object that is separate. We have a thing that we could consider signing. That manifest, that content addressable manifest of files, is a thing we can reasonably have an author sign. And what's more, if you use existing signing networks, like if you use Keybase, which is essentially usable PGP, you also have an identity trail, which is really interesting. I can figure out if the John David Dalton who signed

this package is the same John David Dalton who's using this GitHub account as the same John David Dalton who's on this Twitter account. I still don't know if it's the same person I meet in real life unless they tell me that. But it's like... Yeah, I have an...

You have a web of identity trust, right? That might help with that Dominic Tarr problem a little bit. You'd be like, who is this person? They don't have presence. Are they for real? Right. The other change you have with federation versus centralization,

which I guess we could argue on either side which one's more secure, but you have with centralization a singular, in both GitHub and NPM's case, you know, capitalistic, motivated company who's motivated to secure the registry. And in the case of federation, maybe you have a thousand instances, and these people are volunteers and running it on their home machine and stuff like this. I mean, obviously, there might be corporations running instances, probably likely that that'll be the case since there's costs, but potentially like you could get your instance could get owned and now you have an untrusted instance. Yes, exactly.

This, by the way, is Chris's current, like the topic he's chewing on and it's actually connected with package signing because the identity of an instance has to be established, registered somewhere centrally. Like, here we go, centralization rears its ugly head. But you need to know that entropic.dev, which is run by CJ today, is the same entropic.dev like three months from now that's run by CJ. You have to have a way to know that that instance is the same that you can trust it that its signature on a package is valid i think right

now that we're going to end up leaning on on keybase to do this because they they not only have that central registry of public keys they can give you a chain of history of the public keys and their sick chain concepts so you if, say, someone loses a hard disk and has to wipe their entropic instance, they can reestablish their ownership of that specific thing. And if you're getting bits from them, you can trust those bits. This is the thing. Let's suppose we have three of these things.

I publish a Twitter bot to my instance, or a tool that you use to make Twitter bots to my instance. This is called T. Let's suppose we have three of these things. I publish a Twitter bot to my instance, or a tool that you use to make Twitter bots to my instance. This is called TweetBot. Yeah, let's call it TweetBots. And you use it. You make a Twitter bot. You want to have a copy of that on your own entropic instance so that you never have to depend on me.

I can delete it. There will never be a left pad here because you've got a local copy. And let's suppose you want to use that for your different Twitter bot. Do you have to go back to home to me? What if I've gone away? You could get those bits from the middle one. How do you know that those bits are the same bits? Okay.

If we have a web of trust and signatures that we can trust and verify, then you can depend on getting the same bits. This is not a solution to the problem of, are those bits malicious? That, I think, in the end, still depends on expert humans looking at things. You could imagine the Node Foundation running a... I keep calling them the Node Foundation.

They're the OpenJS Foundation now. They were that for a long time. The OpenJS Foundation, the home of all things JavaScript, running their own instance, foundation they're the open js foundation now they were that for a long time the open js foundation the home of all things javascript running their own instance where they um they only have packages they've vetted they don't they don't mirror anything else so you know that you can trust them these are these are interesting problems and we could get them wrong this is like you want to talk about doubts about entropic this is actually actually hard. Yeah. It sounds hard. Is Keybase, is that a company?

Is that a foundation? It's a company. This is like we have another single kind of. Yeah. Yeah. We just had this discussion internally. Kat, Chris and I talking about do we want to trust Keybase? Yeah.

Not sure yet. Yeah. Yeah. I'm not sure. But I don't want to trust Keybase? Yeah. Not sure yet. Yeah, I'm not sure. But I don't want to have to write that, right? Because I don't want to have to write that sick chain log again because security thinking is hard. If somebody who knows what they're doing has already written it, oh, I don't want to have to reinvent that. Yeah, but package management is hard. If somebody's already done it, then I won't have to reinvent it, right?

Yeah. It's like this walk, this delicate dance of like enough centralization to be helpful. Not too much. Enough federation that we will never be in a situation like we're in now where we are depending on a VC finance company that could go away. This episode is brought to you by cross browser testing of smart bear,

the innovator behind the tools that make it easier for you to create better software faster. If you're building a website and don't know how it's going to render across different browsers or even mobile devices, you'll want to give this tool a shot. It's the only all-in-one testing platform that lets you run automated visual and manual UI tests across thousands of real desktop and mobile browsers. Make sure every experience is perfect for everyone who uses your site, and it's easy and completely free to try.

Check it out at crossbrowsertesting.com slash changelog. Again at crossbrowsertesting.com slash changelog. Again, crossbrowsertesting.com slash changelog. So we've talked about doubts. We've got our doubts, obviously. But Siege, I'm sure that yours are better positioned than ours simply because we're outsiders. What are your doubts with Entropic? Where do you see the – where are the holes in the cheese, so to speak? Well, we've set ourselves a pretty chewy technical problem.

The problems of writing a package register from scratch are difficult enough, right? Like this is a very large ecosystem we have to support. And the way we've chosen to approach the problem is inherently more difficult than a centralized solution would be. We've talked about the security questions, how identity works

when it's diffused across multiple instances, package signing, can you trust the bits you have? All of these things are more technically challenging than writing a very straightforward single source API would be. So we've kind of set ourselves a hard problem. The other interesting thing that we're discovering is that it's even harder because it's not our day jobs anymore. Chris and I both have demanding tech jobs that want our brains and attention during the day.

And, you know, cats moving on to do package management for Microsoft that like, whoa, this is not something we have the luxury of when we were spending our free time on. Yeah. So the question is like, okay, can we devote enough time to move it forward? Right. You got limited time. Yeah. Are people going to be okay with the pace at which it's happening um can we do this without burning out like open source burnout is a real problem yeah i'm sure people have talked about this with you before like you're not getting paid for this work you are doing it as a labor of love you're doing it because it's fun and suddenly you've got a thousand users and they want bug fixes and they're all entitled or they're mad at you because you ruined their day with that bug but that's not how you make a living and you've got a life to go back to

so we've spent a lot of time talking about how we want to work and how we want to make decisions and the pace at which we want to work and like it's to be seen whether we can actually pull that part off. And I think we're up to the technical challenges of the design. Chris and Kat are two very smart people. I'm very privileged to be trailing along after them watching what they do. So I think they'll solve the technical problems. Will they fail to burn out? Can I prevent them from burning out? Chris has some very thoughtful insights on this.

We were talking about GitHub. GitHub is a really great place to discuss code. It's a really great place to chew on a PR. I think it's actually a very bad place to run a project. This is sort of a weird thing to say, right? Because so much of open source is homed on GitHub. But I think the incentives are all kind of weird because they're about discussing code and PRs and the pressure to get at code and PRs and to bring those numbers down. Like it's gamified, get your issue count to zero, get your PR count to zero. But that's like discussing work once it's already done. It's not how you discuss work that you intend to do.

It's not... It's not a good place to discuss... It's tactical versus strategy. Yes, exactly. Your design, the part where we talk about okay, entropic instances have to identify themselves to each other. We have to be able to trace an identity through time

to make sure that this entropic dev is the same entropic dev as last week. That's a conversation. That's a conversation among human beings. We have to talk to make sure we understand the problem and have agreed like, okay, this is a good problem statement. And then we have to go off and think, come back and talk about a proposed solution. And then sometime later, you end up with GitHub

where you are discussing a specific implementation of that proposed solution. So how do we set up a project where that happens in a really constructive way? Tell us. Well, this is experimental right now. in a really constructive way. I mean, tell us. Tell us. Well, this is experimental right now.

We set up a discourse so we could have a forum and talk to each other. And this was actually hard. Chris and I didn't switch over to it. And then we were asking ourselves, why are we not doing it? Oh, because we're in this little teeny Slack with each other. And we're just talking to each other on Slack instead of going over the discourse. Okay, guess what? We got to not do that. It's chat.

And that was actually what we're looking for. It's sort of a problem that Slack is better, but Slack is not very good if you want to have an open source project, because we want people to just drop it. What we want is modern IRC. Yeah, so this is like me walking through this like recapitulating the history of open source projects of the past why do they all have ircs ircs is terrible oh i get it now oh okay all right irc is still terrible yeah it's terrible but but i get like we now have an open chat we have a we have a Discord that we invite people to come in if they want to chat with us.

Kat is most active right now on it. She's got a month off between jobs, so she's there all the time. We're trying to do our conversation there. We also try to kind of codify the way we've worked together for years now, which is we don't actually do anything out of the blue. We bounce ideas around first before we do anything. We never lead with code. We lead with, what if this?

What if, here's three paragraphs of what I think we might try to do and why. We lead with writing and talking. And then it progresses finally to code. Code is like the last step, often the easiest step once you've like worked out what you want to do. So tie that back into how that's going to prevent the burnout because you're going to have more contributors because you're going to talk more. Well, we're going to, we just, we have deliberately set up a pace for ourselves where we like no decisions are going to be made on weekends.

This is a rule we have. We do not make decisions on weekends. Why that? Because that actually gives you the space to have a weekend on your own. You don't have to sit there on the project watching everything going on out of fear that someone's going to make a decision you don't agree with or have to prevent for whatever reason. You can go away. You can have a weekend. And then on the regular team meeting on a Tuesday, then that's where decisions will be made. So you have space where it's okay to be away from the project. Yeah, the maintainer guilt is really terrible, honestly.

Because, I mean, if you're productive, Siege, and I'm your cohort in a project, and you're productive over the weekend, and I'm trying to hang out with my family family and I'm trying to separate my life and have that balance that's necessary, you might feel bad because you're productive and here I am, you know, slacking with my family. Yeah, just by doing work, I create work for you and I create pressure for you that, like, it's hard to cope with. We have to recognize our responsibilities to our team members. The influence that we have on their subconscious and psyche on what they're trying to plan for. So one doubt for me, and then we'll talk about how people can get involved with what sounds like a very interesting open source project. My doubt is on adoption.

I'm curious, just a few quick questions. Can you reuse package JSONs? Do developers have to re-release their packages for Entropic? Or can you suck in an NPM's registry, all that? We're using Toml as our package metadata description thing, so you can have a package JSON and a Toml file coexisting in the project. You would have to publish twice. We reuse legacy packages quite easily. You just install the legacy

package, say package name at legacy and it gets mirrored to your local entropic. This part's working. Yay, something that's working. Something's working. And then you have it. You can install from it locally using the new API once it's mirrored once.

And then keep that up to date. We're still discussing how often should we go and re-mirror? Should we only ever lazily mirror all these fun things? Yeah. So we should be able to coexist. Adoption is really interesting. Wow, I don't know. This is like one of those, well, it could fall flat on its face here.

I think if we get it right and if it's good enough, if it solves people's problems well enough, and if that network of speed savings we think we can offer is good enough, I think that will happen over time. I'm playing a long game here. I don't need it to be successful in six months. I need it to be successful in six months. I need it to be successful in three years. I need it to be here when NPM finds it can't exist viably anymore. It needs to be here when whatever landing place it ends up with, like, decides it doesn't want to run this very expensive thing anymore. So I'm thinking long term. I'm patient. What do you think the adoption strategy plays out?

So it's one thing to be patient and one thing to have sort of a long-term view. You still have to have an adoption process plan. What are you thinking? I'm thinking I work very carefully with the Node project. I think I am there. I need to be there to talk, satisfy their needs and to make sure that I'm scratching their

itch and that they understand this is the eventual home for this code. I think if the Node project finds a use for this, it'll be okay. So they matter to me more than anything else. I'm only in this because I actually really love Node, and I really love writing Node code. Like, why did I get involved in MPMP in the first place? Because Node was having a hard time, because MPM was down, and I was having a hard time with my you know team at the time we were trying to write node and we couldn't because npm was down so i'm like i'm here to make node win absolutely sincerely so i want to satisfy

their needs and if i think we think if we do that the adoption follows but again like this this who knows um well it sounds like if if listeners if you are interested in a fascinating project with lots of technical hurdles uh lots of problems and no doubt an interesting ride you can get in at the ground floor of entropic it's oh yeah it's not even taken off yet it's still just heating up the engines so siege tell everybody where's the best place to go you mentioned the discord what what are you expecting listeners to do? I know you have some talks coming up. Yeah, it looks like either I or Chris Dickinson and I together will be at NodeConf EU in Ireland this November to talk.

We will probably do a deep dive into what's going on technically with the API and the data model, and that'll be a lot of fun. May even have some answers on the security side by that point. So that'll be a lot of fun may even have some answers on the security side for that by that point so that'll be a fun go to ireland be at a beautiful resort in ireland and talk node or you can come join us in our discourse and our discord all of the disses you can find all of these things if you go to our github which is github.com entropic-dev and there's only one project in there well actually there are two projects in there now

Kat is making projects find us there and we have pointers there to our discourse and our discord as well as the code code is the least important thing right now come join with us and talk with us because we're in the talking phase Any plans to have entropic.dev redirect instead of showing this?

Oh yeah. Yeah. That's, that's actually a, that's, that's a joke by the way. It's like, what do you, if you go to registry.npmjs.org, you get a bunch of JSON, but we need a website. We don't have a website right now. We understand that there are a lot of people out there who are much better at writing websites than we are. Maybe you want to do that for us. Sweet. So there's lots of roles to fill.

Many, you know, a long-term plan intended for the betterment of the Node in your case and then JavaScript at large community, the commons of JavaScript, as you've said before, it was super interesting that, that your path with NPM, and then obviously your love for node and JavaScript and still being willing to put in the sweat, hours, tears, pain, whatever it might be. But not on the weekend. Into this. That's awesome. I work on the weekends. Don't talk, Chris. I just don't make decisions on the weekends.

Gotcha. That's right. And you don't tell anybody you're talking about you know whatever you're not learning anybody that you're working potentially right yeah but uh hey see thank you so much for taking the time to go through this with us i mean we're super fans we can't wait to have you back on uh six months or a year's time to catch up on Entropic. That'll be fascinating. Yeah. Cool. But listeners out there, if you want to get involved, we'll have links in the show notes, so make sure you follow those.

Also follow SiegeBot on Twitter and others so you can kind of keep up and pay attention. Siege, thank you. You're welcome. It was a pleasure being here. Thank you so much for having me. All right. Thank you so much for having me. influence more developers. Do us a favor and give us a rating or review in iTunes or Apple Podcasts. If you use Overcast, give us a star. If you tweet, tweet a link.

If you make lists of your favorite podcasts, include us in it. Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service, and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo, and our music is hosted by myself, Adam Stachowiak and Jared Santo, and our music is done by Breakmaster Cylinder. If you want to hear more episodes like this,

subscribe to our master feed at changelog.com slash master, or go into your podcast app and search for changelog master. You'll find it. Thank you for tuning in this week. We'll see you again soon. Well, hello there, listeners. How are you? This is Adam Stachowiak. If you haven't heard yet, we're launching a new show called Brain Science. It's a podcast for the curious. Are you curious? Because if so, we're exploring the inner workings of the human brain to understand things like behavior change, habit formation, mental health, and what it means to be human.

It's brain science applied, not just how does the brain work, but how do we apply what we know about the brain that can transform our lives? Learn more about the show and subscribe at changelog.com slash brain science. Until then, here's a preview of episode number two. We're talking about how we're all designed for relationships. I think about it like scaffolding, that as our kids grow, and it doesn't matter. I just always want people to have this sense of hope and optimism around, look, it's not over if you didn't get it in childhood or it didn't fully grow. Neuroplasticity is one of the most amazing and hope-filled things because we can continue

to build this and grow all throughout our lives. And so having another person participate in the development of our own mind, it's sort of helping build neural networks that say, hey, I totally understand that you're upset as a three-nager because you did not get ice cream and you think your world is now ending. But to actually, you can still empathize, but that doesn't mean you necessarily give them that desire, right? Because I don't want them to be conditioned, i.e. I don't want them to have the perpetual feedback that when they're upset, that they just get to have the ice cream that they want. Right. Let's also say we're using children as an example here because for the audience to empathize with us, that's our breeding ground for research basically.

I can give an example where my son, I can't recall the exact scenario, but there was a moment where I was like to my wife, I said, hey, it's not that he's misbehaving because we were both sort of like in this crazy mood with him and he wasn't behaving. And I was like, you know what? It's not that he's misbehaving. It's both sort of like in this crazy mood with him and he wasn't behaving and I was like you know what it's not that he's misbehaving it's just that he he can't right now he's just too far gone he's too tired he's too exhausted he's overstimulated and his brain is just not developed enough to really get that we're asking him to behave right and desiring and expecting him to but he's just not capable so moment, we both sort of just curled into ourselves and just cuddled him and just was just, you know, loving to him rather than like, why can't you get this? Come on, three-nager, do this. You know what I mean? Like, you know, so our breeding ground and research is our children. Right, exactly. And, you know, I, in my line of work, I mean, I will see the people where this sense of attachment and connection

and feedback loop didn't go so well. And so they've learned, I always say, it's sort of like they jerry-rig things. Like they learned how to best function in their lives as well as they could. But we know this, whenever we jerry-rig something and don't actually fix it the way it was supposed to be, what happens? It breaks down.

Well, if you like what you hear, you should go to changelog.com slash brain science. The show is not out yet, so don't get too excited. But you can subscribe and be notified as soon as the show launches. Once again, changelog.com slash brain science. you you