Securing npm is table stakes (Interview)

31:41my only sense is that it's fairly small. Yeah, I would say demystify the black box of staffing just so the community knows. Is it being staffed? Is it understaffed? Is it, you know, like, I don't know. I mean, if we're relying on this registry and ecosystem, at least be clear on what is, what's not clear with that part of it. Like, tell us. Yeah. I think last year I opened up an issue on NPM. And maybe by the end of the year, it got a response. Not even a, oh, this is a good idea, this is a bad idea. Just a like, oh, hey, that's interesting. And that was a good indicator to me that it was probably not resourced appropriately.

32:33I mean, especially when like PMPM came out after one of the attacks, it was like, okay, we're not going to let people install any package that's like newer than seven days old or something. And the hopes that that would prevent people from like rapidly downloading compromised packages before they could be caught and removed. and that PNPM moved faster than NPM, I think was a bit of a wake-up call for me. Now they're doing it on the client side. So how big of an effect does that have? I would guess like not huge, but they were trying to do something that they seemed like might help and was within their power to do so, which I applaud them for.

33:19And like with NPM, It just felt a little like, okay, these were some stuff that we were planning on doing anyway, and we're just going to roll those out. And yeah, we'll see what happens. Yeah. Let me ask a question that's maybe been asked, but maybe not directly like this. Like, is it still prudent to even use NPM, given like the fact that you put an issue out there and it took that long to get a response? or just the seemingly lack of speed or initiative on the nuances? Like, I don't think security is a nuance, but you'd mentioned that they're a nuisance, which is a close N-word to that. You know, what's going on?

34:00I mean, should we keep using EMPM? Are there alternatives? Should we create an alternative? If it was a possibility, what would that organization look like? Do you have any insights there? Yeah, so I think the short answer is that, the inertia behind NPM is so great that it's very difficult to extricate ourselves from it at this point. Any JavaScript package that you want to install, you look at the readme, it says install from NPM. People don't even know what else to do besides go to NPM to look for these packages. And Dino started an alternative package manager called JSR, which I actually had high hopes for because I think that they put the type of thought into security, instability, and stuff like that up front that NPM has kind of been adding on as it goes.

35:06Just like right from the start, like not allowing package name squatting, reserving certain package scopes that could be confusing to people. Like when I went to go sign up for JSR and I tried to grab the ESLint scope because my initial reaction was like, oh God, here's another place that I need to grab all the usernames on. And ESLint had been reserved. You couldn't actually go on the website and just say like, okay, I want the ESLint scope. You actually had to apply for it and prove that you're the right person to be handling that scope. And they approved me really quickly because they knew who I was and that I was involved with ESLint.

35:51So I was able to get that. They had trusted publishing right from the start, or else you have to use two-factor authentication to publish locally. No pre-install or post-install scripts. There's just a lot that was really good about JSR. And it basically suffered the same fate as NPM, just on a much faster timeline, which was basically, you know, there was a lot of interest early on, a lot of activity, a lot of iteration. Like I was filing issues on the JSR GitHub repo. They were getting answered sometime within hours and things just getting fixed and pushed out. But eventually that timeline started expanding to the point where I wasn't getting any responses anymore.

36:47Even to bug reports, I was finally able to get one response when a new version of Dino was pushed out and that broke the JSR command line tool. I was finally able to get a response from them to get that fixed fairly quickly. They had announced that it was going to be an open governance registry for JavaScript, and they had formed a committee that had people from NPM and Dino and I think OpenJS Foundation and Vault, and that just kind of went nowhere. There hasn't been any updates since then. Like JSR is still running, but as far as I can tell, it's mostly an abandoned project at this point. And there's just some of the Dino diehards like really like to use it, but it doesn't seem like it's ever going to be a real competition for NPM registry.

