 But before I get started a little bit about myself, I'm IBM's community lead for Node.js. What that means is I get to spend a lot of time in the community, I'm on the technical steering committee and active in a good number of the teams and working groups, and in particular the package maintenance team, which is doing a lot of the work that I'm going to talk to you about today. Also means I get to work with a lot of great teams within IBM doing interesting things like keeping Node.js running on our platforms, S390, PowerPC, as well as working to make sure our cloud deployment targets are a great place to deploy Node.js as well. I also want to thank Dominikus, who helped put together the first version of this presentation. We gave a very similar one at Node.conf for you as well, so I want to give him the credit for helping me put this together. Unfortunately for you, today you only have me, so we'll do what we can. Before we get started, a little bit to let you know what we're going to talk about. First of all, we're going to talk about some problems that we've seen and how do we think we can make things better. Next we'll talk about concretely what is the team doing, and hopefully I'll have you really excited about the whole area problem, what you might be able to do to help out, so I end up with a call to action hoping to get more people involved to help us figure this all out because there's no really easy answers. Looking at the start, the problem is that we've seen a real explosive growth in the use of Node.js, both for personal use but also within businesses, and that's really because of all the value that's provided by modules, and in fact, often a number of key modules within the ecosystem, there's like, I've lost count, it's like 900,000 every time you do the chart there's more, but there's a smaller subset which get used and reused very, very heavily, and so we have a dependency on those key map modules because of the value they're providing to the overall ecosystem. What that results in though, is a desire for basic maintenance, if I'm deploying an application that my business depends on, I would really like some basic maintenance, for example, when a new version of Node comes out, I'd like to be able to know that it's going to be upgraded to support that version of Node, if there's vulnerabilities reported against the module or its dependencies, I'd like to see those get fixed. Unfortunately, at the same time, maintainers are struggling to keep up. It's easily the case where somebody created a module, it was really for their own use, they did it on the weekend, and now it's got millions and millions of downloads. So it's not something that they wrote saying, hey, I'm going to turn this into a business or a living, and so as sort of the expectation grows, it's hard to keep up with that because that's not really part of their business plan and maybe there just wasn't even a business plan. At the same time sort of compounding this is that there's some things that have happened like the event stream issue that happened about a year ago where people are starting to think more and worry more about their dependency trees, understanding that I've installed this module with, that brings a whole bunch of other ones, and what does that mean in terms of the sort of risk management that I should be doing? So again, that's sort of just adding to the overall picture. And then the final sort of addition to this is that there's kind of, there's a lack of communication channels. We've seen some recent efforts where maintainers of some packages were trying to reach out to their end users, just say, hey, I could use some funding. And so there's not necessarily well established communication channels between the package maintainers and the users of those modules so that they can one set good expectations and communicate to figure out how to do different things. If you want to read a little bit more in detail on sort of our thoughts on the issue, there's a link at the bottom there and I will send out links to the overall presentation at the end so that you can read up on those if you want to. The other thing that we realized looking at the issue is it's not a one answer fits everybody. So for example, some module package maintainers, they want to keep doing it themselves. They don't necessarily want a bunch of new maintainers to come and help them out. They're happy maintaining the module themselves, but they actually would like support to be able to do that. So whether it's funding or support of some other way so that they can continue to maintain this module. So it's not, hey, we want to grow it. It's like, hey, I want to keep doing it, but help me do that. The next set of maintainers actually want to grow contribution. They say, oh, I don't want to be the one person who's maintaining this. I want to grow it into a bigger thing with multiple maintainers and sort of spread the load. So that's kind of another viewpoint. And then there's some who just want to move on. And as we saw with the event screen incident, when you pass on a package, it's important to do that responsibly and to sort of consider the ecosystem. And the maintainers want to do that. So there's those who want to move on, but move on in a responsible way. So the people who are depending on their packages still have a good path forward. So what are the things we think we can do to actually improve the overall situation? The first one is to try and reduce those mismatch expectations. In my personal experience, I find that a lot of the time when there's friction or disagreement or people getting upset, it's because we had different expectations. I expected that I just did this for fun and if people wanted to use it, great. But the risk is on them. On the other hand, I built this into my money making application. And I'm under a lot of stress if it doesn't work properly. And if those two people have different expectations just because it wasn't clearly communicated, that can easily end up being a source of friction. So one of the things we can do, and I'll talk about later on as we go through ways of at least setting those expectations and then helping consumers understand what those expectations are so that we can reduce the mismatch expectations. This is really one form of the larger problem of trying to build closer communication and collaboration. So try and build it between the consumers and the maintainers, as we just were talking about. Also between the maintainers though, because part of the struggle is how do I keep up with some of these, if I want to meet the expectations for basic maintenance, how do I do that as easily and effectively? And by having collaboration between the maintainers, we can come up with best practices, tools to make that easier. And of course, because we know that when you bring more people, more thoughts, more different views coming from different perspectives, you can come up with a better answer. Really, I say everybody else as well, because even those who aren't directly involved may come with it to the problem with a different perspective that really helps us see the, oh, wait a sec, if we just don't do what we're already doing, maybe we've got a better way to do it. The next one is trying to make it, concretely, make it easier to maintain packages. So let's look at what tools we can build. Let's figure out processes that work, so work on that side. So concrete implementations of things that will make it easier. And then last one is promoting responsible and sustainable consumption. So this is actually working to say, if you're using the modules, it's important, not just because it's the right thing to do, but it's important. If I run a business and my application depends on all these modules, it's risk management for me to actually understand what they are, to understand whether there's paid support, no paid support, what the expectation that the maintainer has set. Like, are they going to say, well, sorry, you're on your own when I go talk to them? Or are they going to say, oh, yes, I'm totally willing to help you? It's part of my risk management to understand that and basically be responsible about what I'm consuming. So promoting that responsible and sustainable consumption by helping people understand how that affects them, as well as provide the past for them to provide support back. So once you realize, wait a sec, I want to help and manage the risk, how do I provide funding to people who want funding? How do I get involved in projects that want to grow the collaborative? Or how do I even take over a module if it's important to me but the maintainer no longer wants to do that? So I'm promoting that responsible and sustainable consumption. So about a year ago, we started the package maintenance team within the Node.js project and sort of a little bit of history is we started by thinking about what we call module LTS. If you use Node, you're probably familiar with the Node LTS cycle and process and we were deeply involved in helping to put that together and implement it within Node Core. And we found that that has really resonated with people and they're very happy with it. So we wanted to say, what if you extended that concept to modules? We think that would be a good thing. And we had some ideas about how you would tie the LTS for a module to the LTS lifecycle of a Node application so that people who have applications and need to upgrade, it's a more planned and coordinated thing. So we started to talking to people in the community about that about a year ago. It was at Node Summit, it's about a year and a quarter. And what we found is we ran into the discussion of this bigger problem, or wait a sec, maintainers are just having a hard time keeping up. So we figured out we needed to tackle the larger problem before we could sort of move on to that specific issue. That was also about the same time that the event stream was in the press and being discussed. So we ended up with a lot of interested people joining the module LTS, it's not the module LTS, joining the package maintenance team. You'll see there's a huge list of people as is often the case in open source. We have a much smaller active group, so don't let that scare you off because we still have more work than we can possibly do with the active people within the group itself. We do have a good representation though from across the different areas. We have people using the modules, we have package maintainers, we have Node.js collaborators, because of course the module ecosystem is really important to the success of Node itself. So we have a number of collaborators. We have people from NPM, which is good, because they're one of the primary delivery vehicles. And again, I'll throw it there, maybe it should be you if this all makes sense to you. And fundamentally what it is, is a place to work together. We don't have the answer, all the answers, but it's a place to get together, talk about them, share processes, figure out what works, and hopefully make some, we're not gonna solve this today, tomorrow, but let's make some progress in the right direction. So concretely what we're doing is we're doing some work to understand the state of the ecosystem. So looking at some of the data to kind of understand where we might go. We're working on what we call support info, which is additional metadata that we think will help close the gap in expectations. And hopefully like we've mentioned on licenses, help consumers understand their dependence and sort of work with it. We're also working on best practices, developing patterns of engagement. So I always thought if I had a hundred developers and said, go help this project, without a little structure, that's actually probably gonna be a bad thing for the maintainers, right? We're gonna have like a million PRs for new features, they have to review, and it's actually more work. So we need to figure out the pattern of engagement for how people will get involved, and it actually reduces the load on the maintainers versus making things worse. And then finally tooling, what kind of tooling can we build and put in place to help the overall thing? So some of the things we did, we went to the maintainers and we asked a couple of questions, like what are the problems they're facing? What are some of the most time consuming tasks? And we also want to do some work to kind of understand the impact of dependencies on them. And I'll talk a little bit through the different slides on some of that data and what we're doing. So one of the first things we looked at, NPM published like a top 1000 modules a little while back. So we use that as a sort of top dependent on modules. We use that to look at what's going on. It's interesting, in terms of the last year of those 1000, only 60% had a release in the last year. For 40% of them haven't even had to do a release. A number of them, interestingly from our perspective, at least as they've actually had commits and they've made changes, but they haven't actually tested in version 10, which is the current LTS. And so one of the things we did put together and work on is a blog post, making our recommendations in terms of testing, which is to try and really encourage people to test on the latest LTSs. On that front, I don't have it in the slide deck, but there are some issues in the package maintenance repo talking about some new options in Travis that let you more easily, basically test on a particular set and have those tests change. And LJ Harbus has done some work to sort of create some templates, which you could pull in and therefore like get testing on all LTS versions and as they change, get the new versions without having to change your Travis configurations every time. We also looked at which version things were testing. And again, 877 of them had Travis, sorry, Travis configurations, which we used as a proxy to what they're testing on. And again, what we found is only two thirds were testing on the current LTS version. So these are the ones which are most used, almost certainly being run on 10, but don't necessarily test on that. So it's potentially moving in the right direction because 70 packages were added since April, but again, in this blog post, one of the things we were trying to do to help is to evangelize testing on the versions we think people are using for the most part. In terms of the dependencies, which is another thing, like 400 of the top thousand don't even have any dependencies, which makes sense, because if they're the most dependent on, they'll tend to be maybe the smaller module that everybody else uses. But of the 600 that did, 20% of them were outdated. And that may or may not be a worry, but it certainly is interesting in terms of how actively they're being maintained and updated. In terms of development dependencies, it was even higher, although we're not necessarily sure that that's a concern because development dependencies, if you're developing from get, you're probably already using those new versions versus you don't need a publish to get those. So not particularly necessarily a problem. The good news is though, that despite that, when we looked at those, only seven had deprecation warnings and they didn't have any vulnerabilities reported. So the module maintainers, I think they all deserve a big hand, they're doing a good job keeping these modules, which are very dependent on in a good state. So that's actually a really positive thing. So now on to the support info, which is one of the key sort of best practices we're working on. And that's to add some metadata, which is hopefully intended to close that expectation gap. And it's got three main areas, it's got the target response and backing. So target is not like engines. So there's already an engines field which says I support these specific versions of node. Target is meant to be my ongoing intention of what I'm gonna support. So I'm gonna support for example, all active LTS versions. So when there's a new LTS version, you don't need to change that. It tells you I'm gonna support that LTS version. And likely when I drop off, it's no longer LTS, I'm no longer to support that. So we have a number of definitions which are intended to let the, to express and set the expectation in terms of what am I gonna support going forward. Responses around telling, setting the expectations in terms of like what kind of response you can get from a maintainer. Like is there paid support available? If it's not, even if it's not paid, how quickly is my intention as a maintainer to respond? It may be like, well, whenever, or it could be no, I try and respond within a week or something like that. And then the last piece is backing. So how is the project supported? So, is it just my own hobby on the weekends? Is it actually a company which is funding it? Is it part of a foundation? There's a whole bunch of different ways, but what's the sort of support network already in place? As well as like, if you wanna join that support network information and how you might do that. One of the interesting things is as we were discussing this, NPM implemented the funding feature, which is a way that you can add some additional metadata to your package about how people can give you funding. That's actually, the NPM people who did that are part of the team working on this overall schema. We kind of see that as complementary and hope to leverage it. They just didn't wanna wait until we had the whole thing figured out and vetted before we did that. And I'll go into a little bit more detail on what they are. At the very high level, though, some key attributes is it's like JSON formats, so it's tooling friendly, but also sort of readable. It's consistent with the package JSON. We had a lot of discussions to whether it should be part of the package JSON or not. In the end, it's actually, we've said it's a link and ideally a link to your GitHub repo. So you can always go to that link to get the most active, the most current version of the data because it's not necessarily tied to a publish. You could change your support statement at any time, right? But at the same time, we want in that GitHub repo so that most likely when you make a publish, you're gonna get a copy of the current data so that if you're offline and can't go to something, you're gonna have a reasonable proxy for what the data would be. In general, we've thought about it use of this in the JavaScript ecosystem, but tried to avoid anything that would like limited to the JavaScript ecosystem because we think other ecosystems are gonna have the same challenge. And finally, it's a draft. You'll see the way we have our docs structured. We still have it in the drafts and so we're still looking for input and feedback and so forth. In terms of just a quick view of the structure itself, in terms of the backing, this shows the current versions that we have. We do see that this is something that people like PR in new versions over time. So if there's something that doesn't exist, we can add to the terminology in terms of what they might be. So in this case, Sponsored is the one that relates to what we saw with the MPM funding where you can provide links to say, here's the way you could provide me funding, but you can also provide other information. So for example, I'm part of a foundation. I'm part of the OpenJS Foundation, for example, and maybe by joining or supporting that foundation, you're gonna help support this module. In terms of the target, again, as I mentioned, and it doesn't overlap with the engines field, it's meant to be more like some people actually say they support all versions of Node.js. And if you wanna do that, you can use that. LTS is another common one, and then there's sort of different versions based in a large part, some of them on the Node LTS strategy. So whether it's like an active LTS or maintenance mode and so forth. And then finally, the response where I can say time permitting, which is like just whenever I get to you or I can say like regular working days within five days, I will get back to you. And it's all about setting those expectations so that you can understand what you can expect if you need help or want help or whatever. And whether it's this includes whether you can get paid support or not. In this case, it says like paid equals fall. So here's just a URL where maybe you go to a GitHub project. Other ones might be like, here's the entry point if you've bought a support contract. And the whole thing is about doing this in a way where we have data that comes along with the packages that we can now build tools around that will help you just like licenses, go through your dependencies, understand what they are, and hopefully motivate you to help get involved and support the packages that matter to you. We're also working on other best practices. Go very quickly through this, but we have ones around testing, publishing, versioning, licensing. We understand that package maintainers, they can do whatever they want, but often at least for me, it's easier for me to say, what's the best practice? I just want to adopt that. So we're trying to define some of those. And even if I end up tweaking that, understanding the best practice just makes me more comfortable that I know what I'm doing. So we've worked on a number of them. If you go to the repo, we have a docs and we have a draft docs. So you can go and see, we kind of release them in the drafts, get some more feedback and then promote them to the doc. So if you're interested in seeing what those other ones are, we have a good set that we're working on and that's the thing we're gonna continue to work on and build up. I also mentioned developing patterns of engagement. So in this case, again, 100 developers unleashed on your project is probably not gonna help you. So our approach is to choose one or two pilot packages, experiment to figure out what works and then document that and then hopefully have a recipe that we can use to, when people come to us and say, hey, I'm interested in helping through the package maintenance team, my ultimate goal would be, we would have some sort of backlog or work or modules that need help. And as people came in showing interest, we could point them at that. But we gotta figure out how we can point them usefully to packages. So today we're currently working with Express. I'm sure everybody knows Express. It's one of the key projects within the ecosystem. And some of their answers in terms of what they were looking for, like the top one that always comes through is help triaging and answering questions. So don't write me some new features, help me answer people's questions we're coming in. The other things that have sort of come out through the discussions is that when you get to issues, you can actually build up in an open source project a large number of issues, but those aren't necessarily all of equal importance to the maintainers. So having a top 10 list where the maintainers can identify, these are the ones that like, if I had time, I would actually do myself so that when somebody else does it, they're like, that's fantastic. I'm gonna take the time to review because it's doing something I would like to do. So doing the top 10 list, and then there's some sort of bigger things like how do I add HTTP2 to Express? Where the maintainers just don't have time to think about it, or maybe it's an area like TypeScript where they'd like somebody who's got more TypeScript background to help out. So identifying those is other key ways to get involved. And at this point, I do wanna call out that Wes, who's working as part of the package maintenance team has a talk on how to get involved in Express. Tomorrow, I think it's like 10, 20. So I'd really recommend going to that. He also has a session at the community corner which is gonna follow that if you wanna actually become a maintainer, sorry, a tree Azure, and get involved. One of the great things that has happened as we've been working with Express is, actually I'll wait till the next slide when I get there. So some of the concrete things we're doing with them is Wesley put together the status board. If you've looked at Express, Express actually consists of a number of different organizations. So just understanding what all makes up Express is not that easy to do. So this status board provides all the different projects and organizations that make up Express. You can look to see like which, how many open issues there are, all that kind of stuff. And then as we mentioned here, this top 10 issues in terms of like, what are the things that maintainers would most like to see. And then the other thing we're working on is that pattern for how you get people involved in triage. Cause that's the top ask for many projects. Wesson, Jerish, another one of the team members that I work with is working on documenting and adding some documentation to Express to say here's how you get involved in the triage efforts. Here's how we're gonna use tags. And one of the great things that happened while we were working on this is that GitHub announced the triage role. And the project seems very open to giving the triage role to people who wanna help. I think that's gonna unlock the ability to get involved and help on that front significantly. So definitely some progress on that front. And like I said, if you're interested at all, go see Wesson's talk. I think it's an important one, as well as you have the opportunity to maybe even become one of those triages in the session afterwards. The next piece we're working on is tooling. So we've built a number of tools or they're in progress. And we're talking about some and I'll go into the details. So the first one is, and I'll mention PKKJS, that's another organization that the team decided to create to basically be the home for these tools. The support tool basically is to help you manage those support files that we're recommending people generate. So basically, create an initial version and validate that you've gotten it right. So it's, this one's not about looking at the dependency tree but about helping the package maintainers generate and maintain them. NV, we talked about the target, not the target, the target not listing node versions specifically, this actually will help you take what the, the LTS or LTS active and convert that into what does that really mean today? Those are a forward looking thing that will change over time but you often wanna know what it means today and this tool basically takes one and gives you the other. The next one where I talked about the status board. So basically providing a good view into a project. Some of the things we're working on, the other one which we definitely wanna do in terms of like the support one is also like build that into a tool that helps you validate the dependency tree just to have an quick start on that. The next thing that Dominica has really been working a lot on is thinking about 2FA. If you're a package maintainer, you probably know that it's not that straightforward to publish your packages with 2FA. And in fact, we see that through the fact that, you know, 0.6% of packages and very few maintainers actually have 2FA enabled. And it's really reflects the fact that if whatever you can do today easily reduces you to a single factor. So you're not really making things better. One sort of thing that's coming out is that MPM is gonna be providing more information about modules and one of those things will reveal whether you're using 2FA or not. So that might put a little bit more pressure to move to it as well. So Dominica's been looking at different options. So like doing remote OTPs so your CI publishes your package and then you'll get a reach out immediately over mobile, chatbots, some sort of software of a service to be able to give the second factor and let the publish complete. Other ideas have been like publish or deliver your package to GitHub and then as a second step, take that out and publish it using your two factor authentication. All of these have enough complication and challenges that it's not like just a straightforward, here's what we'd recommend you do. The great news is back November 14th in one of our package maintenance meetings, MPM actually announced that they're gonna work on something. So we haven't seen the full proposal yet but basically what they've said is they're gonna have something integrated into the CLI which will let you stage. So you basically, in your CI, stage your release, then come back through the CLI and actually promote that to be an actual release and you can control that through the 2FA. So we haven't seen the details and it doesn't mean that it's necessarily gonna cover all the use cases that some of these others might. So maybe they'll still be applicable in more complex cases but we do have hope that we're gonna have something which is covering the 80% use case and make things a lot better. And I think this is just a good example of having brought people to think and talk about the problems in the package maintenance team we're seeing some things actually come out from the ecosystem. In terms of future work, we still wanna get back to that long-term support idea but we understand that it's adding potentially more work so we wanna figure out and lay the pattern for how people would implement that. So we need to do that. Canary in Goldmine is actually something that we've used in the community, the node community itself to test dependencies so that we don't break them. It came out of work we did actually at IBM in our node team. We contributed it to the community and it's used in all of the releases to validate we're not breaking modules. We think this can be useful for modules to sort of do the same thing to validate they're not breaking their own dependencies or the ones who consume them. So that's one thing we wanna move on to when we get sort of get there as well. So just to end up, hopefully I've got you sort of interested and excited and seeing that we're actually making some progress. It's gonna be a long effort but I think we're making some positive progress and so my call to action is like come and help us figure this all out. We have meetings every two weeks. We alternate between nine Eastern and three PM Eastern. These are the times I work in so that's what I know but it helps between letting people both on the West Coast and in Europe be able to make the meetings. If you can't make those, please look at the best practices, comments, suggest things that we should be documenting or if you have a best practice suggest or PR them in and let us work. Let us know what works for you. If you are interested, of course we have the GitHub repo you can get involved in and on the Node.js.org calendar that shows all of the meetings that are going on and so you can find the package maintenance meeting. If you look at the repo a few days before the meeting it will also, an issue is always opened as well that has like the meeting details, the links and all that kind of stuff. So that's what I had today. I'm not sure if we have any time for questions. Oh, and 12.51, I think I'm just on time so I should probably close.