 I'm Langdon White and I work on Red Hat Enterprise Linux as a platform architect. And so what that really means is that I mostly work in Fedora. And we're currently working on the Fedora modularity project, trying to look for how do we make application life cycles independent from each other without losing all the advantages of a distro. Red Hat software collections are based around kind of the Gartner paste layers. The idea of the systems of differentiation. So basically the kinds of applications you want to write to differentiate your company from your competitors. And as a result, the software that you write in that kind of space, generally speaking, has a shorter life cycle than something like a system of record. So unlike your ERP that you spend a million dollars and build once and run forever, as if you can write, that's a great thing for native rel. When you use software collections, it's more targeted at the applications that you want to refresh every couple of years. And so you're going to come back to it. And as a result, when you're using the software collections, they have a much shorter life cycle than native rel, it's two to three years rather than ten years. And so you want to make sure that you're picking the right kinds of applications. Red Hat software collections are kind of almost eclectic mix of tools that you use as a developer, both kind of on your desktop, but then also in production. So it's kind of anything with a runtime. So things like Python, for example, or Ruby, or Node.js, or whatever. And then we kind of also have some of the servers that you might use to build kind of typical applications, so like Apache, HTTP, MariaDB, Postgres, those kinds of things. But it's generally speaking, the set of tools that you want to use as kind of more cutting edge, they're changing a lot. And you need to do the development locally, and then you deploy its production using the same components. Sometimes when people look at the software collections, they're not always sure why we include the components to be included. And what we do, actually, is we look at certain kind of use cases that a developer might want to do with the software collection. And that kind of drives what we put in that particular software collection, especially around libraries. So one of the examples is Drupal. So what we do is, for the PHP collections, we actually say to ourselves, it's like, if I wanted to just immediately install Drupal, let me include all of the things that I would need to do that in the PHP software collection so that I can kind of say, yum install, PHP, SEL, whatever it's called. And then I could essentially download and run Drupal and be done. Red Hat software collections are not kind of just the actual component themselves, right? They are things like Node.js, for example. It's not just Node.js you get, you actually get a bunch of libraries that Node.js uses, and we include those in the software collection. We often get asked, how do we choose which things go in that bucket? Well, honestly, what we do is we kind of think about certain use cases that a developer might want to get to. So, for example, in the Node.js case, we look at Express. And we say, okay, if you do yum install Node.js, they should be able to immediately kind of run Express afterwards. Many developers using software collections, so, for example, with Node.js or whatever, obviously continuously there are new libraries that a developer might want to use that we just cannot keep up with, right? Nobody can keep up with. So the developers who are using those components, they often will identify certain libraries they think they're comfortable with using, et cetera. And there's a lot of due diligence there, there's a lot of work there to make sure that you're choosing libraries that are solid and have the life cycle that match what you want, et cetera, et cetera, et cetera. And what we normally recommend for how a developer should then kind of say, okay, I'm choosing this library and I'm using it, is they actually should include it in what we refer to as a dependent software collection, so that you have a kind of almost another software collection that it depends on the one we ship. And then that is actually what gets deployed to production. So there's a bunch of articles and kind of how-tos and that kind of stuff, both in the customer portal and in developer blog about how to make dependent collections and how to kind of approach the problem so that you're making kind of good RPMs that are useful and good for production. So you've heard about software collections and you know that the Python that's in there is interesting for you because the guy down the hall told you it was useful. It's important to take a look at what's actually else is in there because it's not just other languages, right? It's not just Node and Ruby and stuff you're not really interested in. It's also things like Apache and Nginx and MariaDB. So I highly recommend that you check out the developer blog, look at the software collections kind of tag and look at what else is in there and at what uses people are putting software collections to because all of that stuff is kind of covered on the blog website. And it's easy because as we kind of talked about earlier, it's kind of an eclectic mix and it's important to kind of see what else is in there because you might be surprised that there's things that are useful that may not be obvious if you just think about it from a Python perspective.