37:53What was the downside to pre and post install hooks? I get what they do, but what is the downside? You said there's none on JSR. Is that something you agree with? Is there a way to do it safely? What are your thoughts? So pre-install and post-install scripts on NPM are designed to let you run additional commands after install in order for a package to work. and npm was based on a package manager at yahoo where i worked for five years called yinst and yinst was the way that all of the machines were built inside of yahoo and these pre-install and post-install scripts could run in yinst to help you set things up after you got resources installed.

38:51And that turned out to be pretty helpful to be able to set up machines. That was copied over into NPM with the same idea. The difference though is that Yinst was an internal system. So there was implicit trust with all of the packages that were published in Yinst. For NPM being a public system, you don't have that implicit trust. And I think that this is probably something Isaac would have rethought when he was designing the system, knowing what he knows now. But the NPM ecosystem kind of became dependent on those scripts because of the ability to publish native NPM packages that were actually compiled, like C, C++ packages, packages, where you can't publish the compiled artifact itself because it has to be compiled individually for each machine.

39:56And so these post-install scripts are what allow these native modules to be used and installed on any machine because it just downloads the source code. And then on your machine, it compiles it into the form that can be used, and then you can just run it. And there are a lot of packages that use that now because every once in a while, somebody will say like, well, we'll just ban pre-install and post-install packages. But if you do that, you kill off a non-trivial portion of packages on NPM that people are relying on. And the other thing about that is you can actually say NPM install dash dash ignore scripts and it won't run any of those scripts.

40:40And that's a great solution unless you end up with one of those packages in your dependency tree that needs to be compiled and you might not even be aware of it. And so just disabling that or just always saying like, don't run those scripts, that also has the effect of potentially breaking people's experiences in ways that they didn't anticipate. And if you've ever had any trouble with a deep dependency that needs to be compiled that wasn't compiling, it is really difficult to debug. And so I think any package manager that would start from scratch or any registry that would start from scratch now would be wise to not even have this concept of pre-install and post-install scripts and just say, you know, we're not dealing with compiled packages at all, which is what JSR does.

41:41But if you want to enable compiled packages, it's kind of the necessary evil you have to accept. Do you mean the post-install or pre-install is going to install a compiled binary and that's the threat is that it's compiled and you can't see into it? No. So the threat is that the pre-install and post-install can run anything. Yeah, exactly. Like it might not compile anything. And this is what happened last year was these packages would download and install Trufflehog, which is a secret scanner, and just execute it and find all the secrets and tokens on your computer when you downloaded it. It's one of those situations that like Dino was trying to prevent with its permission system.

42:30Like, okay, you have an NPM package. Should it be able to call back out to the internet for some reason by default? That kind of seems like a bad idea. And so the permission system in Dino was built so that anytime a package was trying to do something that was unanticipated, reach out to the network, read something on the file system, you would have to opt into that behavior. And I know there's been some experiments with that on NPM. I don't think that those permissions actually apply to pre and post install scripts, if I remember correctly. But that is something that they could look at as well of just like, OK, maybe pre install post install scripts are not allowed to just willy nilly go out to the Internet.

43:24maybe they need to get opt-in permission from the user in order to do that first. I imagine that would be a little bit more complicated than I'm making it sound. Yeah, it always is. But it's another option around those. I mean, my preferred option, which I talked about in the post, is just say, hey, if a package previously did not have a pre-install or a post-install script, and then it adds one, don't allow it to be a patch or a minor version upgrade. Force it to be a major version upgrade. Because for most people, that will not be installed automatically, as the minor and the patch versions are.

44:16So if you just said, oh, hold on. For this 1.x branch of this package, you never had a post-install script before. And now you do? Sorry, you've got to bump that to 2.0.0 before we're going to publish it for you. And I think that that alone would slow down attackers tremendously. Yeah. Because people will just not automatically be downloading those packages anymore. And hopefully someone, like maybe it's Socket or maybe it's NPM themselves, will then have the time to identify that as malicious and get it pulled down before it is downloaded millions of times. That's awesome to suggest. Like if it's, I like your idea, of course, as well.

