 Welcome to package maintenance team working group year three panel discussion. My name is Glen Hinks. I'd like to start off by just introducing the package maintenance working team. So the health of the JavaScript module ecosystem in part depends upon the ability of the community to maintain the core packages within it. The package maintenance team is addressing these issues, these issues of long-term maintenance goals by offering a place for maintenance advice, some tooling development, assistance to struggling maintainers, and guidance to folks that depend upon seemingly un-maintained modules. Our goal is to aid the maintenance and health of this software ecosystem. I'd like to start off by introducing the panels but before I do that I'd just like to say the opinions expressed in this talk are our own and not necessarily those of our employers. So I'd like to start off by introducing Dominicus. Dominicus, would you like to introduce yourself please? Hey everyone, I'm Dom. I sometimes would say that I'm a full stack developer, I would say that's more like all over the place developer. I got my hands in a bunch of things and in my day job I build things for clients at Neoform. Thank you Dominicus. Dominicus is being very modest, he does lots of very interesting things. Bethany, would you like to introduce yourself please? Hi everyone, my name is Beth Griggs and I'm a senior engineer at Red Hat where my roles, all my health roles focused on AJS including spending a portion of my time contributing to the Node.js project. Particularly I'm active in the Node.js release working groups so working on getting releases of Node out there and also when I'm not working on that I'm looking at all of our clients that are using Node in the enterprise and looking at what issues they're hitting and things like that. Thank you Bethany. Rodion, would you like to introduce yourself? Hi, sure. So really excited to be here. My name is Rodion. I'm a software engineer working at Aspire Global. My main interests are JavaScript and frontend and backend development. We are developing an iGaming platform so I'm working with systems on the high traffic and lots of challenging tasks. I also like open source so I'm a member of Node.js package maintenance working group and also help with Node.js website redesign. Thank you very much. And last but not least Darcy, would you like to introduce yourself? Sure. Thanks Glen. My name is Darcy Clark. I'm the engineering manager on the MPM Cli team at GitHub. I'm recently acquired last year. I'm pretty active in the Node community and open source JavaScript community helping out with OpenJS efforts as well as the Node projects wherever I can and collaborating with folks here in the package maintenance working group as well as the tooling working group. And yeah, it's a little bit about me. Thank you very much Darcy. My name is Glen Hinks. I work for American Express. I work for the acquisitions division and I am mostly a Node developer or previously a Node developer. We're very much a JavaScript shop and we're very interested in the long-term health of our ecosystems. I'd like to start off by asking Bethany to give us a little bit of an introduction into the history of the package maintenance team. Yeah. So the package maintenance team was kicked off as a result of the call to action back in 2018. It was actually kicked off at the Node Summit conference. And at the time it was just after like that was already widespread adoption of Node.js in the enterprise that was reaching a very large number of NPM modules out in the ecosystem. And a few folks had found that there were still kind of like barriers to adopting the ecosystem, the module ecosystem in the enterprise. And this was particularly around like how much choice there was and concerns around ongoing maintenance and support of the ecosystem modules. So the team was announced to get together a bunch of folks who wanted to work on the challenges around module ecosystem adoption with that enterprise focus. And this was also stand because at the time there were a lot of widely used modules that weren't necessarily getting the maintenance and support that was needed when you look at how widely they were used. And so the team got together then and since then we've been getting together probably every couple of weeks to talk about various challenges. And the early kind of work was around producing some best practice documentation for module maintainers to follow. Particularly to help reach the mismatch in expectations some folks may have between consuming and maintaining modules. And then from there the project started to get and talk about more challenges. We found a need to produce some tooling to help support and module maintainers. And we're still continuing. We're still talking about new issues and building more tooling and figuring out how we can help out. Thank you very much Bethany. That's an introduction for the team as a whole. But what I'd like to do is ask each member of this panel what are the motivations and the state of the ecosystem from their particular perspectives as they look in at the work of the package maintenance team. I'd like to start with Dominicus. Yeah, so the nodes ecosystem is huge. And there's a very broad spectrum of things happening there. I think there's for my personal perspective is my personal interest is to kind of have and be able to sleep at night quietly knowing that the modules that we're using are high quality and are well maintained. I have a particular interest in tooling and in CI tooling which I've been observing the ecosystem how it acts in that regard. I think we have it really nice in Node.js land because mostly we have a very well standardized approach to how you do tests for how you run tests for various modules that you're using. If there's an NPM test as a shortcut and for a very long time we had a very nice open source initiative from Travis where pretty much everybody used the same setup in CI as well. So yeah, just watching out for modules to be up to date. And there was also the case that around the time that this group started there was the ESLIN scope issue, security problem and there's people moving on, there's packages being abandoned but they're still getting a lot of use. So in terms of overall health I just want for the customers to deliver the proper experience and the quality modules that they can use. Thank you Dominicus. Yes, everyone has their own special interests and perspective upon the work we do but we all know it impacts all of us in so many ways. Rodion, what are your views on the current state of the ecosystem and your motivation for taking part in the package maintenance team? Yeah, we all know that companies that build big enterprise level applications they desire to depend on stable maintainable packages with predictable releases and smooth non-js version upgrades. So unfortunately we see the situation that some critical for the ecosystem packages may not receive required level of support because of increased popularity of the package but in the same time initial maintainers were not reinforced with relative manpower to deal with growing amount of issues. So from my side it will be great if companies will start to invest more efforts in support from their side in packages that they depend on and that's why our team was created to reduce this gap between package maintainers and consumers. Thank you Rodion that's very interesting and that's a very common view I feel from many people the concern about the sheer size what happens as people that initiate modules and handoff to maintainers what happens next. It is such a vast system and I'm not sure that this really has happened on this scale before. Bethany what do you think about the current state of the ecosystem and your motivation for participating in a package maintenance team? Yeah one particular thing is the widespread choice you know with like so many million modules to choose from learning what's a good choice and particularly I came from this first time using the node when I was at university where I would just look for a package use it and I was like yes this does the job but then joining a large corporate company like IBM where we've got lots of folks using node and learning how a large organization and enterprise deals with this massive choice that was a big learning curve for me and actually sparked a lot of interest in for example the concerns around like licenses maintenance and what actually makes a module supported and maintained enough for you to be willing to stand like stand your whole production application on top of it and so that that's really where a lot of my interests comes from and what why I like getting involved because trying to trying to figure out how we can encourage responsible consumption of modules and how to help people choose them. Yes so that is one of the you've hit a nail on my head there are so many to choose from which ones we choose there might be five or six that do the same thing they might seem equally as popular which ones are being maintained how do we know which ones are maintained you know do we just use one that has the best read me that's the sort of thing we see with this one looks like it's the easiest to use and we may find down the road that it might not be have been the best choice so now we're going to talk to Darcy who actually works at NPM for his perspective of the current state of the ecosystem and his motivation for participating in a package maintenance team. Thanks Glenn yeah so my original involvement was it's a bit selfish obviously trying to stay up to date with other folks in the ecosystem and and also trying to hopefully bring discussions into a form that is sort of neutral a neutral form I really like what we've done here with this group from NPM's perspective in terms of the ecosystem and how it's changing evolving we can continue to see exponential growth that might not be surprising if folks on this group but we continue to see exponential growth in terms of downloads of packages consumption of packages in October we hit 100 billion monthly downloads from the registry the NPM registry which is amazing milestone as a ecosystem this you know was marked also at the 11 year anniversary of the NPM CLI so right around the same time we hit about 100 billion downloads so that's that's 11 years and and we finally hit that milestone surprising enough this past month we just hit 123 billion downloads so you can see that exponential growth just continues to climb and in terms of the registry the things that are actually on you know NPM we have 1.6 million packages now as of 2021 and if you look at the numbers from also GitHub side who also is helping to track things their recent stats from Octaverse or stated the Octaverse or state of the repositories that live on on GitHub we saw the JavaScript continues to be the number one platform in the world for in terms of programming languages and TypeScript is quickly jumping up there as well hitting you know number four in terms of languages just behind Python and Java in terms of the state of those projects 94 percent of the JavaScript projects rely on open source they rely on other open source dependencies and the median transitive dependencies is 683 if you compare that to other languages Python is 819 roughly 19 median transitive dependencies Ruby 68 and PHP is 70 the closest to you know node and JavaScript projects so that's pretty interesting in terms of the growth and sort of the network that we're establishing here as an ecosystem and sharing projects with each other it's a big web and we're all working together hopefully to strengthen you know more projects thank you Darcy and it is interesting to note that sometimes we have a let's say a selfish self-interest from a perspective that we have but that interest actually serves the wider community because funnily enough we all have that same interest we want our thing to be maintained and to be stable but the only way to get our thing to be maintained is to do it at a much larger level because as you say we have so many dependencies and they're all open source majority of them maintained by volunteers in the community so I'd like to give my perspective on this ecosystem so I'm going to take a little bit of a bigger perspective step back a little bit so I must say there was a time when the JavaScript ecosystem was actually perceived as not the realm of serious programmers or real development that time has long since passed as Darcy has said you just got to look at the size of it it is now the largest ecosystem and the barriers to entry are very very low very low indeed compared to other ecosystems you do not need years of experience to make a really big positive contribution and this makes it a very inviting community and I look at it and I can see people of only one year's experience making packages pushing them out and they're being adopted however I see also see from everything we said there's a downside to a large ecosystem we have the most dependencies transitive dependencies and we do see common modules becoming less commonly used and as ideas change we the common modules might change and this is good the ecosystem we're pushing this ecosystem forwards however there's a basic underpinning of the ecosystem the underpinning actually comes from commercial companies they pay for us to go to work and do stuff and although we use this this thing they have revenue generating sites that often depend upon these maintained pieces of code and sometimes some modules get superseded by others and these modules that they depend upon are now unmaintained and when we say unmaintained there are different types of unmaintained somebody may not have time somebody may have essentially ghosted a module and have moved on there may be family events that have happened and I view this as a chance to actually for people to come to a small team and say there's this module it has many downloads many people are dependent upon it I can't contact maintainers or they're not responding what should we do and I think this is the first time as an ecosystem and I originally was looking into the ecosystem from the outside before I joined it and when I was on the inside I realized it was much bigger on the inside than the outside meaning I realized what it was where the first point of call I think that's been set up for this actual long-term health of the ecosystem so that's what my mine is also selfish I want things I use to be maintained and the only way to do that is to do that at this sort of larger level so I'd like to thank everyone for that taking given us their perspectives on this particular ecosystem I'd like to go into some of the things we've actually done in the package maintenance team I'd like to go to the early days this is a three-year look back when we first started obviously you know there's lots of interest when a team is first kicked off we are looking to see what our remit was what were we doing and we actually started with documentation so with many projects the initial phases are characterized by long open discussions and we were no different we had long open discussions we were composed with participants from many time zones and our initial goals was to establish via debate what we wanted to achieve so we started writing things down and some of the first things we wrote down were really basic things like what license should you have and we looked at licensing we actually contacted npm and we said what are the most popular licenses and they provided us with a nice ordered list and from that we made some judgment calls and said okay these are the commonly used ones we recommend you should have a license we wrote it down at that time it was still very early we weren't sure how much or how big a remit we had so we started writing down other things we wrote down what we thought about testing we came up with a governance model for our team it was very much about starting off and we weren't quite sure what the entire remit was we knew what the problem was but how should we go about solving it so we started off by writing things down but we soon realized what our our role was was as a place that could be engaged by mostly well-known people within the community that had an issue with a module they would come along and they would say this module has this many downloads and often there were many weren't they Darcy many millions and it appears to be unmaintained or at least non-respondent in github and we wanted to become a place where we could provide some guidance somebody could come to us and we could say yes we will contact them we will say who we are are you maintained or you're not maintained and we would wait we provide some sort of guidance to users it's not just a case of maintainers there's also the users of those modules and then of course this leads into what we should do when we actually have to support things so i'm now going to ask rodin about the package support tool what the support means to you and why is it valuable rodin yes so as a working group we committed to work on processes and tools that may reduce the gap between package maintainers and consumers in terms of expectations so it was decided to document a process of how package maintainers can communicate the level of support they are going to to provide for the packages they create and we created a specification called package support which describes how package maintainer can specify a target version of Node.js they will they will support and how quickly maintainer will respond to issues and the bacon so how package is supported and how consumers may help support the package and based on this specification we created a tool called support that will help maintainers to create and validate the structured support information for their packages and this tool also can read support information in dependencies tree of the project so i definitely recommend everybody to check out pkgjs slash support repo and start adding support information in your packages thank you rodin and i'm going to continue this discussion we've we just had about support by asking the other members of the panel how much support do you think users should be getting and do you think that they've become a little bit spoiled after all most of these modules are maintained by volunteers and we always enter into these things very you know bright tide but after a few years of maintaining something you may become a victim of your own success do we think that do do we see that very much in the community i can answer the first question right as a user of a package you should expect zero support right that's that's the reality of this i think there's a lot of ethics of open source to be communicated to a lot of people on the other hand there is a certain expectation i guess in between the people that overall the community would step up to fix major issues and i think this has happened i think there's a bunch of really well known and widely used packages that have not necessarily exactly changed hands over the past you know few years even even last year that have been receiving security reports vulnerabilities cv's that have been getting addressed and i think that overall as long as you know you're picking your modules carefully the community has been providing that support to to to kind of not necessarily guarantees but a certain baseline of support where issues are getting addressed in a timely manner in critical packages overall right yes it's it's a very interesting thing on the face of it we're kind of offering an ecosystem however currently we're not guaranteeing any levels of support and i think many of us on this panel were always amused by the things we read in github and the demands that are made upon maintainers who have given their time freely that they should provide features or services to people part of this team's remit is to try and make this process a bit better what we've found is if we provide a tool that specifies maintenance levels then we may have some expectations or relieve stress on users and on maintainers too if it's unsupported you know they'll get there when they can however we do have some modules within the ecosystem that essentially people do maintain and we've actually been developing a tool called gwibi for this and I would like to call on Dominicus to talk a little bit about what gwibi is and why we think we need this tool yeah so gwibi is a bit of an experiment I guess there is an overall need to have a generic tool in the ecosystem that would be similar to the scanner in the gold mine tool that's available for Node.js itself whereby there's nightly builds of Node or pre-release candidates of Node.js are getting tested against the modules in the ecosystem that Node.js doesn't break these modules and now because we have a very large ecosystem there's lots of interdependencies between modules right one thing depends on another and that means that as a maintainer who does provide a level of support to their package or even just you know purely out of selfish interests they're building the tool and don't want to break other tools that they may be using themselves because of this deep and wide dependency trees that we have in Node.js ecosystem you want a tool which allows you to test that whatever you're building does not break your dependence so gwibi is an attempt at that there have been similar tools in the past I think there's some still available what gwibi does differently is and I guess that's the tricky part and that's the experiment part right to see if it works is instead of downloading the packages and running their tests locally it opens pull requests or pushes branches into the package repositories of dependence which allows these tests to actually run in the CI environment of that package the way it is set up so as I mentioned we have mostly standardized in Node.js ecosystem to basically you can test any package using npm test however if you do that locally that's probably going to run in the Node.js version that you have installed locally whereas most of the packages would probably be testing against multiple would be targeting multiple versions of Node right so you could have I guess 10 is how is it out yet it's probably out of support yet at this point but if you have if you're supporting 12 14 and 16 and you start to use new features you could be breaking something in Node 14 so you want to test the whole run the whole suite the whole system of tests with the changes that you're making so wibi tries to do that and yeah it's very much still in progress there's a couple of unsolved issues but we're moving there and we'll see how that goes right I'm very interested to start using it in in in real life against real packages against real I guess plug-in ecosystems and we're we're getting really close to be able to do that so yeah looking for volunteers to test that as well yes I'm super excited to start using a tool too so thank you thank you very much we're going to move on to Darcy now to talk about vulnerabilities because we all know that vulnerabilities cause problems and nothing freaks out the enterprise more than a vulnerability report Darcy would you like to comment yeah so this is another area in which this group was speaking to security for quite a while trying to ideate on different initiatives that we could kick off and and figure out how we could get involved and make some recommendations along the lines of sort of the supports json spec that sort of came came out of that work and so myself and Wesley Todd have become the co-champions of a new collaboration space in the OpenJS Foundation it's the first ever it's called the package let me get the name right it's very long package vulnerability management and reporting collaboration space and we'll be kicking off essentially the first session there at this conference and and we'll be talking a little bit more about what we're hoping to achieve with that group the idea being that we would like to improve the CVE reporting and and sort of resolution workflows that we see today going back to some of the data that I gave before from the GitHub state of the octaverse we see roughly 59% of those 683 transitive dependencies they're up to 59% of them are going to get a security alert within a year of them being active on in a in a project so that's that's almost almost the certainty is what we see in the data that there's going to be some sort of alert come by with one of your dependencies and we see roughly 17 of those vulnerabilities that are actually filed are explicitly malicious whereas the other 83 are actually results of mistakes so we're trying to like reduce the churn and we want to essentially bring together security researchers and organizations with package maintainers and and tooling authors like like ourselves at npm to try to reduce this burden and reduce the noise so that we improve the tooling and secure the ecosystem more so that's the idea behind putting together this collaboration space and we're working with folks that have already been working this space for a while and yeah we're hoping that the outcomes of that work will be you know improved tooling and potentially even auditing tooling for the ecosystem as a whole so that's a little bit about what we're doing that space and that was spun out of this group which which is an amazing and exciting initiative yeah it is quite amazing to think we've spun off some children from from the team and no one takes security lightly and you know for the health of the ecosystem and its adoption within the enterprise this is a serious thing and it's good to have a place to go that we could point those organizations to and go we take this seriously as well so I'd like to get back to Bethany and have her talk about what she thinks the greatest achievements for the package maintenance team is so far sure so I think great achievements include like the documentation we produced the tooling and or like getting to know the other package maintainers but I do think the key achievement and outcome of this working group is that we have provided a neutral space where we bring together package maintainers consumers authors and also from various parts of the ecosystem so we have to fix from npm we have people who are active within a node project and so bringing all of these people together to try and figure out the problems I think that's probably the greatest achievement because we're we're then satisfying everyone's needs and challenges rather than just like a subset of the the constituencies absolutely so this is the first time I've been involved in a party group too and you know I just walked up to people at conferences yeah yeah I'll help I don't know how I help and they reached out to me and said okay and I said what you don't want me to write code they said no and I think if we give that message to people it's not just about writing code and majority of projects need other help too so Rodion I'd like to turn it over to you and I'd like you to talk about your experience of how you got involved with this group yes so I joined a working group almost a year ago and I heard that Node.js working groups have live meetings on YouTube so I decided to check those recordings and I found meetings for package maintenance working group and after that I subscribed to working group repo on GitHub and from one of meeting nodes in that repo I discovered pkgjs organization with tooling repositories so I subscribed to several repositories there and in a few days I think I got a notification that some of support tasks was failing on some of Node.js versions so I decided to check those tests and fix it and yeah so this is how I got involved so everybody can start to contribute just make sure to subscribe to Node.js calendar visit our meetings subscribe to repositories and check notifications regularly thank you Rodion I'd like to reinforce that the most important thing is not your ability or the level of your contribution it's actually just participation and I keep saying this to people people I work with people I come it's actually please participate you'll find that you're far more valuable than you realize no matter what your skill level is so I'd like to wrap up today I'd like to thank each one of the panelists and if you're listening to this we will be taking questions what I'd like to say is the number one thing with any ecosystem for its vibrancy is its community and I think whatever your level of contribution or skill level is actually just that first initial participation often leads to greater and better things and all I can say is there's almost no downside to participation I can think of all I can say is there is an upside we are the largest community I said at the beginning we were not viewed as serious to begin with but I think everybody knows we are very serious we are very large and we are certainly a competitor to most ways of of doing things in what I'd call the traditional neoclassical way we've provided a different way with a very low entry point for junior developers and with that I'd like to thank the panelists and wish everyone a great day thank you all