 Good morning, good afternoon, good evening wherever you are today. I hope you're all enjoying the OpenJS World Conference. My name is Beth Griggs and for the past four years I've been working at IBM as an open source engineer in the Node.js Runtimes team. Our team's original focus was to bring Node.js to IBM platforms but over time our team contributed ports for these platforms upstream and now we maintain those out in the Node.js community. One of the areas that our team explores is how we can encourage and support our enterprise customers to leverage Node.js and its module ecosystem. So you'll probably know firsthand the value of Node.js modules. I personally think they're one of the most powerful things about Node.js but they're the one million modules on the MPM registry. There's a high chance one already exists to support the task you have at hand. Node.js modules can make it quick and easy to get small prototypes going while also promoting code sharing and reuse. As an example, I've written a small program that will obtain all of the OpenJS World Tweets. This can be achieved in just 17 lines of code and installing one direct dependency, the Twitter module. And this is just to demonstrate the parallel of modules and show that they enable you to be productive quickly, not solve problems others already have and enable you to focus on the business logic of your application for after the lower level implementation details. But the usage of modules can pose different challenges and these challenges can apply not only to the users and consumers of the modules, but the module authors and maintainers too. Today I'd like to share some of these concerns and later talk about how the Node.js package maintenance team is working to alleviate and provide guidance for some of these issues. First I'm going to talk a bit about the risks of consuming Node.js modules. It's probably safe to say almost all Node.js developers fall into the user or consumer category, even if they are authors and maintainers too. Going back to my other example, I built a small program just using the Twitter module and 17 lines of code. This example program had just one direct dependency, the Twitter module. But that's actually a lot of code in production. When we look at the whole tree of dependencies, there's actually a total of 49 unique packages. This is because the Twitter module depends on many other modules. If we look at the lines of code, there's almost 60,000 lines of JavaScript covered by six different license types. And what this shows is the amount of code you write is significantly different from the amount that you deploy and are responsible for in production. As a developer, it is just as important to think about the code you did not write as much as the code you did. And this is what concerns some of our enterprise customers. The more code you deploy into production, the more risk. These are five risk areas that I found pop up a lot in discussion with our clients and customers. The risk areas are security, licenses, maintenance, breaking changes, and compatibility. And I'm going to dig into each of these a little bit. Looking at security, there was a survey of NodeJS developers conducted in 2017 that covered the state of NodeJS security. Those results found that 84% of NodeJS developers were moderately too very confident in the security of NodeJS core. This means that NodeJS developers are confident with their use of NodeJS runtime. They're confident that generally security issues will be detected and resolved in a timely manner. When it came to looking at third-party modules, only 16% of NodeJS developers surveyed were confident that the third-party packages they were using were vulnerability free. Each year, we get a few notable security issues pop up in NodeJS modules. But there are steps a user can take to mitigate against the security risk. Those include making use of MPM audit. But that itself comes with a challenge, as it cannot tell you if your application is actually susceptible to the vulnerability that is detected. You can use features such as GitHub security alerts. You can lock down your package JSON or publish a package lock JSON. This will stop you automatically picking up new module versions in your production deployments. And then you can enable tools like dependable to help keep your dependencies up to date. And there's also a variety of commercial security tools that can detect vulnerabilities in your Node module tree. And then there's license concerns. I'm going to pre-empt this section with the standard I am not a lawyer. But why should users care about licenses? Well, if you link with open source libraries and then distribute the software, you need to make sure that your software is compliant with the licenses of all of the link libraries. And this includes all of your dependencies in your whole Node modules tree, not just direct dependents. Sometimes it's unclear what's meant by deterrent distributing software. So I'll dig into that now. Transferring software between employees of the same company is not normally considered a distribution. Users interacting with an application over a network is not generally considered a distribution for most open source licenses. But there are some network protective licenses that put restrictions in place for this scenario. And hosting JavaScript files on the public web server is definitely considered a distribution. License types can be loosely grouped into the following three areas. You have protective or copy left licenses. And for these, your software has to be bound by the same conditions as link software. You have weekly protective licenses. These generally have less restriction when you're dynamically linking. And then you have public domain or permissive licenses. This includes licenses like the MIT license that allow you to do almost anything except sue the author. It can be difficult to understand the license terminology. Luckily, there are a few tools that can help with this. The first is tldrlegal.com. And this helps to convey software licenses in plain, easy to understand English. And there's also the GitHub licenses view where it will break down the license into what permits you to do limitations and conditions of the license. Some tools exist to help you understand which licenses are included in your whole module tree. You can use a module named license checker. This will provide a summary of all of the licenses it can detect in the tree. There's a big caveat with this, though. It will only show you what the license field says. It will not check the license text itself. So it's still very possible that a clause is you're missing. Or perhaps even that the license field in the package JSON doesn't match the license file in the repository itself. However, this tool does help give you a general overview of which licenses are included in your module dependency tree. Now to consider maintenance. I'm sure most businesses understand that once you've built a piece of software, there is an ongoing maintenance cost that you need to account for. But if most of the code isn't your own and it's coming from your dependencies, you also need to consider how well maintained your dependencies are. There are a few questions you can ask yourself to help determine how well maintained a module is. Those include, is the module deprecated? Are issues in the module being fixed? Are there still regular releases of the module? Is development still active and how many maintainers are there? If there's just one maintainer, what would happen if something happened to them and they had to give up the project? There are some tools to exist that can help you analyze the activity and maintenance of the module. Those include the GitHub insights view, which will show you metrics such as the number of merge pool requests, number of closed issues, etc. And there's also a website named mpms.io. And this website ranks MPM modules by quality. And to determine quality, they feed in similar metrics such as the ratio of open to close issues and the number of maintainers. Both of these tools can help you answer the question of how well maintained is the module. And there's a question of how can I manage the maintenance risk? And I personally think the two key ways of doing this is to firstly contribute back. So if you can contribute back to the maintenance of these modules, that reduces your risk because you have the ability to patch bugs or maybe magical requests when required. And the other option is to financially support the modules. Another concern is breaking changes. Some projects, particularly in the enterprise, still have relatively long release cycles. So choosing a module that makes breaking changes too frequently could be an issue as your upgrade cycles might not be able to cope with you may need time to migrate to the next major version. The first thing to check is whether the module dependency you're using is following a versioning scheme. The MPM modules semantic version is a popular one. The semantic versioning scheme indicates that the first number will be incremented when a breaking change is made. The second number is incremented when a feature is added in a backwards compatible manner. And the third number is incremented for any patch or fix that's applied. Once you've established whether the module is adopting a versioning scheme, you then need to ask yourself how strictly are they following the versioning scheme? And also how often are they making breaking changes? Another question you need to ask is whether the module that you're using supports the Node.js version that you're using. Some modules will restrict which versions of Node.js they support. Happy, for example, presents a support matrix which details which versions of Happy run on which versions of Node.js. But publishing of this isn't widespread in the module ecosystem yet. So that covers some of the issues from the user's point of view. But what about the author? Let's take a look at the issues from their perspective. Imagine a scenario that an author creates a module just in their free time as a hobby, and then it gets really popular. What challenges will they face? The same five areas of concern apply to authors too. So looking at security. For the author, there may be an expectation that they will respond and fix the security vulnerabilities. But can the author commit to fixing them in a timely manner? And can they cope with the influx of reports they're getting? In enterprise settings, there's sometimes an expectation that a security problem will be fixed in a given number of days. That expectation doesn't translate to the open source world. And then there's licenses. These are important for authors too. They need to make sure that they're choosing the right license for their project to protect themselves in the future. So that's a website called chooselicense.com that can help with this. And then there's maintenance. Maintenance is a concern just as much for authors as it is for users. The maintenance burden of maintaining an open source project can be huge. There may be expectations from users for responses, for bug fixes, for feature requests. Breaking changes are also a concern for authors. How does an author know which other modules are relying on them? How do they know that when they fix a bug it doesn't break a feature for a user? And how can they test the impact of their changes? Compatibility is also a concern for module authors. How do they keep their module up to date with the latest Node.js releases? And also how can they manage the expectation of which release lines they support? Also what happens when a module author no longer has time to look after their module? How and who can they ask for help? And how can they find someone trustworthy to hand over the module to? I don't know if you remember the Flatmap stream incident. This started off as a social engineering attack. In this situation the maintainer of the module no longer had the time to maintain the Flatmap stream module. The attacker originally appeared to be acting in good faith offering to take over maintenance of the module. But once they gained the access they needed they published a malicious release. And this really highlights the need for some defined processes for handing over modules. So that covers some of the challenges from an author's perspective. So now we've covered the user and author's concern. How does the maintenance fit in? At this point I would like to introduce the Node.js package maintenance team. The Node.js package maintenance team was established in 2018 and it was established to focus on the sources of friction to module ecosystem adoption, particularly in the enterprise. I was already recognised that the highest level of comfort was with packages and modules that are stable and where there is confidence that there will be ongoing maintenance, predictable releases and easy upgrades to new Node.js versions. Unfortunately at the time we also found that there were a number of packages that were broadly used in the Node.js ecosystem that may not be getting the basic maintenance required to keep them up to date, reliable for the widespread use they have and usable for the latest Node.js versions. Today the package maintenance team has representation of all three of these personas. We have users, authors and maintainers, including maintainers of some popular modules and also including maintainers of the Node.js runtime itself. And there are a range of companies involved including NPM, IBM, American Express, Netflix and Neerform. So what is the aim of the Node.js package maintenance team? The package maintenance team covers a few different areas. The first it would like to document some best practices for module authors and maintainers. It would also like to document processes for authors and maintainers to follow in certain situations, for example when you're handing over a module. The package maintenance team also wants to encourage and promote responsible and sustainable consumption of modules and also is working towards encouraging clearer and closer communication between users, authors and maintainers. So what is the package maintenance team actually doing? So we've got to set the groundwork first. We're trying to understand the state of the ecosystem. We're doing this via surveys, but we're also getting together and discussing the common problems users, authors and maintainers space. We're also asking what are the most time consuming tasks for users, authors and maintainers. The package maintenance team's also been working with some pilot packages including the express module. For working with the express maintainers we've been able to identify some key problems that the maintainers are facing. The first is that they're struggling to keep track of the status of all of their issues across express modules. The express GitHub organization has several repositories. So with issues being opened across them, things can get very fragmented and difficult to follow. And also generally they're struggling to keep up with all of the issues raised where express is so popular. And the package maintenance team has been working with express to find a solution to their key issues. And one of those we're investigating is triaging efforts. So the package maintenance team is working to define some best practices for triaging issues. They're also working to define a pathway for volunteers to help modules so that people could volunteer to maybe triage for modules such as express. And the package maintenance team has now successfully recruited volunteers to help with the express triage. Members of the package maintenance team have also worked alongside the express maintainers to help create and enhance their status board. So the status board is a view that helps the express maintainers keep track of what the top priority issues are or the issues where help is wanted. The package maintenance team are also working on publishing best practices for authors and maintainers. All of these documents are viewable in the Node.js package maintenance repository. Some of them are still in draft phase and this is because we're still working with authors and maintainers to gather a variety of use cases. In some areas we may go a bit further and provide resources that module authors and maintainers can use, such as for testing. We may provide a sample Travis Yammer file that enables you to configure your Travis CI to run across each of the support in Node.js versions. Another area we're investigating is the publishing of support information. We're first encouraging authors to document their support commitment for their module. Be that whether they're open for commercial support or they are willing to provide support on the best effort basis or even if they're not willing to provide any support. And secondly we're exploring whether we can define this information in the package JSON to allow it to be machine readable. This would enable us to build tools to provide to users so that they can validate the support information of their module tree. Generally the purpose of this support information is to manage the expectation between users and authors. It can give users the confidence and information to make a solid judgment on whether they should use a module and also provide an avenue for authors to maintain expectations. We're also ensuring that the support information can be integrated with newer features such as MPM Fund. The package maintenance team is also working on tooling. We've spun off all of our tooling to a separate GitHub organization named PKGJS which describes itself as tools for package maintainers by package maintainers and we've already started work on a variety of tools. One of the first tools created in the PKGJS August of Dependence tool. This tool is aimed at module authors. It helps authors answer the question who is depending on me. It helps them find a list of their downstream modules. You can pass this tool a package name. So in this example we've passed it the package express and it will then scrape MPM to find all of the modules that are depending on express. You can then also filter these results, for example by the number of downloads to find out what is the most downloaded module depending on you. Another tool in the PKGJS August is the detect node support tool. And similarly you can pass this tool a module name and it will try to scrape which versions of node the module supports. And one of the larger tools we're working on is a tool named Wibby which stands for will I break you. And it's a tool that will help module authors test whether the changes they're making in their module will impact their downstream modules. So kind of think depend upon for testing whether you as an author are breaking the modules depending on you. And this Wibby tool will rely on the dependence tool I mentioned earlier. So what are the next steps for the Node.js package maintenance team? Well we're going to continue to seek consensus on best practices for module consumers, authors and maintainers. We're also going to continue to build tooling to support consumers, authors and maintainers. And also we're looking to support more module in need of help by recruiting more triages and in particular at the moment Node.js is looking for help. If you're interested in getting involved in Node.js package maintenance team there are a few ways that you can do so. The first way would be to check out our guidelines and if you disagree with them let us know it's likely that we've just missed your use case or scenario. You could help us build tooling to support module users, authors and maintainers or you could become a maintainer so help triage issues and contribute to popular modules in need of help. All of the information can be found on our GitHub repository which is Node.js slash package slash maintenance. We've covered some of the concerns that users and authors face with Node.js module ecosystem. We've also explored the work that Node.js package maintenance team is doing to try and help alleviate some of these concerns. If you want more information you can find me on Twitter and I hope you all have an enjoyable remainder of the conference.