45:04I think a major version bump is going to slow it down. It's not going to prevent publishing. It still allows movement. So if it's your package, you can still move along. But anyone else has to sort of adopt that based upon their semver. But what if you were constantly scanning any package or project that had a pre or post install script? anytime those were added or included and forevermore, that one gets special attention, special scrutiny on that script. If you're base 64ing something, if you're doing something nefarious, if you're making a network call, if you're doing an install of any sort, it's looked at and has to be scanned and verified like a security verification so that at least you have some check and balance.

45:54Yeah, I like that idea a lot. I think that for too long, we've just been saying like, oh, you know, they go and add a post and sell script and gosh, like that's terrible. But yeah, it's great. If it's done wisely. Yeah, I like the idea a lot. But there are all kinds of things that I think can be done with these packages to just make sure that they're safe. And yeah, I love that idea of just providing extra scrutiny to those. I mean, it could be the case that you even need a waiting period if you're changing or adding post-install scripts. And this is the thing that I found a bit frustrating is I feel like there are some low-hanging fruit options that are out there that would actually not be very resource intensive to implement on NPM, which is why my suggestion of just requiring a major version bump was one of the things that I put out there.

47:02I don't think it's super complicated to implement, but let's just start doing something during the publish process instead of just relying on people discovering it after something has been published and then downloaded a bunch of times. I mean, you can even introduce, I mean, you got verified publishing, why not verified publishers? If you're going to give somebody the PETA factor to make a token renewable in some way, shape, or form, or a just-in-time credential that makes sense for the maintainer, why not only give certain types of ability, like the pre and post install, for example? If it's such a powerful thing, anyone who wants to use that, in addition to that, verify all maintainers or the organization or the maintainer, the kind of core maintainer, have some sort of connection to one real person inside of that package, project, whatever.

48:03And if you can't do that, then I'm sorry, you don't get that very special ability for this trusted network or should be trusted network. It takes people, though, right? A lot of software can automate a lot of that, really. I mean, you can do a lot with that process. Yeah, I think that the resources for that would probably be fairly high and probably more than it could get in the short term. Let me say that I think if you're GitHub, though, right, if this is GitHub, which it is, then you have GitHub at your ready. So for those publishers, one easy way you can do it or one easier way is you can leverage the already need for securing GitHub, which is that project or that person has to use GitHub auth.

48:48So you have a one person or somebody there, like you can leverage at least GitHub auth and all the security put behind GitHub itself to have one verified member or at least one member in the party. Gotcha. Yeah, yeah. Interesting. I think potentially an easier solution, which is a little bit heavy handed, is you could just say, okay, okay, all packages that have pre - and post-install scripts right now, you can keep doing it. Anybody else, you don't get to do it. We're basically cutting that off now and saying that, you know, we're grandfathering in all those old packages so they will continue to work, but new packages, sorry, you're out of luck.

49:30We're just not going to do it for you. You need to figure out a different way to distribute stuff. And you can just tell your users a couple steps before and after, right? I mean, that's the easiest method that you could do is just tell your users, you got to do something before and do something after to make this work right. Yeah. It's unfortunate. Yeah, just go ahead and write your own shell script. Or here's the shell script, download it, and you need to run this, and then after that, it's fine. Right. Yeah. But again, I feel like there are some lightweight solutions that could be done instead of putting more responsibility on maintainers every time there's an attack.

50:20Well, friends, this episode is brought to you by Squarespace. I love Squarespace. I'm a user of Squarespace. And Squarespace is an awesome all-in-one platform where you can stand up a professional site, offer paid services, get paid, the whole thing without writing a single line of code or debugging CSS. They've even got Blueprint AI now, which takes basic info about what you're building and generates a fully custom site with actual design recommendations. Not a template you have to fight with, but a starting point that already looks like you thought about how it should look. And for the data nerds out there, I know you, that's me too.

