 a great time and Hugh's going to do the intros for our keynote. Thanks Langdon. So I've been working for Chris right now for about nine months since I started here in Boston. But I've been working with him since 2007, I think. Sounds about right. We worked together on Red Hat Zen, which was the virtualization of the future. It turned out that was a bad bet, but we had a great time, I think mostly a great time doing it. And Chris has been not only a force in Red Hat, but a force in my life and also happens to be about the most laid back person I've ever met. Which is kind of cool. Saran, by contrast, I've only known for about ten minutes. However, I know of her as not only a talented interviewer and a force for good and sanity in this bizarre world that we all work in. But also as a really interesting and engaging speaker. So I am really looking forward to having both of them share their thoughts with us. And please welcome Saran and Chris. I've never been described as a force before. I love that. Put that on my resume. Put that on my LinkedIn. Thank you all for coming. Really excited to see you all. I heard you had a great party last night. So kudos to you for showing up this morning. That is awesome. Go you. Chris, are you excited today? I am on West Coast time zone. Translation. Never been more excited. Actually, I'm really bummed that I haven't been able to make much of DevConf translation. I'm in the process of moving. I'm moving out here to Boston. And as exciting as that is, it's totally diverted my attention away from being able to be here. So this is my first experience at DevConf U.S. and I hope to make the best of it. So I think a good place to start is to figure out who's in the room. So we're going to do a little audience interaction. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yeah. Okay. Okay. So show of hands if you are a student. Raise them high. Raise them high. Be proud. Be proud. Student of life. There you go like that. Okay. Show of hands if you consider yourself an open source contributor. Raise them high, raise them high, raise them, oh, okay. Show of hands if you've contributed in the last six months. Oh, man, these are only serious people, oh my goodness. Okay, last month, oh my God, we're in trouble, Chris. Oh man, okay, very, very exciting. All right, so I think a good place to start is you are the CTO Red Hat, which sounds very important. And you've been in... I don't know what it sounds like. Very impressive, you're chief, very impressive. And you have been a software developer for over 20 years. How did you get started? My story is probably not that unusual. I got started as a kid with a gift from my grandfather, which was a Commodore, a Vic-20. I really wanted the 64, but it was a little out of reach. And I got excited about programming from that machine. And as a kid, also, I had an opportunity to go to a couple of courses that were taught at the local university, but were aimed at kids, just to learn basic programming. And I would say I got the bug there, although I didn't pursue it directly. And it was a little indirect. It was much later through school when I got reconnected through university, where I got reconnected with computing. And when I left school, I studied physics. And when I left school, I thought I have two choices. I could become a physicist and be the person that knows everything about the thing that there's only three other people on the planet you can talk to about. Also very impressive. Which would be cool. Actually, I really struggled with this decision. Or I could just do something different. And something different is what drew me eventually. And that was largely about Unix. And computers were still something that I found a lot of interest in. And even though the command line is arguably arcane, somehow I found it intuitive. And so that's what I did. I launched into computing at a university, deciding not to be the person that knows the thing that only three other people on the planet know something about. Well, it looks like it worked out. I'm not complaining. You get to sit here and talk to me, right? Yeah, yeah. Okay, so you, when you first got introduced to coding, did you understand that that could be a job? I had no idea. I was 12, so I was like jobs didn't exist. Job, to me, a job was, I thought, maybe being a garbage man would be really cool. I was pretty into the trucks. And a little, that's advanced thinking. And then that was when I was younger. And then by the time I was playing with computers, I was much more interested in sports. And I thought maybe just maybe I'd be a pro sports player. I wasn't sure exactly how, because I wasn't good enough at any of the sports. It just seemed like a fun thing to do. So you didn't have a sport in mind? No, I just had the concept. Makes sense. And then, so coding as a career was not obvious at all. And it wasn't necessarily much of a thing at that point in time. It was pretty niche still. It was in university where I realized it was a thing. And I thought, what a terrible sounding thing to do. Sit at a desk all day long, staring at a computer screen, writing lines and lines and lines of code. And then I got into it. Where did the time go? Well, the interesting part is now you travel all the time. So you don't actually sit at a computer all day, the way you thought it was going to. That's right, that's right. That's more recent. So I did spend a lot of time in front of the keyboard. And the thing that I missed the most in the beginning was pencil and paper. Because as a physicist, you spend a lot of time with math and math equations. And I loved the process of solving a problem and thinking about it, but also writing it down. And it took me about a year in my first job to get over not just working things out on pencil and paper. And it took me about five years to get over not writing things with pencil and paper. So I'd write a lot of documents twice, write it out, and then type it in. And today, it's the opposite. Keyboards are an extension of how I think. And so it's quite different. I'm a big fan of writing things down. For me, there's something about the process and it cements the idea in my head in a way that's different from typing. Absolutely, yeah. Okay, so what did open source look like 20 years ago when you first got started? What was the length? Because nowadays I feel like it's so mainstream, right? Like everyone's in it, heard of it, pretends they did like they do it. And so for you, back then, what was it actually like? What was that world like? I was exposed to one small corner. So I don't know what it was like in its entirety. One corner was, for those of you who were working on UNIX machines and ever used SunSight, SunSight was a place where you could get a bunch of awesome tools. And many of those tools were open source tools, notably the tool chain, GCC and Ben Utils. And shells, you could get bash, not this crappy UNIX, the UNIX native, whatever UNIX variant you worked on, UNIX native shells tended to be a little bit behind the times. Corn shell, orange shell, the shells themselves weren't the problem as the implementation with the UNIX specific implementation. So there was that. And then I really first got started as a user of Linux. I had all these, the job that I worked on, we used Solaris, both SunOS 4 and 5, so BSD and more AT&T derivative. We used SCO UNIX, we used Dynix, both Dynix and Dynix PTX, which would be similar BSD and AT&T derivatives. We used CUNIX and there might be one other, there might be one other UNIX derivative in there. And everything we did was with GCC, we didn't use any of the native tool chain on any of those platforms. And all of those computers were expensive and they were either pizza box sized or refrigerator sized and none of those, either size-wise or cost-wise fit in my basement. And in my basement I had no shortage of x86 boxes and a friend of mine said, you know you can get this thing, it's called Linux. And you can run it on that x86 box and it'll feel like you're running UNIX in your basement. Hallelujah, I don't have to steal a Spark box from work and risk getting in trouble. And that's how I got involved, really as a user. It was not long after that that I was responsible for the high availability of a platform as a telecommunications company. And in that world, Five Nines and HA is a really big thing. And I met a colleague who worked on this project called Linux HA and Linux HA was really my first experience in being a Linux developer or an open source developer. And the experience was really remarkable. It completely changed my life. I mean, honestly, not to be too kind of dramatic or hyperbolic, but it completely changed my life because coding at that point in time was usually somebody bequeaths you with this big document written in somebody else's language, describing a problem that you may or may not understand and describing a way to solve the problem which may or may not make sense. And then your job is to take that description, turn it into code. And so not a lot of creativity there necessarily and you're not necessarily understanding what's going on and there's this sense of the omniscient being that knows everything and hands you the tablet and being involved in an open source community where I could just communicate with people who were really amazingly skilled in this area of high availability, share some of my knowledge but maybe more importantly, expose my lack of knowledge in a way that didn't feel so threatening. It's like, I don't know how to do this and people would just respond. Have you tried this? Did you think of that? And ultimately I was able to both learn and then contribute to the project and the contributions that I submitted were eagerly welcomed and that whole process which in the beginning didn't take very long, that whole process was totally life changing in the sense that I realized I could just get involved. It was my own initiative that was all that was required to make an impact on the community and I could learn from really some of the brightest minds in this field in a way that gave me a huge opportunity to kind of grow and that was the beginning of open source development for me. Yeah, so when I first heard of open source or especially the community of open source, I heard not so nice things about it. People are, you know, it can be a little... Crass holes. Yeah, I was gonna be more diplomatic, but yeah. You know, they don't have a lot of time and I'm not necessarily a lot of patience, a lot of knowledge, but it can be a little mean sometimes. When you were starting out, were those issues that you had to deal with? In that very beginning, not necessarily, it may have been a unique community smaller, so it's almost like, well, there's another one. Whatever we do to keep that person engaged, let's do that. It wasn't long after that that I got involved in the Kernel community and the Kernel community was much more abrasive and you had, you just had a different way of engaging and I definitely had points in time where, you know, if you could reach through the keyboard and throttle somebody, you would. Or conversely, you just feel like that's been, you've experienced that and you feel kind of abused. And so that is the thing. I would definitely not want to disagree that there's not a cultural element that can be abrasive and part of it is time, part of it is, these are people and people have differing ways of working with each other. A big part of an open source community for me is the human relationships and the trust associated with those human relationships and what's interesting about that in your family, you're probably more rude to your parents or siblings or children than anybody else around on the planet and that same kind of safety of trust. I could be an asshole to you and it'll be fine and afterwards we'll go have beers or something. And so there's a little bit of that and then also just people have different skill levels in terms of how they communicate with others. And when you have extremely bright people really passionate about their ideas, you're also engaging just that passion. Like I'm right and you're wrong. And so there's a lot of different dynamics that are happening in one, in that community context. Yeah, and I imagine the community is kind of forced to grow up a bit too, right? The more mainstream it becomes, the more people it includes, the more ideas are in the room, you kind of have to be more accommodating. Have you seen any shifts in the culture? Absolutely, absolutely. In fact, in the Kernel community, we had some real issues. You could pinpoint it to a few key people. And so, who shall remain nameless? Some of those people behind the scenes were actually spoken to, like, hey, your behavior is damaging to the entire project. And I'm not talking about Lina's here, that was done in public, but there were some folks who didn't even understand the degree to which their behavior was off-putting and hurting other people. And so a little bit of just direct communication and saying, you really need to think about how your voice impacts other people. I suspect that made a small impact because a lot of these are ingrained behaviors. And then at the same time, more at a kind of project level of focus on how do we get more people involved? If you look at a finite pool of people over time, there's gonna be some attrition. And if you have a finite pool with attrition, that will approach a pool of zero over time. And how do you keep onboarding new people? And for two reasons. One, just to keep the critical mass. And two, you need to have fresh ideas. It's really easy to get into an echo chamber and start getting stale ideas. And we wanted the project to continue to grow and thrive. And one of the big values of Linux specifically is that it's quarter century plus. It's evolved with the technology landscape. It's adapted to all of the changes. It's on all of the, normally it would be in my pocket although right now it's over on that chair. It's on my phone and powering the world's largest supercomputers. And that whole entire spectrum of hardware that's enabled has changed over time. So continually evolving in a context where also the software that's running is continually evolving. So Hugh and I worked on Zen, later KVM. Today a lot of focus in the industry around containers and all of these contexts. Linux is at the core. And how do you keep evolving this project to stay relevant? It requires both code level changes but also keeping the community fresh within people and new ideas and new requirements and new use cases. And if you have a kind of a stiff arm policy to accepting newcomers then that's never gonna happen. Doesn't work, yeah, okay. So I wanna switch gears a bit and talk about the business model I guess of open source. I feel like recently or over time it's become more and more corporatized. I think this is a word we can use. Especially just recently with Microsoft buying GitHub the largest platform for open source projects period is I think one of the biggest symbols of things kind of moving in a more corporate direction. And I know you represent Red Hat which is also a big company. But how do you feel about that? As an open source contributor someone has been in the community for so long and now you work for a company company. How do you navigate that? How do you think about that? It's complicated. There's the first, like my first response is we won. Come on, I mean that's awesome. We have been, I've been at this for a long time and there's this sense of us against them and my t-shirt might even resemble that. And the us was the community and the them was proprietary software. And today so much of the economy is run through open source developed software which is a huge, huge, huge major step for open source communities. The flip side of that is the part of how we've grown is through becoming mainstream and becoming part of this economy. And that means there's a lot of money that's infused into projects and with that money comes this... Strings. Yeah, like there's definitely strings attached and it changes the incentives and so one of the things that I care about is how can we retain the health and vibrancy of a community and the kind of community concept while embracing a whole set of new developers who are corporate enterprise developers. I mean the growth of open source is into corporate culture and into products and running companies. Many of the new full-time developers are coming from corporations and making that accessible to those developers, making open source communities accessible to those developers is really important. It's how we're gonna continue to grow and get the diversity of use cases and people. But we can't do that at the cost of sort of selling out the community concept and there's definitely a faction within the community that's very much just a counterculture and so that faction I think would not feel like we've won, would feel like we've sold out. But retaining that kind of core community principle I think is the hard part and one of the things that I've seen in the industry and I know many here have probably participated in this process is we have all of these organizations that support open source projects, foundations and to me I sometimes refer to the foundation as corporatization of open source development and I mean that literally as well as tongue in cheek with the negative connotation that comes along with that and the literal piece is we really do have more corporate input into the process and the concern that comes along with that is where's the soul of the community and the governance process is put in place to make it comfortable for all these corporate entities to be involved because they don't know any other way and if we didn't allow for that we wouldn't be including those members into the community and if that's all that we have then we may lose the real core value of the community and so I think there's a balance and attention there and I see the value of a foundation and one of the things I worry most about is you pool a lot of resources behind a project and with those resources that's dollars, that's funding those resources one of the major things a foundation can do for a project is market it and marketers are really good at marketing things and when you market a project independent of its maturity level you can really create and set expectations for the industry and some of the things we've seen in the last five years are projects that have huge marketing budgets get a lot of focus in the industry don't quite meet the expectations and then there's a lot of dashed hopes and so I think responsible thinking about what is what's the value of supporting a project which is mostly about the developers and the users and getting the right message out at the right time is it's a tough balance I mean the Docker project didn't exist one day and sort of went viral the next day and really helped change the focus of the industry and there's something really cool about that and then there's all of the kind of marketing corporate interests that can I don't know confuse some of the messaging it kind of makes me want to ask the question what is open source at its absolute core I was in a room where this was being debated and a friend of mine sat next to me and she said all this debate about the open source community and the corporations and the people that's not what it is open source is purely about the license that's the whole thing the whole thing is just the license and it's not really much more than that I wasn't actually disagreeing so I was like she's a pretty big open source contributor and I thought really, really that's how you look at it but it does make me wonder now that there's all these players that didn't exist before there's corporate input, there's foundations there are people who get paid to do it there are people who are doing it you know, nights and weekends what does open source actually boil down to in your opinion? It might be a sort of a cliche word but it's collaboration and so the reason I don't think it's a license for one there's many open source licenses and they all have different subtle implications of how that license can be used so there's kind of the most restrictive open source license and the least restrictive open source license and the least restrictive open source license allows you to take open source code and embed it in proprietary software and the most restrictive doesn't allow for that so just with that spectrum alone I feel like that you can't define open source as the license to me it's much more about the collaboration and most importantly about the contribution and the reason I think about the contribution is that same license spectrum which allows you to take code and abscond with it may or may not be how a community treats the code that they're working on so the community culture and the expectation for collaboration and contribution is independent of the actual license and it's the community culture and the collaboration contribution I think is open source it's you know your output is code that you're developing your community is developers and users and you're facilitating that with a license to a degree that you can freely redistribute the code but it's not the license the license is more of a tool and it's really important that GPL versus BSD and can I embed this in my proprietary code or not doesn't seem to be the driving force for how much people contribute back to a project it's more the community the culture the expectation that creates that and I think that's a really important distinction so to me it's that it's collaboration it's the contribution both code contributions as well as bug reports and documentation and you know users participating that's that collaboration and contribution are the key of an open source community. So one thing that I was personally excited about with the corporatization of open source is the money that goes with that right because I think we like to think that open source is accessible to everyone but the reality is for a long time is it's accessible to people who already had good day jobs and could afford to do a lot of really great work but to do it for free and now with foundations and funding and I'm outreach is a great program but allows for people to actually get paid to do this work have you seen the benefits in diversifying the community and bringing in different people who may not be at that point of privilege where they could just kind of do it for free. Yes absolutely I hope the numbers are still small I'd love it to be bigger but I was reading an article recently and it was the premise of the article was just go learn that language and then you can get involved in a project that is written in that language. Implicit in that is an assumption of that you have the free time to go learn the language and that there is some kind of privilege that comes along with that and the focus that I see in the industry right now is not just only on the code and the foundations but also on trying to be more broadly inclusive and knowing that our communities won't thrive survive and thrive without more diverse inputs is probably the first knowing is half the battle and some of the work that we've done to help improve the diversity and inclusion within communities is all over the map from here we've been able to bring some new members to the community through funding and scholarships here at DevConf which is awesome so I know there's some folks here that are been able to take advantage of that and we're really excited about bringing in new contributors many of the foundations actually have scholarship programs that try to incorporate people into the community through largely conferences and getting people to travel because that's where you meet and have the high bandwidth face to face communication which is unique compared with digital communication and if you look at some of the statistics they're not that awesome, frankly I saw Marina put together some numbers for me and one of the things that stood out was a survey of the GitHub community the diversity levels are really, really, really low and then if you look at some other communities they're a little higher so it was like 3% in GitHub and roughly 10% in communities like the kernel and in any case that's low but that 3% number really struck me and even internally at Red Hat our internal numbers aren't that high and so what we need to do as an industry and with what we're doing within Red Hat is look at that and where are your biases? What can we do to not create barriers some of which are, you don't even understand it's language choice, how you communicate simple things like the wording in a web page or the wording in a job description so we had an internal panel which I thought was really interesting internal to Red Hat panel which I thought was really interesting talking about how we can broaden the contributions from a more diverse set of developers or really applicants to jobs and one of the women on the panel said, all of this DNI, mumbo jumbo, whatever just show up with good skills and do the right job and another woman on the panel had kind of in her back pocket a set of wording for a set of job descriptions and she just read them out and said does that sound like a job for you? And her answer was no and I had never even considered that the wording in a job description itself would be off-putting and so we try to pay attention to that internally and I think communities need to also look at themselves and how they're portraying themselves and some of the positive work of the foundation is helping create DNI programs and funding and really look at this as a, it's an industry level issue and what's interesting about it is open source in a negative way is off the charts. So open source communities are less diverse and less inclusive and as much as it's about community and collaboration the dichotomy there is the community and collaboration doesn't seem to be accessible at all and some of that is the socioeconomic reality of do you have the spare time to go learn a new language or you're working three jobs and you don't have the spare time and some of it is just the language and the way that we communicate with each other that maybe even the style the kind of I come from an era where meritocracy was still a good word. Today it has developed a negative connotation and we're using inclusive meritocracy at Red Hat and other communities have just abandoned the word altogether. But the notion that the best ideas are the ones that win rather than the person with the most senior title is really important. It's fundamental to a community and whatever the right word is I'm happy to go with conventional wisdom of what's the best word for that today. That's the core value that matters and it's in getting people's access to skills and inviting people into communities like this. I think are really important ways to improve the diversity and inclusion of open source in general. So why is improving it important because open source has been around for many years has done very good work as you said, we won. So if we've been winning then why do we need to talk about this now? My sense is the best ideas come from the most diverse. I wanna use the word community but the most diverse group and if you look at the success again of Linux as a kernel and an operating system I believe the success is through the broad diversity of requirements placed on the platform and that diversity of thinking and the set of different requirements in one part is just representative of different portions of the industry. But I also believe that the people that make up the community have that same impact on the code base and on the community so the more diverse we have a community the stronger the fabric is that we're creating of the community itself, the connectivity in the community. And if you think in terms of biology or something where you do highly efficient, hyper efficient monocrop farming it produces a tremendous amount for a fixed period of time and eventually you tap out the resources and a more sustainable long-term high productive environment might be some integrated crop management and looking at how you can balance different inputs to create to still maximize your output but maybe it's not 110% for a brief period but it's a big number for a longer period and that to me that's the thinking that I think is why a diverse community is so important and why now what I think part of it is just broadly culturally we're more aware today than we were in the past. It's just sort of a steady state of awareness growth and starting to see some of the limitations and some vocal people who have helped us see that vocal people who stood up and said this community isn't working well for me. I feel actually uncomfortable and threatened and attacked and if our goal is to make people feel uncomfortable, threatened and attacked then okay great but that's not our goal and I think we don't always understand the community can be blind and so we don't always understand where that's the behavior that we're exhibiting and that's the interactions that we're fostering and that's not the world that we're trying to create. I don't know. That's a good answer. A lot of my own opinion in there. Wonderful. I think we're at time. Do you have time for questions? We do? Okay. Awesome. Questions, got a couple of questions. Raise your hand, raise them high. Got one up front right there. Got another one right there. Yes, thanks a lot for the answers. You said we won and I think you're right but I'd like you to comment also on another aspect where I think open source one which is development models. Everybody in the corporate world today uses Git. Some will use private instances of Git lab or whatever so if you could comment on this and how we want that. So one way that we look at it is the barrier to entry for creating software has really become very low and so it's actually platforms Git itself as a tool for distributed development but platforms like GitHub or Git lab that make it easier for developers to share ideas and contribute code I think are a key part of that and more broadly speaking just the kind of digital communications and the way that we submit code, communicate, talk about the code changes and then commit the code changes in the way that are easily accessible to the entire community, both developers and users. That barrier has gotten so low that it's trivial. It's like electricity, we just expect it and it's that plus we have a ever growing source code base that you can either literally fork and modify or use as a foundation to build on top of and those two things it's trivial to create a project and the environment in which you're creating a project is rich with resources means it's like critical mass it's gonna be it gets increasingly difficult to stop that momentum because that's where all the activity is and it's kind of a self fulfilling prophecy of a sort and so I think it's that I think it's trivial to create a project in a really rich environment of. I think you started with the big 20s or you remember? You started with the big 20s so you remember when software components were a pipe dream to find the future and now we have them and I think we could not have them without open source. Yeah, I'd agree and so at that point in time a distribution medium was paper and I would type code snippets into a computer so it's not super efficient. We've been trying to create reusable components for the entirety of the industry and we still are so object oriented programming was a first major industry level attempt at creating reusable components. Today we call them microservices and containers and they're still not perfect but we keep refining the idea and getting better and better at creating these reusable components is whether it's libraries that you could pull from GitHub or whether it's code running as a service or containerized and ready to launch into your platform. That notion of reusable is pretty critical and the distribution capabilities of an open source license enable that widespread adoption. So they're all intertwined. I think the barrier to entry is so low today that it's why you have 80 million plus projects on GitHub. My question is we talked a lot about diversity of human diversity and maybe this isn't the right term to use but I'm wondering about the diversity of disciplines in open source and what kind of thoughts you might have around that. How can we improve that? How can we get more and different kinds of skills involved in projects? Because it struck me when you were describing implementing code to sort of like a piece of paper handed down from on high. I don't think we're that much different. Like it's either that or sort of maybe a bit more chaotic from the community and there's no sort of middle ground and I was just thinking more disciplines beyond just like coding would help there. So that's an interesting question because the market requirements, product requirements, sort of like the true waterfall development process. I think broadly we understand doesn't work as well just if nothing else it takes too long and there's the loss of information from the beginning to the end. The flip side which is closer to more open source projects is just surely evolve in place and almost respond, react to every individual input uniquely and then like right then and there, which is a little chaotic. And so you go to open source communities and they reach a certain size and they often struggle with who's the architect? How do we evolve the architecture which isn't necessarily at a line of code level? And so that's a great observation. I don't have a awesome insight on how to improve that other than I know that different communities are struggling with that and they've each created whether it's a steering committee or an advisory, you know, technical advisory committee or in the case of certain projects there are a small number of people or a single person who really does have an architectural sense of the project and a level of authority to keep it going in that direction. And so I guess I believe that kind of naturally there's communities are searching for something to improve the overall process or procedure or way of doing development. And one of the things that's creating more challenges is that the corporatization side brings in more requirements and the requirements have these things like it has to be done by Tuesday because my product's gonna ship on Tuesday. So the, which from an open source community point of view is a completely artificial requirement. And so there's tension there as well. It's not just how do we evolve the architecture and off the code, but how do we do that to take on requirements without being so unpredictable that the corporate side can't figure out how to work with us. So that it's, I don't know. We'll work on that one together. Before I get to my question, I just wanted to mention about software components is we sort of forget that those Unix utilities we strung together with pipes were the primary software components for most of us for many years. But I had a higher level question about diversity. So it's been 15 years since I left industry and went into academia. But one trend I saw, and maybe it's partly because Boston's a small area, is that there's a strong old boy network in hiring in the sense that I think is based on rational decisions that if you've worked with someone before, you've got, there's a lot less variance in your estimate of how good they are. You may have a resume with a higher expected value, but the chance that the person you worked with is going to crap out on you is lower. And that leads to everybody knowing everybody else. And to what extent do you think open source, do you think it has changed that at all? Or do you think that it has the opportunity to change it? Well, I guess it's interesting in the sense it's changed and doesn't change all at the same time. So it's changed in the sense that you could be, you may not have worked with a person, but their work is so publicly visible that you get a sense of who that person is and what their skills are and capabilities. And as a result, maybe more interested in bringing them into your organization or hiring them and to be more concrete, you could take a project that has a maintainer and that project maintainer is likely to get a job maintaining that project multiple times. So is that an old boys network, maybe of a sort? On the flip side, your ability to showcase your skill set is in code, it's not just in a resume. And I think that that makes it easier to show your capabilities. So I think it's a little bit of status quo in the sense that you get a key maintainer, a person who's achieved a certain status in a community is more likely to take that status and bring it into from company to company. But at the same time, you have a really easy way to showcase your talent. And one of the things that we've been looking at is internally at Red Hat in terms of the hiring process. There's a term that people often use called cultural fit. And if cultural fit is you're just like me, then you're not creating diversity within your organization. And so we try to look for skills that are complimentary. Cultural fit, if you could use a different term instead of cultural, but a team fit or something that's trying to build a balanced team is a really important way to look at how you bring people into an organization. And again, I think that that's just, there's a benefit of being able to see the contributions that people are making within communities. As a son, yeah, okay. So in terms of dealing with that 3% number of contributors and open source, it seems that universities might be a really great place to start because they are, in my personal experience, much more inclusive. They work more at this and they have some experience about how not to use those words that make people not feel welcome. It's once you step out of the university that everything changes. That was my personal experience. And when you're in a university, you can show your skills, every day you're showing your skills, you're being tested, you're demonstrating it. It seems like a much more equal opportunity that you have in that setting. So if you could somehow extend that out of the university, maybe get more open source. In fact, I've known people here who got involved in open source while they were in university when doors felt more open. So maybe that's a good place to start, but that's not really a question. I would agree. I would agree. There's some attrition. So you see the numbers actually fall off from the university side into professional employment. And so there's clearly something different happening. Projects that we're involved in like CoLab and Outreachie that try to blend, have some student connection with a professional, in a professional environment, I think are steps towards bridging that. And it also starts before the university. The STEM programs for children are already kind of creating, they're fostering environments that aren't as diverse as they could be from the very beginning. And so you get to a university setting and you would never even consider the computer science might be of interest because it's just, you've been taught in the third grade that you're not gonna be interested in that or it's not gonna be available to you. So it's a whole spectrum. And we've done some work. Red Hat has done some work in our relationship with the universities in the Czech Republic where we have a large office in Bernal and we've seen as we get further into younger students we create just a better pipeline. And it takes a long time. It's a concerted effort and we're just a small company and there's an industry level thing that we need to tackle. My kids are involved in First Robotics and they're very good at being inclusive. First Robotics, good at inclusivity. All right, good, thank you. Cool? One more question. We're gonna be late, it's okay. It's Sunday. Yeah. So changing it a little bit around. One of the problems I've seen over the last year, open source has taken off and all of a sudden we see these colossally sized internet companies. And a lot of them are taking huge advantage of open source software. The question is, do they give back? Do they, I'm still waiting for the first commit from someone with an Amazon.com address associated with them. So, in a good way, Amazon.com's forced Google and Microsoft and everybody else to start contributing open source. But how do we get these colossal companies to not just take but also give? So I was an audience member at a conference where the panel was Google, Microsoft, Amazon and Oracle and they were representing in their cloud. And my question was, you haven't given anything back to these communities that you're taking from. You are what I would call a leech on the community. And I believe that starts internally as a cultural mindset shift within your companies. Do you see the value of contributing and do you care, essentially? Do you see, from a business point of view, is there an economic incentive to make sure you're contributing to these communities which as you are pulling from them today, if you're not contributing back, they could decline and your whole business could be basically at risk. And the responses were really interesting across that panel. The Oracle person said, you're right. And the Google person said, we gave Kubernetes. And the Microsoft person said, we have fundamentally shifted our mindset from open source is evil to open source is a really important part of the industry and you'll see more and more contributions from Microsoft into open source. And the Amazon person said something similar to we made Kubernetes and they cited a short list of open source projects they had created which if you go to those projects, you'd see it's all Amazon people contributing to those projects. And specifically, one, they said, it's really awesome. You can watch the developers work on the project and if you're really interested, you can get involved and make a request and if you're lucky, they'll code it for you. Like, that's not really open source development. So it is a big concern and I think it is a cultural, it's an internal to those companies cultural shift that is hard to influence. And I think the influence is economics. I think the influence is when they see that it's critical for their business to contribute, then they will. And certainly the fact that open source is mainstream and you see that as a way to try to attract talent into the company helps. And most of those companies have big Kubernetes distributions and they're trying to make contributions there into the Kubernetes community, but that's just one community. A different concern is many of these projects then are run as commercial services in the public clouds. And the community side doesn't really have an analogous way to run community level. We do community level development, we don't run community level services. And that's something that we're looking at and we're trying to figure out how we can do that with some universities and other communities and maybe other industry participants. And maybe that helps shift the balance a little bit of there's different ways to consider software. Part of it is the code, part of it is the service. Some of those services are commercial, some of those services are non-commercial and maybe in a non-commercial way that we get some of the operational skills and operational understandings and maybe that shifts that balance of how we can get those large hyperscalers to be more contributors than just users, I don't know. It's a shot in the dark, but I do think it's a real issue. Cool, that's all we got? Yeah, we are wildly over time, but that's fine. We're gonna push the next session back to 1040 everyone. So you got 10 minutes to grab coffee and get to the session you wanted to see. And thank you, both of you very much for coming all of this way, all the way from the West Coast in a moving van. Chris. Thank you. So I'm gonna, I'm not sure if you're sticking around but I'll be sticking around by registration. I'm also host of the Command Line Heroes, the new podcast from Red Hat. So yeah, we got some fans, our banner if you want to see.