 But this is fine. I'm happy to leave this on. Oh, or just get rid of it. Leave this, or you can here, when it's running, yeah. When it's running, and you need to, I think it's mainly in this kind of, you would need to switch between slides. But I'll have to plug something in, right? Yeah, the USB thing. Yes, I know what the USB thing is. Unless Jim has taken it with him. Yeah, I will, I will ask. Can I use your laptop help a little bit? Yeah. I think it's very, it's, right, 11 seconds. Yeah, I think. And I stole the CoroS and the CoroS. OK, so CoroS. I've just stolen CoroS user. You focus on the complete, complete the end, or? Yeah, on the other side of the screen. How simple is that? How simple is that? How's that? Yeah, fine. Hi, our next speaker is Karambir Singh from the CentOS project. He's the project lead, and he's working at Red Hat. He'll be talking about open source focus on the user end and how CentOS fits in Karambir. Thanks. Is my talk done? So hi guys, my name is Karambir. I'm from the Muslimin SKB. I don't have a lot of slides, but I thought green looks like a nice color, right, it complements. Because even I'm looking at green and you guys are also looking at green now. So is there anybody here who doesn't know about CentOS? You don't count, you're wearing a shirt. OK. So what do you know about CentOS? OK, sounds good. But so you're actually at Red Hat. OK. There's basically two different takes on CentOS, right? CentOS the thing, and CentOS the bigger word, CentOS, right? And I always like to make sure that there's clarity on what we mean and where we're going with it. So on one hand you have the CentOS Linux distribution, which is built from sources of Red Hat and Pres Linux that is released publicly or whatever. And that's CentOS Linux. But there is this other thing called CentOS, which is the CentOS project. And amongst other things, one of the things that we do is build and release the CentOS Linux distribution. There's a lot of other stuff that also happens on the edges, a lot of things that happen in the community space and a lot of engagement opportunities and things like that. And I think it's easy to miss that part of it because there's a very big expectation in open source about everything being about open source. It's kind of hard to look past the fact that you can have communities of users and it's very easy to look past the fact that, look, this guy doesn't write code. He can possibly be a part of a community. How many people here think of open source as being a disruptor? Versus how many people here think that open source is the new normal? So when we say open source projects, what we're really talking about now is modern day software processes, software projects. It's no longer about the one hipster guy in a room full of 700 who writes open source. It's pretty much expected that most innovation that happens these days, that's coming out, is open source anyway. Now, in my opinion, there's four key aspects to any software project. The first part of it, the first key part of it, and I think the most important part of it is that at the end of the day it is still about software. So if you're writing software, it should ideally be good software. It should ideally be software that solves the problem. It should be a software that people actually want to use. If you're writing software for yourself, you're not really doing a lot in the community space anyway, especially if you're not going to give it away or if you're not going to do open source or whatever. So step one, and I think the most important part of being in a successful software process as such, is to have a piece of code, a piece of software that actually solves a real problem. So that's one part of it. The second part of a software process, especially for more relevant software processes and software projects is that you need to have a responsive maintainer group. It could be the authors. It could be the people who help the authors of the software. It could be the documentation people. It could be curators in the community, whatever. I mean, whoever you call the maintainers need to be responsive. If people come up with a request, there should be somebody they can point the request at or if they come up with a bug report or a feature request. There should be somebody there who can take that on and then talk to them about what it is that they need, what it is that they want, where they want to go with it. And that becomes, again, a key part of the first wrapper on top of the onion, figuratively speaking. You've got the code, you've got the onion, and the first wrapper really is to have a really good responsive maintainer group. The third piece of the puzzle that is important for any relevant software product and software processes is that you need to have a community that you can address. And when you address that community, a key metric you need to be able to communicate into that community is a confidence of continuity. But if somebody's going to come in and talk to you about, hey, you've written this great lib that I can use to make my file smaller, right? I'm going to invest with you. I'm going to write my software using your particular software. He or she needs to have the confidence that by investing in your setup or by building something on top of your setup, they have some level of assurance of continuity. It shouldn't be, hey, I wrote this piece of code back in 1997. Throw it up. And I'll see you in 20 years' time. So there needs to be that confidence. You see what I mean? There needs to be that confidence that you have the code which is doing relevant stuff. Is that me? There's something moving. OK. Let's try that. So you have the code, right? So hopefully solve the problem and solve the problem in a space that people want to consume the software. And then you build up a great maintainer relationship between that, between the community and the product or the process or whatever it may be. And the third part of it is then you want to be able to communicate into your community some level of confidence. And it comes in many ways, right? They should be confident that your software, if it has vulnerabilities, will get patched. If they have an objection to assume you have an IRC channel and some guy is being really awkward and he's undergoing a pain or whatever. They should have confidence in being able to approach the maintainer group. And the maintainer group should then have a process or whatever that they can address some of these issues. Even if it may be, even if your process is, we'll think about it. Even if the process is, we'll see what we do on a case-by-case basis. I'm not saying you need to go away and every software project needs to have a whole set of governance rules or whatever. But there needs to be something in there. And then finally, you need to be able to communicate a sense of continuity that there is a reasonable effort that is going to go into this particular piece of software. We are going to keep it going. In many cases, especially, I'm guessing a lot of people in the room are actually working forward on that. And in many cases, and increasingly so, especially stuff coming out of the Western world, increasingly software processes and software projects are backed by vendors where there's money involved. People are not doing this as, you know, hey, this is what I did after my dinner on Friday night and before I went to bed. This is actually people working on software from Monday to Friday. And which means there's more structure to the whole process. There's more organization around it. There is ways and means that you can address resources and stuff. But that confidence for continuity still is something that has to be communicated into the user base. Does that kind of make sense? Is there anything that somebody wants to talk about? No? Okay. So the fourth critical piece of any software process is that it's nice to have users. You know, you can write the best possible software that you want. And you can have a really good, responsive, maintainer group, right? You can have all the interfaces set up. You can have really good communication. You can do whatever you want. You can have a really good community of your piece of software. But at the end of the day, you still need users, right? Now, this gets slightly sorted with the same argument that I made like a minute ago, that increasingly open source processes in open source software are backed by vendors. And you could potentially argue that the upstream downstream relationship has kind of eroded from the user space, from contributor space to being the project upstreams and then the user space actually being the product users and the product consumers. Not so much as the software process it's up. So it could be, hey, I developed the software in open source. It's on GitHub. Fantastic. I'm joined me. And if you want my biographies, have your credit card number ready and call 1-800-my-new-database.com, right? And that's fine because that fits into the paradigm of open source software. If somebody else wants to go and kind of create interfaces in there, somebody else wants to go create a forum or an IRC channel or whatever, they're welcome to do that, right? How welcoming those external interfaces to your product or to your process are going to be within the upstreams of the processes. Again, a key metric that people will look at if they're trying to figure out how confident am I that the software is going to exist in six months' time? How confident am I that if I invest, building my storage solution on this particular piece of software, it's still going to be relevant in a year's time or two years' time or whatever. So it's part of the vendor engagement. You still need to build the bridges. You still need to have those confident loops that you kind of communicate with. And in that case, the user space changes a little bit, but you still need users, right? There's no point in writing software that nobody's going to use. I mean, you could potentially argue that there is a lot of point in writing software that you want to use yourself, right? In that case, you are the user. You are the maintainer. You are the contributor. And then it's up to you to figure out how are you going to use it, how are you going to deploy it like years from now, whatever, and if that even means anything to you or not. In most cases, I don't know if anybody here disagrees with me. It's nice to have that second user, you know, somebody who uses your software that isn't somebody who also writes the software. Is that a reasonable assumption? Yeah. So, yeah. And what happens is that in many cases, it becomes hard for an open source project to take the first step, right? How do you announce what you're doing? So you can take your content. You can go to a conference. You can find, if you're into storage technologies, you can find a storage conference. You can go there. You can tell everybody about this great thing you've got. You might get some traction there. You can get, you know, journalists to write about what you're doing. You can do a couple of interviews. You can, you know, set up some sort of a viral Facebook campaign or a Twitter campaign, you know, of monkeys jumping out of a car while they deploy a storage solution, right? And then you hope that that creates a funnel that on routes into... So you can do all sorts of various things, right? So this is where I think CentOS kind of fits in because there is a certain demographic of users who invested very heavily on CentOS, right? For whatever they were doing over the years, over the last 10 to 12 years that we've been around. And it's a very specific kind of a user base in that, firstly, it is distinctly a user base. There are very few developers who just consume CentOS and participate in the community process. There are a lot of developers who use CentOS to do different things, interesting things, but they typically go and do it in different environments, right? So again, staying with our storage examples. There are a lot of people who build storage solutions on CentOS, but they typically go and do it on their own in their own space and et cetera, and that's fine. That's a part of the open source process, right? But the people who engage with us, the community space around CentOS is very, very, very heavily user-influenced. And in that space, it's very, very, very heavily skewed towards the operations, towards the sys admin, towards the infrastructure side of things. And we do have desktop users. I think one metric that we dug out was there was a critical Firefox update. And we said, if we can find out how many people download that update, we can probably try and work out some metrics on what percentage of the CentOS user base is actually running Firefox, therefore, desktop users. And I think the number we came up with last year in the late summer was about 18%. So about 18% of CentOS users use Firefox, which is interesting, which is a lot more than what I thought it was going to be. But the other metric in there is that what are the other 72% of the people doing? Or are the 82% of the user base. And that kind of reflects on this queue, that is there in the community space. And that cascades down to people who are on our actually channels, people who are on the mailing list, people who engage with us, people who come and talk to us at conferences, people who go and talk to us at conferences and things like that. And then that presents a great opportunity for other projects who see an audience. Let's try that. There's probably a loose cable somewhere. Okay. Wow. This has suddenly gone into a stereo sound or something. If I'm moving it down a bit, then the mic is away from me. Is that better? It needs more user testing. Right? So yeah, so on the CentOS side of things, there's a massive skew towards infrastructure projects and towards assignments and operations people and stuff like that. What also happens is that there are certain values that people can derive from CentOS Linux, right? Which is what makes the REL equation so interesting. There are some big companies who have invested very heavily on CentOS because they want to use it land that they can predict, but they don't want to use the kernel in CentOS. They're on their own mainline kernels. There are other people who don't want to use the Ruby stack in CentOS. They want to do their own Ruby stack. And CentOS is a great place to come and do this because there's no support, right? You get the agony on kind of support. You know, you can go to a mailing list and say, oh man, my system broke. And everybody will be like, oh, very sorry to hear that. I mean, beyond that, there's very little in terms of SLA support you can get. But what you do get is you get a community of users. And sometimes that can be dangerous. Like the other day, there was a big service outage on the internet and they had a LVM issue. And they were complaining. And all of the advice they were getting was, have you tried ButterFs? Have you tried ZFS? And he's like, look, I've got eight years of having used X3 with LVM. I am not going to go away and now deploy ButterFs or whatever. So community support can be kind of useful as well, but it can also be kind of weird because everybody has their own opinions. But beyond that, if you know what you're doing and if you're in a space where you want to own a particular piece, then CentOS is a great place to do it because the rest of the environment around CentOS doesn't change, which is effectively what the real proposition is that deploy today and four years, five years from now, you'll probably have the same version of Ruby. You'll also have the same version of the kernel and the same version of Python. So if you now want to go and tweak one piece, you can then own that piece and only own that piece, right? Which tends to be a really great place to be if you want to build a user story around a particular piece. And what we've been doing on the CentOS side, and I think if you guys were in Fabian stock, Brian stock, Jim stock as well, you'll see that what we've done exceedingly in the last sort of two years and hopefully some part of it we're doing well is that we've gone out and we've extended the ecosystem around the REL code base. So we are building for architectures which REL doesn't support directly, like ARM v7, ARM v8. We have a 32-bit build for EL7, the code base itself. There's some stuff happening now on Power64 and Power64 LE. There's been somebody talking about MIPS as well. And what that really does is that it expands the scope of where you can now take your project, right? Now, within having said all of that stuff, what we try and do is we try and curate an environment, right? That takes away the pains of engaging with the community from the upstream projects itself. Again, staying within the storage paradigm, if you were to take somebody like GlusterFS or Seth, they already have mechanics in place that allows them to build, test, and deliver, right? They already have ecosystems that rely on them. For example, the OpenStack environment is very sort of wired in with the Seth area. What's Seth doing? It's kind of interesting to what's happening in the OpenStack areas. Similarly, what Gluster is doing is very interesting to other projects like people who do cloud stuff in EC2. There's a lot of Gluster in there and people like Overt consume Gluster. So there's a lot of engagement there already. And then the end users who consume a lot of this stuff already have upstream engagements as well. So what we're really trying to do from the CentOS project side of things is that we have the base, we have the users, and people who now want to go away and now think about storage, they should have an easy on-ramp, like maybe two steps, to be able to deploy a storage solution. And that is effectively what we're trying to curate on this side, is that don't change your developer experience. Don't change your bug triage or your patch or your vendor engagement or your maintainer engagement. But work with us to help bring your product or your project down to the CentOS user base to make it trivial for people to experiment with code and make it trivial for people to actually consume the products and stuff that you're shipping out. Does that kind of make sense? Again, if anybody wants to talk about stuff, feel free to just shout out at me. I'm happy to talk about stuff as in one. Okay, so... Is it? Okay, I'm happy to do that. Let me reach into my back. Hello. Is it on already? Okay, this is good. Now I don't have to listen to myself in 3D audio anymore. How's that? Hello? Hello? Yes, no? There's a light on. So I wonder what the real-time kernel story is. We probably need a faster boot set up on this, right? Yeah, so if anybody wants to talk about stuff, feel free to reach out. And again, going back to typical open source projects, right? We'll have the workflow already in place. You have your source control stuff. You have your build mechanics. You'll have your test mechanics, whatever they are. And what we try and do, Brian touched on this briefly, is try and provide a really great build environment. Try and provide a comprehensive test environment. How you use it, of course, is up to you. But we try and provide as many options as we possibly can in the test environment. And then we try and provide as many delivery mechanisms as we possibly can. And then try and provide some sort of user engagement beyond that product and process as well. I've got a couple of slides. Let me see if I can get that on. And then we can try and... We can get that on that screen. But Brian touched briefly on the chunk of what this is, right? So typical open source projects will have the build test to release stuff. And this is sort of what we have in place right now. We have an environment that people can build in, we can test in and deliver from, right? And then there's the whole feedback loops and stuff. So I'll just quickly try and see if we can walk through what that typically looks like in one implementation, right? And it's something that isn't there yet. We did it yesterday on the container pipeline side of things. So what we're doing is we're trying to build an environment that allows any project, whether you are already engaged with Santos or not, to come and build their container story with us. So if you want to get into containers, then if you want to do it as a project, and now if you want to deliver it to an existing user base, the easiest way to do it is to actually find somebody who knows what they're doing, learn everything that is to learn about containers, and then try and build your own story, right? And you may or may not get any traction. So what we're trying to do is take that pain away so you have a GitHub repository and we'll just take that from you and build your container story for you. So what that typically means is there's an input process, right? Which comes in from whatever. In this case, I think we've got the upstreams, which is just to get repository somewhere. And you could be a project anyway. You don't have to be engaged with Santos at this moment in time. Or you could be using the atomic developer bundle. Does anybody know what the atomic developer bundle is? The ADB box? Yeah, okay. Not a lot. So you should go look it up. This is quite fun. Especially if you're getting started with containers, it's a good place to start from. So what we'll do is we'll take the input that you're pushing through, we'll build it through something called the container index, right? It's an easy thing to get into. It's literally a GitHub repository. You clone it, add in your details, request to merge, and that gets merged in. And literally that's the only interface that you'll have with the entire system. You don't have to sign a CLA. You don't have to get involved with legal stuff. You don't have to sign up for an account or stuff, anybody can join in. There are two constraints though. The software has to be distributable and redistributable because the entire build is public. All of the stuff that happens in through the process is public. So you have to be okay with that, right? The second part of it is that if you're using any custom tool chain or if you're using any binary blobs, then you have to have the ability to distribute and redistribute. So for example, we welcome NVIDIA's binary blobs or firmware stuff if you want, for example. But you just need to have that conversation with NVIDIA and make sure that they're okay with you distributing it. Not us, right? That ownership of the code is up to you to kind of figure it out. Then we provide mechanics in place for people to test that kind of environment. So you do the build. The container gets built or the source gets built. You push it into a test environment. And the tests can either be user-relevant tests or they could be... What am I talking about here? They could be imported payloads. So you could set up your own scaffolding. You could do international tests. You could do integration tests. You could set up your tests to rely on other projects as well. And it's all fairly simple to integrate in, right? The mechanics for this already exist. And then, based on your test environment, if you want a feedback loop that says, hey, you know, something happened or something broke, then you can go back and you can iterate, build test, build test. Still such time as you're happy to kind of move that forward. Now, the key part of this, and I go back to a few times, is that there is no user interface for you to engage with. So how you get your project in sending in the GitHub pull request. And all of the feedback that you get is based on an email address that you give us. There is no web interface that you can go to. There's no account to sign up to. There's none of that kind of stuff. So if you're working in a vendor environment, basically it's key there that there's no agreement to sign to use any other stuff. Now, when you're ready to release, we have a couple of ways that you can release stuff into, right? Which is where we do the validation stuff. And on the container pipeline, this is how we're implementing it. That should be up, I think, in the next couple of weeks. I think End of Feb is the target to having that up. What we do have right now is we have CentOS Linux running in Native Hosts that you can deploy Docker Kubernetes into, do your validation and all that stuff. We've got, I think, we've got a dozen odd machines running, or VMs running CentOS Atomic Host. So you can do your validation in there as well to make sure that things work, CentOS Host, CentOS Atomic Host. And then we also have an on-prem story which, at this moment in time, we're trying to figure out, it's going to be OpenStack. I think Brian touched on this as well a little bit. That OpenStack instance is not up yet. So how we're doing the on-prem story right now is by using public cloud instances. So we have a slice in rack space that we can deploy 30, 40, 50 VMs into and tear them down all the time. And then we have a much larger chunk of infrastructure in EC2 which is, again, sponsored by Amazon. And we can do validation in that place which also means that you can validate on just a generic image or you could validate inside the elastic container service if you wanted to, if you so wanted to. But longer term, our plan is to take that off, bring it all in-house, run OpenStack within the CentOS infrastructure and then let you kind of test against that. Another key part of the testing infrastructure or the validation infrastructure over here is that we give you access to the resources backing it, right? And the way that it basically means is that if you want to deploy your own OpenStack, you can do that as well. There are mechanics in place that let you deploy and then do your validation. If that is what you want to be validating, right? If you want to be consuming OpenStack as a through an API, we can give you the whatever APIs you need. So if you need a glance access, we can give you that. If you want a swift access, we can give you that. If you want horizon access, we can give you that. Or if you want to abstract it away, we have a very thin layer called Duffy which can't do OpenStack yet, it can do bare metal. But we hope that soon it will be able to do OpenStack instances as well. Then moving on, what we do is that because I kind of briefly touched on this anyway. So we have bare metal, right? All of that stuff gets validated there. It gets validated in a virtual environment, like whatever if you're running, for example, in OpenShift or if you're running in containers. And we do it in vendor clouds. So things like EC2, Rackspace. And I think there's 62 different vendors who participate in the CentOS instance sake. And we validate across all of them if you want to. So you could go and validate, for example, against ByteMark. Linode and DigitalOcean unfortunately are not there yet. So if anybody here knows anybody there who can help open those conversations up, that would be quite cool. But there are 62 vendors that are participating in this space. And what we do is that because you're a part of the CentOS ecosystem, because you're building with us and you're testing with us, we let you use our credentials into those environments to validate content for those environments. Does that make sense? So basically, I'll give you an example. One of the things that we're doing with OpenShift is that OpenShift is soon going to be building their entire content, OpenShift Origins into CentOS. And then we will bring up an instance of that within CentOS itself, and that's slated to happen by the end of February. But what we're also going to do is we're going to put OpenShift inside VMs and then use the CentOS Amazon Marketplace to expose OpenShift through the Amazon Marketplace instance. Similarly, use the Google Compute Marketplace instance and the... And without going into names, the 62, right? So let's stick with that number. So there's 62 different environments that we can then expose that particular content into. So if you're in the storage business and that is interesting, then you don't have to go build those relationships. You can consume the relationships that CentOS already has in place as a project and exploit those for whatever the requirements might be. Like one of the things that we're working quite hard on right now is Atomic Host. How many people here know about Atomic Host? Not a lot. You should... You should all... The rest of you should all kind of start reading news media. Well, Atomic Host in a brief... In a very brief kind of way is a different way of looking at a distribution where you can't install and remove packages. You get a complete baseline that you live with and then you do an upgrade every six weeks to four weeks or whatever and the only way to get the upgrades in is to reboot. And the primary... The driver there being that you don't install and remove apps. You install and remove containers or payloads and then you join larger clusters, etc. So it's a different way of looking at distributions but it's a great way to run containers. And what we're basically working on right now is to enable those 62 vendors to ship Sentos Host at Atomic Host to all of the people who want to consume Atomic Host in their environments. And we've had mixed results because like in this audience, I'd say half of the people know what Atomic Host is and that's the same problem we have in hosting or in vendor space that a lot of them are, but what's wrong with just Sentos? We're like, well, nothing's wrong with it. This is just a different way of looking at it and it's better in certain ways and it's worse in certain ways. But now what happens is if you're a Sentos group or if you're building with us, you get interfaces into that environment as well without having to build those relationships and I think that's a key part of the value proposition of engaging in the user space that a lot of these guys are not talking to developers. Like EC2 has a developer paradigm but EC2 is in business because of the users who come to consume EC2 services. Rackspace, right? Rackspace has developer interfaces but their primary interface to the world is the user side of things and that is what we try and do. We try and build bridges into those environments. So we take those areas and then what we were talking about earlier is enablement across architectures which is also what we're happy to do and if you have payload that you want to bring out into different areas, you don't have to look for the hardware, you don't have to look for the enablement side of things, just come and consume what we're doing, right? That's probably the complex picture which most projects don't want their user stories to look like, right? If you have to start to use it off at that end and then explain this whole thing to them before they can get to your software, that's a bit of a problem, right? But what happens is as a project, as a technical project doing development work, this sort of a process makes your life easier for the user story because the user story really just starts here at the bottom, right? Because before that is all stuff that you would own. You would own the testing, you would own the release cadence and all of that kind of stuff. So all of this stuff, right? What does it look like to a user? It basically gets summarized into one simple pipeline which is you have an input which is from Git and then you get stuff out of the pipe at the other end. And effectively your exposure to the user base gets limited to exactly that, that you have your Git repositories with your content in and what you get out at the other end is packages that have had the benefit of going through this particular process where you can cherry pick that, hey, I want this, this, this, I want to test this, this, this, I don't want to test this, this, this. And that is the big, that is, in many ways that's a big value proposition of working within the CentOS ecosystem, engaging with the user space, right? That you can summarize that entire technical setup, right? That entire background of what happens, the entire factory as it were, on what happens to software from one end to the other end to, hey, I have a Git repository on one end and then you get consumable stuff at the other end. That kind of makes sense? So then again, going now, I'm just going to go back to where we started from, right? There are four key tenets to a good or a relevant open source or, well, we're not talking about open source anymore, right? It's a software process that produces projects. The first part of it is key, right? You have to have or you should really have software that is useful. If you don't have software that is useful, then that could be a bit of a problem, right? Because nobody's going to want to use it. So let's assume that people have software that other people want to use. The second part of it, the second layer of the onion is that you want a responsive maintainership. You want a responsive group of people who are going to maintain the relationships, who are going to maintain the software, who are going to be responsive to bug reports, who are going to be responsive to requests, and things like that, right? The third layer of the onion is that you want confidence. You want community-driven confidence that the community should know that if they're investing on top of your layers, and that could be either using a library that you create, it could be somebody running his business on the email server that you wrote, or whatever, right? So when they invest on your product or your process, there should be a reasonable level of confidence that there is continuity. I think that's a key part that a lot of people often miss, right? And then the fourth part of it is that you want a great user engagement story. And this is the part that Santos can really help you in, is to build a really comprehensive infrastructure that you guys can then consume without having to own any of this debt, right? As a single example, right? How many people here know what Jenkins is? How many of you have suffered the pains of Jenkins? How would you like us to just take that away and run Jenkins for you so you can focus on the code? And I think that's one of the key tenets here, right? So what we're doing is we're running this infrastructure for you. And even simple things like when a test fails, you want there to be confidence, right? That the test failed because of a code issue. You don't want the test to fail because, hey, one hard disk fell off. Or, you know, the network switch was down between two machines. Or the git checkout timed out and things like that. And for us, that is the confidence that we build into the user base, that is the upstream projects. And that's what we're basically trying to get to. So basically take this, assume the complexity of running all of this stuff. Make it simple for you guys to do your job, which is all of the arrows in the middle in there. And as far as the users are concerned, all of the relationships at the end, which is, you know, hey, here's the content go consumer. That could be good or bad. Nobody has anything to say. Right. We have, I think about Brian is at the back there. There's about 76 projects that are in this, in various stages of evolution. Let's not use the word use. Let's use the word abuse. The people who abuse it the most are the open stack upstream projects and audio. And then there are projects like James was doing a talk about management config. So the second person who's kind of abusing it quite a bit is James who's doing this management config software piece that is completely built and delivered and tested on our pipeline. And he's going pretty much across the board. The only thing that he's not doing with us is the sources, you know, the bit of the grade, the depth part of it, that he's got on GitHub. And that's fine because you can enter this process at any point you want. You can choose to just use RCI. You can choose just to use the source to binary build services, or you can choose to use both. You can choose to test on whichever environment you want, and you can choose to go to whatever architecture or whatever platforms you want, whatever vendors you want. What you can't, however, do is bring your artifacts in after the blue stage. So you can't say, hey, here's my process. Here's my project. Go publish it on Amazon. Feel like, you know, all the best. So you have to, so as long as you're involved in some part of the process, then you can go through with it. I think the software collections guys are doing quite a bit of the process as well. Again, they're doing the source elsewhere, but they're building with us. They're doing a little bit of testing with us, but there is CI there, and then they're delivering through RCDN at the moment only for X8664, I believe. But there are a couple of people who want to do it for PowerPC, and I know there's at least a couple of guys who've been asking about some of these components, like the newer LAMP stack for the Raspberry Pi for the ARM v7. But there are, I mean, the pieces individually all come together, and the different people who are consuming it at different scales. Does that can answer your question? Is there anything else anybody wants to bring up or talk about? Alan, hi. So the question is how do you do user metrics? We don't actually do a lot of user metrics, because it's hard for us to do metrics. I'm guessing what you're talking about is downloaded, right? So the way the CentOS CDN is set up, most of the people, most of the users would get their content from local mirrors. They won't actually get it from a machine that we run, which makes it really hard to track stuff. There are a few things that we do track, though. For example, for the CentOS deliveries that we push into Amazon, right? Anybody who hits a YUM update will hit mirrorless.centos.org, which is on our infrastructure, and then we look at where they came from and then send them to a mirror, which is local into their availability zone, so that the users don't end up paying for transit bandwidth to do YUM updates and stuff like that. So we can get some numbers around those, which is, again, very vendor-specific. And the other place where we do have a lot of metrics is IPv6 versus IPv4, and we can do density and things like that. But in terms of how many people actually did a download, we would have to figure that out on a project-by- project basis. So the second question might be like a relevant question might be that, A, how many people are downloading OpenStack from CentOS, right? And then a second question might be the ones who do what all components of OpenStack are they actually using? Because it's possible you guys are spending all your time packaging two pieces that nobody uses. And that's hard. That's hard to do unless we build something into like an installer or something like that. I guess the short version, the short answer to do those metrics, we'd be happy to work with you to build something up. If there's nothing else, then thank you very much for listening to me. Oh, there is another question. No, I mean, I don't say that OpenSource is one, right? I think so if you go back, right, I think so I'd say that if you went back to 1999 doing OpenSource meant that you were that one guy in the conference who knew what it was, right? And then God forbid you ask a licensing question, then you'd be like, I know there are three of us playing this to you. And I think that paradigm has switched, has changed quite a bit. And I think it's OpenSource as a software process is no longer considered disruptive. It's actually become mainstream enough. I'll give you a tangible example, right? Across the world, 97, 98, 99, you could organize a Linux user group meeting, right? You could order pizza, you'd get beer, people would bring the machines and you'd have install fasts. You'd figure out, right, this CD-ROM drive, this whatever build for it. And I don't know, I've been there. I don't know how many of you have been there, but increasingly you'll find that it is no longer viable, is no longer productive to actually have a Linux user group meeting anymore. But you can have software meetups. You can, and you will see PHP specific meetups. You'll see, you know, you'll see web engineering stuff coming up. You'll see even agile tools for agile practices. And what they're talking about, the tools they're talking about is that, you know, open source is no longer considered to be the strange beast in the corner, which is why, again, I think in many ways rather than talking about it as software, I think of it more as process. And the idea that you can have collaborative software engineering, right, in a medium where people who have access to the software is beyond just the developers and the product managers itself. I think that idea is catching on fairly well. There's a lot of people who are working for Microsoft as well. And even those guys have changed, you know, development processes to a point where they may not go to public spaces, but the way they work is still sort of, you know, semi-community driven. This is a, I mean, I would love to see open source win. I think there's a lot of miles to go before we get there. But my thing is that I don't think it's any more, you know, the most important thing. Thank you very much. Thanks, guys. Thanks, guys. So, trying the mic, trying the mic, trying the mic, and suddenly it's working. Come on. Yeah. So, yeah, still working, still working. Oh, this is pretty awesome. Yeah, well, yeah, it's working. Yeah, I'm just just just That's all for this video. Thanks for watching.