50:56Built-in analytics are cool. See your traffic, see your revenue, see your bookings, see your sales. Figure out where to focus all from one single dashboard. No third-party apps, no GDPR headaches. Just there for you. And whether you're launching a side project, selling a course, or finally replacing that under-construction webpage you've been kicking around, Squarespace handles the website part so you can focus on the thing you actually want to build and the content you want to create. So head to squarespace.com slash changelog for a free trial. And when you're ready to launch, use our offer code changelog to save 10 % off your first purchase of a website or a domain.

51:35Once again, squarespace.com slash changelog. I'm saddened by your report about JSR. I had high hopes for it. It seemed like, like you said, it was off to a good start. and I wonder what happened there. Like what, why? But what about Volt? You mentioned Volt. That's another one that's been up and coming from longtime JS ecosystem people, Darcy Clark and friends, and then backed by a lot of people who have been around the ecosystem forever and have benefited and had issues with NPM over the years. Has Volt been manifest? Is it a thing? Is it still becoming a thing? Is it a viable option? Because eventually we can't make GitHub do anything.

52:24And so if they're not going to do anything, we can continue to tell them they should and try to convince them. But having some other alternative, which I was hoping JSR would become, would be at least somewhere you could put your efforts into and say, let's all do this instead. And it would be grassroots and it would be a lot of work. And I understand there's billions of things being downloaded every month off of NPM. But if the package maintainers had somewhere to point people and say, you know what, for new versions of ESLint, you got to go here. put it in your post install script this is an old version of ESLint for the new version I'm only publishing on this other platform go read my blog for the reasons if you can get the top 100 packages maintainers to do that you could probably make a dent but we have to have somewhere to go and if JSR is not going to be it is Volt an alternative?

53:18what do you know about that one? Volt as far as I know was not in the business of providing a registry It was more around tooling around NPM. Like a new client that does fancier stuff? Yeah, basically new client does fancier stuff, more secure, etc. I haven't seen anything notable come out of that. In fact, I'm starting to think this might be me. I was trying out one of the Vault tools, and I went and I found a problem and I opened an issue on the GitHub repo. And again, it just sat there for months, just no response at all until very, very late. I mean, again, maybe by the end of the year, somebody was like, oh, this is fixed in the latest version.

54:13It's just, I don't know what's happening over there. and it just, I don't think that JavaScript registries are good business fundamentally. And I think that, you know, NPM Inc figured that out and glad for them that they were able to get out and get the registry into a place where it would at least be up and running. I feel like JSR basically the same thing happened where JSR was being funded primarily through Dino, even though they wanted to make it more of a community thing. But fundamentally, they came up with it, they were running it, they had it on their infrastructure. But they are a startup, they need to figure out ways to make money.

55:06And JSR was just a way to spend money. I mean, it's nice. It's a nice gift to the ecosystem, but they still need to figure out a way to turn a profit to pay back investors. So the chances I think that JSR is going to grow up into something else is probably pretty slim. And like you, I was pretty excited about it. I think they got a lot of stuff right. But one of the challenges of, again, like having a a competitor to NPM is like, number one, you can't actually do quote unquote binaries like ESLint on JSR. You can't just say like JSR install ESLint and then just run ESLint. It doesn't work that way.

55:52And then two, any alternative to NPM needs to be compatible with NPM. because unless you're able to use all of the packages just on that new registry, you're going to have to mix and match between NPM and that new registry. Sure. And that's also something that JSR just did not get right. If you try to use JSR packages in with NPM packages in a package that you want to publish, just straight up doesn't work. because we tried to do this with one of our ESLine packages because the nice thing about JSR is Dino published a bunch of standard library type packages on there, and they're really good. And so we wanted to use one in one of our packages, and it ended up being such a pain that we just copied the source code from the JSR package into our repo so we could package it and publish it up onto NPM.

