 Hi, everyone. My name is Beth Brogues and I'm a senior software engineer at Red Hat. I gained my Red Hat just three months ago when I moved over from IBM. And I'm excited to be here today at my first virtual DevCon. My tool today is titled, Consuming Open Source and Maintenance Perspective. As part of my role at Red Hat, I helped to maintain the Node.js runtime. I'm a Node.js technical steering committee member and particularly active within the Node.js release working group. This means a lot of my time is spent auditing the content for and producing releases of the Node.js runtime. And today I'd like to share some of my experiences and challenges as an open source maintainer and also showcase some of the work we're doing within the Node.js ecosystem to try and alleviate some of these challenges. I believe open source is backbone of the modern tech industry with major projects backing areas from IET to cloud orchestration. And I'd like to just start by showing some of my favorite open source projects. For example, did you know that there's open source for quantum computers? Quantum Qiskit is an open source software development kit for interacting and working with quantum computers at the level of pulses, circuits and application modules. And this is one of my favorite case studies. NASA consumes open source. One specific example is their use of Node.js. NASA uses Node.js to aggregate data from spacesuits. In 2013, an astronaut found himself in grave danger because water was leaking into his helmet. From this, NASA decided they needed a solution to aggregate all of the data from spacesuits to create an alerting information system. They chose Node.js to do this. You can read the full case study on the OpenJS Foundation. I think it's pretty cool that they're using open source in space. With open source being so prevalent in our industry, I probably don't need to convince you all of the benefits. But these are my key thoughts. First is that open source is open. This is good for access, accountability, transparency, etc. Open source is also community driven. Open source projects get input from a wider range of developers than what you would if you were developing internal cloud source software. This often leads to better solutions. And you also benefit from more eyes on the code. This means we've got more eyes to catch bugs and also hold code quality to a higher level. Open source also enables us to build a partner work of others. This means we can reuse already implemented low level APIs to save us time and save us having to reinvent low level technical implementation details. This means we can focus on our product and our business logic. For example, in the Node.js and JavaScript ecosystem, there's over 1.5 million modules on the NPM registry. So there's a high chance that one exists to make your life that little bit easier. And notice I've straight out free. Although open source can be free in terms of cost for usage, I wouldn't say it's free because there's a cost in terms of risk. And from an open source consumers perspective, I think these risks can be grouped into five key areas. Security, licenses, maintenance, breaking changes and compatibility. In terms of security, if you're consuming open source as dependencies of your project, you need to be equally concerned about any security issues or vulnerabilities in your open source dependencies as the code you've written yourself. You're responsible for all code you have deployed in production, not just the code you've written. As a consumer, you need to be aware of licenses. Particularly, you need to ensure the licenses of the open source you're consuming are compatible with your project and how you intend it to be distributed. I think maintenance is perhaps the biggest risk when consuming open source. If you're building a project atop of open source, you need to ensure the projects you're building upon continue to be maintained for the lifetime of your project. And then there's the risk of breaking changes. As your open source dependencies are likely to be maintained by someone else, there's a risk that the open source project may make a change that is not compatible with your usage. Compatibility is another concern. When choosing an open source project, you need to ensure that the project is and will continue to be compatible with the platforms, versions and runtime versions you intend to support in your own project. I think all of these risks are widely spoken about from a consumer's perspective and there are some known actions you can take to mitigate against some of these risks. For example, for security, there are a number of tools and commercial services that can alert you with known vulnerabilities in your open source dependencies. Some of these tools will go a step further and automatically update your dependencies for you or patch them when a fix is available. For licenses, many consumers will have a list of accepted license types that can be included in their projects. Consumers that build commercial projects will often have more stringent legal review processes in place to order any licenses of open source dependencies before they can be incorporated into their products. As a consumer, I believe there are two key ways in which you can reduce your risk in terms of maintenance and ensure your open source dependencies continue to be maintained. The first is to contribute back to your open source dependencies. This directly helps to ensure that your dependencies will continue to be maintained, but there are further benefits. By contributing back, you'll gain a greater understanding of the dependency code and also have a seat at the table in any future decisions. If you are unable to contribute time to help maintain your open source dependencies, the other way of doing so is to contribute financially. Many open source projects have funding schemes set up where you can donate funds to help support the maintainers of the projects. Again, as an open source consumer, you can reduce your risk of unexpected breaking changes by participating in the open source communities that you're depending on, in particular by commenting on issues and reviewing pull requests. You can also go a step further by producing some automation that will test your project against nightly versions of your open source dependencies. To reduce your risk in terms of compatibility, you should first ensure and selecting your open source dependencies that the platform and version support matrix of the open source projects aligns with the intentions of your own project. Also, if there's a niche platform that you want to ensure continued support for, again, contributing back via funding or participation is a good way to reduce the risk of the platform being dropped. So that's some risks and some mitigations from the consumer's point of view. I'd like to flip that now and take a look from the maintainers perspective. From the maintainers perspective, I think the key risks can be grouped into the same five areas. As an open source maintainer, in terms of security, the biggest challenges I experience are actually the expectations around security vulnerabilities. Many companies and organizations have defined windows in which they expect security vulnerabilities to be patched by, but these defined windows don't translate to open source projects. Many open source projects are people's hobby projects or side projects, and they may not have the capacity to produce a security fix at such short notice. Work bounty projects can actually be a challenge here because they incentivize security researchers to identify vulnerabilities in open source projects, but there's no incentive to help the maintainers patch these vulnerabilities. Again, this can lead to the maintainer being overwhelmed. As a maintainer, I need to ensure I have chosen an appropriate license for my open source project. This is not only to enforce how I wish the project to be distributed, it's also to protect myself from certain scenarios. If you are unsure on which licenses to choose, I tend to look at chooselicense.com, which gives a nice overview of some key license types. As a maintainer, it's probably not surprising that maintenance is a big concern for us. In particular, there may be expectations from consumers that we will deliver bug fixes that we will respond to feature requests. This is particularly a problem in the Node.js ecosystem. Many modules on NPM aside in hobby projects, and when these get super popular, a maintainer can be very quickly overwhelmed by the influx of issues and poor requests. There's also the issue that if at some point, I no longer have time to maintain the project, what will happen? I think a good example that demonstrates why both maintenance and security are key risks for maintainers is the event stream incident. This actually started as a social engineering attack. In this case, the maintainer of the MPM module no longer had time to dedicate to the project, so they put out a request for a new maintainer. The attacker appeared to be acting with faith and offered to take over maintenance of the module. After some period of time gaining trust, they published a malicious release that contained code to mine bitcoins. And I really think this highlights the need for some defined processes for handing over popular dependencies. I think this example also highlights that security and maintenance are risks for maintainers, just as they are for consumers. Raking changes are a concern for maintainers because they're the ones having to make the call on what changes are made. But the issue from the maintainers point of view is we may not know who is depending on our project. We may also have the problem that a bug from one user might be relied upon as a feature for another. And when we're making changes in our open source projects, there's not really an easy way to test the impact of our changes until after the release has gone out. The challenges our experience from a maintenance perspective in terms of compatibility are the expectation to support new and niche platforms and the expectation to maintain support for older platforms and runtimes. In some cases without help, we may not just have the capacity or access to actually support these platforms. I think the key overarching problem that all of these challenges stand from is the mismatch in expectations between the consumers and maintainers of open source projects. We've talked a lot about problems, but what about solutions? In the context of the NodeJS ecosystem, we've set up a working group to try and tackle some of these problems and come up with solutions. The NodeJS package maintenance team was established in 2018 as a team who wanted to focus on reducing the sources of friction to module ecosystem adoption, particularly in the enterprise. At the time, it was known that the highest level of comfort was with open source packages that were stable, had ongoing maintenance, predictable releases, and were easy to upgrade to new NodeJS versions. But unfortunately, at the time, it was also known that there were a number of packages that were broadly used in the NodeJS ecosystem that were no longer getting the basic maintenance they required. The package maintenance working group is comprised of members from a wide range of companies, from the likes of NPM, IBM and Red Hat, Netflix, and more. And we also have representation from both consumers and maintainers. And all of the risks and challenges I've mentioned today are areas that the NodeJS package maintenance team were exploring. The working group has several key aims, the first of which is to document best practices and processes for Node module maintainers to follow. Another aim of the working group is to promote sustainable and responsible consumption of open source Node modules. Another aim of the NodeJS package maintenance working group is to provide a space where module maintainers can ask for help. In the past, we've been approached by module maintainers who no longer have the capacity to maintain their modules. And we've successfully recruited a group of trusted maintainers to go in and help out. The package maintenance working group is aiming to define and document a comprehensive set of best practices for module maintainers, covering areas such as licensing, security, testing, versioning, and more. For each of these sections, we bring together the maintainers and our group to discuss and agree on the best practices. All of our documentation is available when the package maintenance repository, which is at github.com slash NodeJS slash package dash maintenance. For example, in terms of support, the NodeJS package maintenance working group is exploring whether we can expose support information in the package JSON file. For example, here we have defined a response type, which is time permitting, paid, which is false, and that would indicate whether there was any paid support available. And also what backing the project has is a hobby project or is the project backed by a corporate sponsor. We are also developing tooling to extract this information so that a user within NodeJS project would be able to run a command line tool and it would output all of the support information from their dependency tree. Our key next steps on this are to encourage adoption. This is a specific example by the NodeJS package maintenance working group of working on solutions to solve that mismatch in expectations between consumers and maintainers. Via the NodeJS package maintenance working group, a number of NodeJS module maintainers have gotten together to start building tools to help solve some of our common challenges. We're building these tools under an organization, on GitHub called PKGJS, which we describe as tools for package maintainers by package maintainers. An example of one of the tools that we've created under the PKGJS GitHub organization is the dependence tool. This tool helps module maintainers answer the question of who is depending on my project. So in this example, you can see with supplied tool with the package name Express and number five and sought by downloads. So what this will return is the five most downloaded projects that depend on the Express module. This information is really useful for open source maintainers as it allows maintainers to discover their downstream dependence. Once they have this information, they can bear these dependence in mind when making key decisions in their project, such as breaking changes. Again, this is all about bridging the communication and expectation gap between consumers and maintainers. So that's some of the work the NodeJS community are driving to try and alleviate some of these challenges. So I've shared some thoughts on the challenges of open source consumption from both a consumer and maintenance perspective. I've also introduced the NodeJS package maintenance working group. If anyone has a particular interest in following or joining the working group, please do reach out. Or if you'd just like to learn more, all of the NodeJS package maintenance meetings are streamed live to YouTube. If you'd like to see more of the discussions we're having and work we're doing. And although prevalent, these challenges are not unique to the NodeJS ecosystem. My expectation is that we'll start seeing similar discussions across run times and technologies with the potential to collaborate on solutions. My key little thoughts are that I believe as a consumer, the key way to reduce your risk of consuming open source is to contribute back to the open source projects that you're depending on. I also believe the key challenge as a container is to manage the expectations that your consumers have.