56:57So that story was just not there at all. It was okay if you were just building up an application that you were not going to be publishing to NPM. You're just going to be deploying. That worked okay. But then going and publishing that back to NPM just did not work at all. So we're stuck. Yeah. I don't know. I got an idea. All right, let's hear it. What if, and I know Bunn is not a registry, but what if Bunn is very fast? What if by the sheer weight of Anthropic behind Bunn now, saw this as a blind spot and an opportunity? They obviously invested in Bunn anyways. I'm not sure of the implications behind it.

57:43There's a lot of speculation, of course. But with the sheer weight they have with just the weight, their deep coffers, their money, their et cetera. What if they can recreate what NPM is? They're already NPM compatible. What if they could redo, but better with maybe AI, native, provenance, et cetera, anomaly detection, take your advice, Nicholas, et cetera. Like what if they took it on and they said, you know what, we're gonna do this. could they sway all the maintainers away from NPM by the sheer weight of who they are right now? I don't think so. Okay. And part of the reason is it seems like a lot of developers are very skeptical of AI companies and providing data that can be used to train AIs.

58:45There was a lot in 2025 of people being like, oh, look at this terms of service. They've now included that your data can be used to train AIs. And I feel like if Anthropic were to start a registry, that would be like day one, people being like, wait a second. Am I just feeding Anthropic my copyrighted material so it can continue to train Claude? I think that would be a major barrier to that. I think that's a fair point, yeah. What about the users? All they need to do is convince Claude to use their registry, and then the rest of us are just riding Claude's back anyway at this point, aren't we?

59:28Yeah, well, I think it would be interesting if they started having Claude say, no, you've got to use the Anthropic Official Registry. but I could also imagine you know similar upset developers user backlash against Claude now yeah totally yeah and and also just you know from an operational standpoint I don't know that Anthropic has the operational experience to be able to keep a high volume registry up and running at this point I mean that that's something that I mean there were really smart people Explain that. What does it take to do that? I would be lying if I said I knew exactly. Okay, so you're speculating.

1:00:12Well, no, because I knew a bunch of the people who started NPM Inc. We worked together at Yahoo. Really, really smart people coming from Yahoo that had really, really good operational systems and being able to pull people from that ecosystem in to help build up NPM. I mean, people forget now, but the NPM registry used to go down a lot. in the early days. And even after they got their funding, like it took a while before it reached stability. And there's, you know, a lot of, again, I'm not going to lie and say I know how to keep a registry online myself, because I've always been more of a front-end developer than a back-end developer.

1:00:57But just, you know, off the top of my head, how many like read replicas that you need and where you need them. What sort of traffic are you getting from publishing and how frequently? And how do you cache effectively to make sure that CI systems are up to date and also not unstable? There's a lot that goes into managing the registry. I would say it's probably kind of similar to running YouTube in a way. Because YouTube, before they got bought by Google, This was also a problem of just managing the scale that was going on. And part of why Google was an ideal destination for YouTube was they had the infrastructure and the operational knowledge in order to keep that site up and running, even with all of the traffic and all the bandwidth that it eats up every day.

1:01:51and again if you look at Claude how frequently does Claude go down because they run into bandwidth issues it still is more frequently than you'd like to admit they're getting better but it still happens so you're not down with you don't think the world will be down with Anthropic slash BUN registry NPM compatible anomaly detection AI native et cetera, et cetera, et cetera? I don't personally. I think that for a registry to have a chance to compete with NPM, I think it has to come from a company or a person starting a company that is already trusted by the community. And that's why I thought JSR had a real shot.

1:02:44because coming out of Dino, coming from Ryan Dahl, already had a lot of trust in the community and always presenting himself as wanting to do the right thing for the JavaScript ecosystem. I thought JSR really had that shot. And to see it kind of fade away has been really disappointing. Well, I think JSR was open source and supposed to be, like you said, governed open. So there's opportunity for somebody else to pick up the mantle and run with it if there's no movement from the Dino team any further. If we look around all these different package ecosystems, like how do they all do it? Or is NPM at such scale that it doesn't really matter?

1:03:33How RubyGems does it? How Perl continues to do it? I know Perl has like CPAN, which is mirrored around the world on different servers. Rust, I think, is the Rust Foundation but it's way smaller in terms of how many crates there are compared to NPM packages Java, I think Java isn't Maven run by a single entity that sells commercial services are these all just like the scale isn't the same so it doesn't really matter how they're doing it successfully or what are your thoughts on that? Yeah, I think that's exactly it I think it's a scaling problem because there were package managers around before NPM existed.

1:04:17And RubyGems. So Crates came around afterwards and was kind of inspired by NPM, but they don't have anywhere near the scale. No, but what about PyPy, for instance? Python has huge scale. Yeah, I don't know that much about the Python ecosystem. I mean, neither one knows the Python foundation. Python what foundation? Yeah, it seems to me these other languages usually follow a predictable pattern of, at some point, some developer was like, we need a package manager. They made one, people started using it. They started a foundation or nonprofit or something that just kind of gets donations to keep it up and running.

1:05:04And I think that that's where the JavaScript story kind of went sideways of like, you know, it was started as, you know, a side project, right? Isaac Schluter. And trying to find a home for that, he started NPM Inc., a for-profit business. And I think that that was probably the point at which the divergence from other languages hurt the long-term plan for the registry. Because again, once you become a startup, you take VC, you're on the hook for making money, you're figuring out how. And then if you can't figure out how, they want you to sell to try to get as much money as possible, get it back.

1:05:55Maybe in some ideal world, the NPM registry would have ended up, instead of at a for-profit company in, at the time, the jQuery Foundation, which went on to become the OpenJS Foundation. I think that in an ideal world, that is probably what would have happened. Although I don't know, ESLint is part of the OpenJS Foundation, so I do have some insight into how the foundation works. And I also don't know how the foundation would have been able to afford to keep the registry running probably the same way any foundation does is just donations they'd have to just beat the streets for bigger donations from funded companies that really want javascript to win like google for instance when the web wins google wins at least historically yep and so they would be probably a sponsor and it would just be like let's just break even and continue to break even and pay these bandwidth costs and aws costs or whatever it takes to run the thing and that's how they're all running but like you said the scale is bigger than them oh i did confirm python software foundation i'm not sure what i was talking about with python science foundation but uh the psf has oversight and donation sponsorships aws google datadog provide 10 000 fastly provides 10 000 per month hosting that's just reading this from a lm lookup so fact check that but it makes sense that like that's that's the way it's working it probably doesn't always work great there's i'm sure there's push and pull on the direction and there's quite drama around all the things but like that's kind of how community run important things are maintained and continue but they don't have the profit motive motive behind them and so i think you're right on track there with like turning it into a business was probably a long-term death now and here we are and had it gone to the open js foundation versus to github perhaps that would have killed it off for good or perhaps it would have given it a better chance i don't know obviously we can't do the uh parallel histories but seems like it's not in it's an okay place as it continues to exist it operates pretty well but it's so important now that the stakes have been you know, ratchet it up on the security side.

1:08:18And there are more things that need to be done. And there's really not much of incentive besides, like you said, some pending nuclear moment of terrible press and like user backlash and all these things, a huge security breach, perhaps legal action that would actually motivate them to really go after it. Or just the cool factor, man, just the cool factor of implementing anomaly detection and like these verified users. And like, that would be, that'd be a fun job you know to to save potentially i mean it's not a save because i mean you're going to keep using it but you're kind of using it begrudgingly you're not exactly thrilled that your npm is not as secure as it should be scared yeah you got it's your only option it's like the road to there is paid with potholes and thieves and you know people with weapons and stuff trying to take me out it's like that's not a good road that's an exaggeration of course but you've only got the one road to go down and not much choice.

1:09:16And even if there was choice, based on what you've said, Nicholas, is that even with that choice, there might not be a mass exodus away from NPM to something else just because of its gravity. I mean, the packages behind NPM is 3. I mean, if this math is correct, as of late 2005, 3.1 million packages. This is according to Wikipedia. So Wikipedia is better. I mean, that's a lot of packages. That's a lot of people to move. I mean, you don't want to swap out your just-in-time credentials, let alone move to something else with maybe different tooling, maybe better tooling. Who knows? Yeah, they'd have to have a good reason.

1:09:56Yeah. And security rarely moves people very fast or far. It might this community, though. I mean, if there's a lot of fear of its uncertainty because of security in particular. It seems like the profit incentive could be there, though. And when you see companies like Vault and companies like Socket springing up, basically because of these problems, it seems like there's some possibility there of GitHub just saying, look, there are companies that are willing to pay for these types of services. Maybe we can offer those services and use that to offset some of the costs of implementing these changes on NPM.

1:10:45Just say, hey, if you want the fastest notification of potential security threats or what have you, you sign up for the service, we're going to use that money, funnel it into the NPM team and start funding it that way. I feel like there's a lack of creativity in the solutions at this point because there's a whole world of possibilities out there to be able to turn NPM from just like a cost sink into something that could maybe break even or maybe at least just not be the albatross that you're dealing with constantly. I think it's wishful thinking at this point that GitHub would willingly spin off NPM into a foundation.

1:11:38I mean, they could certainly do it. It wouldn't hurt them financially to just say, hey, you know what? We want to start a foundation or give it to the OpenJS Foundation. as part of that. We've come to an agreement with Google and Meta and whoever else that we're going to jointly fund registry operations by donations to the OpenJS Foundation. The OpenJS Foundation will be in charge of hiring engineers to work on it based on that. Maybe that's an off ramp for them. I don't know if they'd be open to that. But there's a lot more options out there than I think are being discussed or even considered at this point.

1:12:22For sure. For sure. Let me take this as an opportunity to invite anybody who has insight into the underpinnings, the behind the scenes of NPM. Open invite. Come on. Let's talk about whatever you want to talk about. Let's even spitball some ideas live here on the podcast. Maybe we even spin up a cloud code session and whip up a new feature for you. That's what I'm trying to say. We'll get some action here. I was going to say, get Nicholas hired on there to come in and right the ship, you know, bring him in. He's got good ideas. Would you do that, Nicholas? Hey, happy to, if I can help. There you go.

1:12:59I'm out here willing to help. Yeah, what is your day-to-day look like? What are you up to? Well, I'm, at the moment, independent software engineer. So I just take on contracting, consulting work. I work on ESLint as I'm able, and I do coaching for software engineers, just helping people when they kind of reach those upper levels of the IC track, tech lead, staff engineer, principal engineer, which I did in a former life. just helping people kind of navigate companies and leadership and communication and politics and all the things. Is that one-on-one? Is it a small group? How does that work out?

1:13:47Yeah, it's one-on-one. Just do remote Zoom calls and yeah, just talk about the challenges people are having and give some tools and suggestions of how to deal with situations that might come up. Because anybody who became a tech lead, they'll know that basically when you become a tech lead, they say, hey, congratulations, you're a tech lead. Go do tech leading stuff and don't really tell you what that entails. So that's when I come in and just help people figure out how to work effectively in those roles and manage your manager and get stuff done. How likely is it that person is already employed and a tech lead?

1:14:32And they're just like, hey, now that I got this role, can I use some discretionary spending for some leveling up? Yeah, that's 100 % of the people that I work with are people who are already employed at a company. A lot of times a company will even pay for the coaching through their professional development expensing. and sometimes the managers reach out to me and just say, hey, I have this person that I'm working with that I really like to get them some coaching either because they just don't have more senior people at the company. Like I work with a lot of startups that just don't have those really senior people that can help mentor people or sometimes the really senior people are just too busy, don't actually have the time to sit down and do that sort of coaching and mentoring.

1:15:24Sometimes it's the engineers themselves who reach out. And I always encourage them to talk to the manager to see if they have professional development funding that might be able to pay for it too. Because if the company is going to benefit from you becoming a better employee, then it seems only fair that they should pay for it too. Well, how can they reach out to you? What's the best way to say, hey, Nicholas, I need some help. Yep. So you can drop by my website. It's a human who codes.com slash coaching. And that'll give you all the information about like, what I do, how it works, and see some testimonials.

1:16:04And there's a button for you to apply and fill out a form that just tells me about you and I can figure out if it would be a good fit. because I'm one of those people who I want to make sure I can help you with the situation that you're dealing with. And if not, then I'll try to help you find somebody who can. And how should GitHub contact you to come help fix NPM security? The same way. Slash coaching, yo. Pay the bills. The folks at GitHub, I'm in a Slack with them already so they can reach out at any time. DM near you. All right, GitHub, the tables are turned back to you. Come on the pod. Let's talk about NPM or reach out to Nicholas, whichever you prefer.

1:16:47That's your next move. There you go. Let's make it happen. Nicholas, anything else on your mind? Anything else you want to talk about? It could be on topic, off topic regarding what's going on in software world or anything before we let you go. Yeah, I just wanted to say about AI. I don't think it's hype. I still see people out there saying, oh, this is just a hype train. I mean, it's not, like, personally myself, I have seen, like, a 10x productivity improvement in the amount of code that I can now generate versus writing. And especially when you're, like, jumping around from project to project, saving me a ton of time.

1:17:32Like, there's, it would be really difficult for me to be productive writing code for ESLint right now. but with AI like hey you know I know what I need to get done and I can describe it fairly quickly and just kind of let AI go off and do it so if you're one of the stragglers out there who's still not embracing AI in your day to day like 2026 is the year you gotta start doing it now 2026 is the year how about resources for maintainers who have to maintain npm modules packages whatever do you have any resources for them any any advice for them maybe they're not paying attention as much as they should to the details where could they go to become leveled up yeah that is a good question that i don't know i have an answer to i love to see that resource exists because i feel like that's just like a natural thing too because i mean np i don't even i don't know i don't know npm's docs but i would imagine like that's the need there but they're already not doing the other things as well as they could so let's just do those things better.

1:18:38But the docs can be, you know, maintainers out there who've been down the road, have the bloody knuckles and the scars to prove it and the backward facing desire for everyone else following them or following NPM or the ecosystem to be leveled up in some way, shape or form. I'd love to see that happen. So if you're out there doing something like that, you got that resource or that's your next big AI generated things. I mean, that really could be something you can AI generate over a weekend. You can invent a hundred new docs that were never there with a few prompts and your new buddy, Ralph and Claude, just circling around, whatever, get it done.

1:19:17If I'm remembering correctly, I think OpenJS Foundation might have put out something along these lines, just not 100 % sure. Very cool. Well, Nicholas, thank you for coming on the pod, sharing your time again with us back here on the changelog. And thank you so much for your angst in sharing that and just pushing the needle on what could be a secure NPM coming to you sometime soon. Yeah, thanks for having me.

1:19:51All right, that's your changelog interview for this week. Thanks for riding along with us. What do you think about NPM? Is it being neglected? Is there a way to save it? Are we being overly dramatic? Let us know in the comments. Links in the show notes. Thanks again to our partners at Fly.io, to Breakmaster Cylinder for the beats, and to you for listening. We appreciate you more than you know. That's it. This one's done. But on Friday, come on back. We're talking Clodbot slash Moltbot, personal software and the death of software as a service. Talk to you then.

1:20:38Thank you.

1:21:07Game on!