 Awesome. So, I love going late in the day because I generally don't give very technical talks. There are, I think, almost no bullet points in this talk. I'm not going to show any diagrams. Actually, I have one technical diagram. And so, usually, people are burned out by this time of day anyway and they're starting to think about cocktails, which is perfect. So, this is going to be a talk mostly about mistakes. I was involved in launching a thing called OpenStack and we've had some measure of success. But OpenStack has a lot of history in Texas along with tequila and handguns. So, we just wanted to set the stages that this is really about mistakes made with whiskey and guns. And actually, I think all progress is made through these mistakes. But there's this this belief that I'd like to call out right away that computers help us make fewer mistakes, which they don't. They actually, we make exactly the same number of mistakes. We just make them at a higher rate. And so, hopefully, we improve things in technology faster than perhaps in other fields because we can iterate through all of those mistakes towards something that sucks less much, much quicker. And so, I think OpenStack is kind of an interesting environment because it's really a community built around alcohol. So, we're going to come back to the steam of drinking in a moment. To start with, though, everybody is a liar and this is kind of the root of looking at any community or cultural challenge or sociology is that you're trying to get true data out of talking to people and interviewing people but people lie about everything. So, the nice thing about OpenSource is that geeks are really bad liars, which makes it easier to understand what's going on because you can catch them out. And the classic lie is in OpenSource, the idea of OpenSource itself. How many of you have a job? How many of you work on OpenSource? So, you are the proof that the lie that OpenSource is about volunteers doesn't exist. I have yet to meet anybody. I've been working in OpenSource for 10 years. I've never met anybody who does it for free or for very long. They either aspire to get paid to do it at some point or they're paid to do it today or it's an adjunct to keeping their razor sharp or their skills honed for things that they get paid to do. It's funny how many people believe that lie. It's not something we go on deliberately say, oh, yeah, we're volunteers and we like to hang around and wear bathrobes and right software. But that is the perception of the community. So, there's a lot of these lessons from OpenStack that are about the perception of the community as opposed to the reality of the community. And this theme of bathrobes I think is one of them. I wanted to talk about OpenStack because I have reached this weird point in my own, how many of you have ever met me before? Do you have any idea who I am? No. Okay. My name is Joshua McKenzie. The first release of OpenStack was on my blog in 2010, a long time before it was called OpenStack. So, I've been doing this open source stuff for a long time and I've done it wrong a number of times. Remember that thing about mistakes? And last year, I think it was last year, I was made a member of the Python Software Foundation. So, now I've had a chance to watch other open source communities trying to copy things we did at OpenStack that we didn't really realize we did. And they're like, oh, we should do this thing the way the OpenStack people did. Was that actually a thing that was more of an accident? And yet OpenStack, in one sense, has been enormously successful. It's gotten bigger faster than any other open community ever. It's 12,000 members, I think, as of today, in a little less than three years. So, the one thing we did do right, mostly by accident, is we built a community that scales. It doesn't mean it does anything else right, but it did have that property and it's worth looking at why. How many of you are familiar with Melville Conway? A couple of people nodding? Okay. Ish. He came up with this great observation, which is that if you have a software development organization that has four teams, they will write you a four-pass compiler, guaranteed. And often when people talk about cloud and they talk about Amazon and they're like, why is, why are the storage APIs so much different from the compute APIs? Oh, it's Conway's law. So any time you look at some system, you're like, why is it broken up in these pieces? That wasn't a logical decision. That was an organizational decision. And so a lot of what worked for OpenStack by accident was hacking Conway's law. We just chopped things up into, we made an organization that had an infinite number of smaller pieces and all of those pieces can write code in parallel. Cleaning the API up on top of that is sort of an interesting challenge. But I worked at NASA and that was where I was working when we launched OpenStack and Conway's law can go very, very bad. So there are some sort of positive connotations in OpenStack. It's one of them, but this is a photo of Mars from the Mars Reconnaissance Orbiter. And it is the only photo we got right before the Mars Reconnaissance Orbiter smashed into Mars at about 400 miles an hour. It's because we had two different groups working on that particular spacecraft and one of them was working in metric and the other one was working in imperial. So when Conway's law goes wrong, it goes wrong at very high speed with disastrous consequences. The nice side effect of working in NASA is I get to use photos of planets in my presentations and it's kind of legit. So the insight that I had or I think I had, I'm probably delusional about scaling community is that we know that because of Conway's law, the code is a reflection of the community. If you have a community, it's going to produce code that looks and is organized like that community. The larger the community, the more obvious this is. We had this insight that actually the community is a reflection of the culture that the community started with. We have never been able to change the culture of OpenStack. I want to talk more about what our culture is. But it's what it is at this point, as far as we can tell permanently. And we were lucky that there were some characteristics of that culture that turned to scale. Well, they have other problems. We're all alcoholics, but it does scale. All right. So how many of you know what OpenStack is? Okay. This is so much easier. When I started talking about OpenStack, it was still called something else. I wrote these earlier in the year. So these numbers are wrong. It's now 12,000 people and it's I think coming up on 1.6 million lines of code or something. It's really, really fast growing. By any interesting definition of scale, we have scale. We've got deployments, number of servers, number of people working on it, number of commits per day. Monty Taylor, who gave a speech an hour ago, saying we measured recently our continuous integration environment, spins up like 6,500 VMs a day, running the test gate. That's it, just for the review queue. So our actually, the cloud infrastructure to run the cloud community is a pretty decent sized cloud in and of itself. There's this public history about OpenStack that in beginning there was this NASA team and this Rackspace team and we joined forces and everything has been happy since. Just before the NASA team, there were six of us in a bar and this project originally called Pene. We scrapped that name when we found out that in French it means small penis. So we renamed it to Nova, which in Spanish means doesn't go. So we've not had a lot of good luck. So one of the things that Rackspace brought along with money and a ton of people was expertise in naming things. OpenStack is clearly way better than Pene would have been. Nobody would be paying tens of thousands of dollars to be a member of the Pene Foundation. Yes, well, and or want to admit that. Yeah, actually, that's also not gender inclusive. That's one of the things. Okay, so we built OpenStack because NASA had this big data problem that we were trying to solve. But what was interesting about being at NASA and starting this computing project is that NASA has a culture that is very well-defined. They pick hard problems. They decide to solve them. They decide to solve them in the best way, the most elegant way or whatever they've decided means best. And they ignore everything else and they go solve that problem. The original problem was you get people to the moon without killing them there and back. It means as a bureaucracy, if you're not part of that solution, it's a horrible place to work. And actually, they have four or five major mandates that are supposed to be equal, but it's hard for anyone inside NASA to think about anything except for humans in space, the robotic program and everything else. And so that was the culture that we inherited when we started working on OpenStack. We're like, let's build open source infrastructure as a service and figure out how to make that work and ignore everything else, including that getting tens of thousands of people to cooperate on anything is probably going to be hard. So that attitude really permeates a lot of OpenStack. You'll see folks just like, well, yeah, it's hard, but that was never part of our decision of whether or not we're going to work on that or take that approach or why would we support both NN and KVM? It's kind of the same decision as the Libvert folks made because it's the right thing to do. They take these photos of the sun, they do insane things. And so the definition of big data for NASA, this was that big oil spill that we had that wasn't that far from here, actually. All of the reporting you ever heard about that came from NASA satellites. Some of it came from NASA satellites into cloud computing systems we were running. And the scale of that problem was insane. And so we talked to Amazon originally about just using Amazon. Like, hey, we want to do cloud computing. We have all these partners. And the largest data set Amazon could give us at the time was a one terabyte EBS volume. The smallest useful data set we had originally was 100 terabytes. We can't even do any science at all. We can't do a preliminary POC calculation without at least 100 terabytes. And we need 10 gig to every box. And it was just, there was nothing like what we were building. So we started this thing. And it really was so much different than what NASA had done before. We were one of the first agile projects. We did Scrum. We hired people from Silicon Valley. And it was like, it was this perfect storm of the stuff NASA was trying to do. And the president's open data initiative that said, hey, government agencies should publish their data and do open standards. We're like, hey, we're doing that. And the relationship with Rackspace and the fact that they were willing to bet the future of their company on doing something they'd never done at that scale before, which has become an open source business. And I mean, it's like, it's the classic cloud workload. We smashed things into the moon and we had on purpose at that time. Not the Mars one, which was by accident. We got all of this rich data in like 10 seconds. And that was the entire mission. It was like hundreds of million dollars to get 10 seconds worth of data. You really need to not lose it. Durability was important. So all of that is kind of preamble to say the culture of what we were trying to do, this hard problem and this fact that we were this agile Skunkworks team, we didn't want to be a committee. I'm now, it's ironic, I'm now run a bunch of committees for the OpenStack Foundation. Stefano is laughing at me because he's on a bunch of these committees. But I hate committees. I'm bad at committees. I don't like things that feel like groupthink. And so one of the original goals of OpenStack was to never be a standards effort. Standards efforts don't scale actually because what you end up with is compromise instead of rough consensus. And compromises don't make anybody happy. You don't hit that 80% use case where everyone can sort of get along and use it. We referenced ARPANET all the time. The cloud we ran at NASA was hosted in what was originally May West, same data center as early ARPANET. And so we had some of the same network engineers who'd worked on like Milnet and ARPANET and the first links between Sun and NASA. And we talked a lot about what the RFP process was, RFC process was originally, which was not about, hey, here's the standard I think would be cool. Let's argue about how the standards have fit together. It was, hey, I wrote some code that implements a thing that I think is a system that maybe you could connect to. What do you think of my code and my idea for how it should work? It was essentially the same thing the Apache Foundation does with the plus one, plus zero voting system. Rough consensus, good enough, let's get moving. So we really, really, really didn't want to do this. And it turns out that's good because communities don't scale. So instead it was like this just like, ship then test, fire then aim. This was literally the first release of source code, I think it was like 17 days after we started. I have a pet peeve, which is nobody should ever talk about open source before it's actually open. Anybody who says, I'm working on this thing that I'm gonna release source code for really soon? Shoot them. You've made my life worse by promising me something you probably won't deliver in the future. So we really, we wanted to like just ship, develop in the open, test in the open. And we really had some, a lot of us had worked on open source before in a bunch of different kinds of foundations and a bunch of different models. And we wanted to have zero committers, which we ended up doing, it's all by the merge bot. Nobody has ever had commit privileges on OpenStack. All code review and automatic merges, which is amazingly powerful. It sounds like I'm meandering, but I am actually driving towards the point I'm gonna come back and talk about some of these things. The magic thing about that initial launch of OpenStack was that our culture was fully baked. The first five of us in the bar and actually the team at Rackspace were doing exactly the same things. It was one of the reasons we got along so well. We drank the same stuff, bourbon mostly. And we had two things that we really believed in shipping code and code review. Bob Parsley worked at AOL slash Netscape when I worked on the Netscape browser. And he had the sign on his door. I thought it was genius. Just the prime, and this is a big commercial entity and it wasn't really open source and it was kind of freaky. We said the purpose was always to ship. If you don't ship it, it doesn't count. Just gonna keep emphasizing that. You have to ship or it doesn't matter. The other thing that's odd, and we'll come back to this, is the culture of open source, the culture of open source at OpenStack is very Gen Y. And I'm like relatively old for OpenStack. There are a ton of very young people. And so this is the idea of you just gonna do whatever you want. I don't think we actually could have had a benevolent dictator, no matter how good they were. I mean there were like five or six people at the launch of the project who were like we could have had this person be in charge and never would have worked because the culture was of a set of peers. Nobody would have done what anyone said. Like if I try to tell people what to do, they don't do it. Nobody at Rackspace ever did what anyone told them. So we had, it's not that we actually had this plan of like oh we should try something that's not a benevolent dictator, is that actually that was never an option. We were kind of anarchists to begin with. There was like even the original sort of two weeks of hacking, you can go back and read the commit logs. There was no like so and so said this and drew a design doc and then we built that. It was like whoever was working on that piece of the software built what they wanted. And then we argued about it. So the DNA of our community was this original culture and it was rough consensus, working code, drinking, tests and code review and this idea that we were all peers. And that was it. Those building blocks ended up being really, really effective for scaling because having leaders doesn't scale very well. It does eventually you end up with these hierarchies, right? And you end up looking like very large organizations and the reason we all laugh at big companies is because it's so expensive to have a hierarchy that almost no work gets done. The really important thing to emphasize about culture is you really can't change it. It's so hard. There was so much inertia around culture. These are some of the first commits in the OpenStack code base. We had this style guide called hacking.tst that eventually got turned into an automated test suite that checks every commit for style. How many lines of white space do you have between the import block and the first method definition? Length of line. Everything is consistent and we cared about it and we cared about it enough that it was in the first 48 hours this was in the code base. The docs were in the first two weeks. Sphinx generated, AutoDoc out of the code and we had people writing sort of user-friendly docs on top of that in the first release. We believed in automated testing and we had 85% test coverage. In that first, we had this, I think three weeks in, we were doing load testing of the entire API using Grinder and benchmarking. It turned out the LDAP server fell over so the API in the OpenStack part was fine but we were using LDAP for the test suite and it died because we were creating and destroying test users too fast. But we knew that, we didn't wait. If we had waited, we never would have done it. So those building blocks were turned out to be really helpful. We didn't do it because we were planning to have 10,000 people, to be honest. I never thought there would be more than 100 people working on OpenStack. I launched this other open source community almost exactly the same time in Europe called OpenQuake doing earthquake modeling for the World Bank. And it has like 40 members, 50 members or something across a few organizations. And I kind of felt these were like equivalently relevant things. They're both really nichey communities. How could anyone get that excited about earthquake modeling? How could anyone get that excited about cloud? But cloud apparently is way cooler. I don't know why. Okay. Nobody likes to feel like a loner. And it's actually really uncomfortable to hang out with people that you don't feel like they're like you, they're not your people. And so we tend to seek out folks that we have good cultural matches for. We hang out with people who like the same stuff we like, who think about things the same way. What happens is that's so intrinsically true that your community always ends up being a reflection of your culture. If you really care about test driven development, the only people who are gonna come and join your project are the ones who also care about it, at least enough to get along. You know, if you keep submitting patches and they keep getting minus two, you're gonna leave eventually. So your community sticks with exactly the culture that you start with. And that's why it's so important. Like when you launch, the first couple of interactions on the mailing list, the first time some newbie shows up in IRC and is like, hey, help me with this. I don't know how to read your text file. You have to be nice to them because that's the tone you have set for your community forever, whether you logged that event or not. It always ends up being an exact clone of the community you started out with. So we started out with rough consensus and drinking and that's what we still have. We have rough consensus. We had lunch with a bunch of OpenStack board members today and it's like, we're still arguing about the same stuff. It's still drinking the same stuff. OpenStack's community being that it's young and it's kind of weird in Gen Y and we do all of drinking at the infinite level of scale, we end up with our own music videos and rock bands that make up parodies of OpenStack for the community and it all feels like it fits together and it's not like the OpenStack Foundation organized some music video. These are just some people. That's the project technical lead for the dashboard and that's one of my marketing staff and somebody made up a dance that's got OpenStack letters in it and stuff and then they started doing it in Korea at one of the OpenStack summits. The gems of your open source community are these freakish things that emerge from your culture like the red hats. So the last thing is it's really interesting to look at the code itself. Test coverage never gets better over time. Like everybody wishes it would and you can invest infinite amounts of money on writing more tests and then at the same time you're also, people are writing more code and they're forgetting to. So we've been basically 85% test coverage since the day we launched and we fought really hard to make sure it doesn't get any worse but it seems to be impossible to get it to go any better. So it kinda, you need it if it matters, you should keep it as high as possible when you launch. And this idea of never having committers, this is probably the most radical thing OpenStack did compared to any other open source project I know of and it scales really, really well because this idea that it is a meritocracy and everybody can submit patches and there's a big community of reviewers around each project so you can probably get a code review even if the technical leader of that project doesn't like you or your competitors or you dated his sister one time, something. You can work around it and it means the community can scale. The personal, you're never gonna have a community without some personal relationships, a little backstory or some, you worked for him and then you worked for her and then whatever. You need a community that can work through those things. I don't know why I have a diagram of OpenStack in here. I think it's just worth mentioning how many different boxes there are and the message-based architecture inside OpenStack, actually, let's look at something for a second. If I started out by saying everybody lies and there's these ideas that Open Source is about volunteerism and that Open Source automatically leads to better code and that eventually anyone who works in Open Source burns out and goes insane. That last one's probably just true about NASA people. There's this term called chaotic governance. I was trying to come up originally with a cooler title for this talk rather than just saying it's about scaling community and say what is this model that we actually ended up with? I hate this word. It sounds like a hippie word. I used to be a hippie and now I don't like them but it's supposed to be this perfect mix of chaos and order and you get all of these nice emergent behaviors and emergent principles like you do with systems of chaos but it's a little bit more structured and so you can actually tell what's going on. And so there's some things that work really well. The governance that we have for OpenStack is an exact mirror of the software, roughly speaking. We have this three tiered governance structure where we have everybody builds NVC systems, model view controller. OpenStack is roughly speaking a model view controller system. We have a database which has all this sort of persistent state and then we have a whole bunch of controllers and conductors and schedulers and then we have various client side tools including the dashboard. We have a user committee in OpenStack that is in charge of talking to users and finding out what they want OpenStack to do and we have the technical committee that actually manages the day-to-day development of all of these different projects and then we have the board of governors that really deal with the money and the company involvement and legal, like talking to lawyers, which is now apparently the purpose of my life. And it's really bizarre that they exactly mirror each other. Our whole IRC-based teams, everything happens in IRC and it's all team-based meetings. We have this Q-based RPC mechanism inside the software itself and it feels when you're looking at the code like you're talking about the community as well. We have these open meetings, we've got open source, it's very plugin-based and we had this strong goal of saying we should have an ecosystem of vendors who can monetize by using plugins. And not only is it weird, we didn't set out to do this, we didn't like, well, let's have our governance look exactly like our software, but also it scales really, really well and it keeps it very authentic when people start interacting with the project and they look at the mailing list and IRC and then they look at the software, it all kind of makes sense. Our weird commitment to code review and our fixation on style guide goes along with the fact that we write 100% Python. Well, now it's Python and bash. And it feels very authentic and this idea of authenticity I'm gonna come back to in a minute. So there are advantages, there are also some huge drawbacks, right? Things that have a lot of separate components that have sort of emergent behaviors tend to be really resilient. You can shoot an entire OpenStack project. We have done, we threw the entire Keystone project out because nobody really liked the code and it seemed like it had been overly specced before it was built. We threw it out, we wrote it over again. We preserved some of the interop layers. Community was fine, right? New people joined the project, a couple of people left, the whole thing kept moving. We've added all of these new components all the time and things go away and they come back and it generally works. And it means we have a framework that folks are using to build all kinds of clouds. Public service providers are using it for the HP cloud and the Rackspace cloud. CERN and NASA use it, banks use it, governments use it. It's super general purpose, which I guess for a framework is what you want. It does have some giant drawbacks. This is kind of like a biological system and biological systems when you have dead stuff lying around bacteria and worms and things come along and eat it and clean it up. If any of you have been on SourceForge recently, this does not happen in open source. Dead code just sort of lingers. So there is always the risk in a large system where there's no central control of having sort of bit rotted stuff. We had the Hyper-V driver originally bit rotted and we had to yank it out and then later on Microsoft came back and supported it. We put it back in, but it's always have to be vigilant about, oh, okay, well what about this thing? And in a general purpose framework, so many things can be combined in so many different ways that the number of ways they might not work can be pretty high. The worst one is nobody has any idea what's actually going on inside OpenStack. Any chaotic system you actually can't tell from the outside or the inside and it's people think what at OpenStack is about is about the thing that they're doing with it. If you're working on Neutron, OpenStack is 100% about SDN. The network is the most important thing. The storage guys are like, what are you talking about? Nobody even uses that, as far as we can tell because all we do is sell storage. And so the people who are supposed to be in charge of like rounding up and summarizing OpenStack, nobody knows who they are, first off we don't. Like it's not the board of directors, it's not the technical committee, it's not the foundation staff. So apparently it's the media. The media just picks random people and they'll just be like, Stefano, what's going on with OpenStack? Stefano is like, well, I've been working on this activity board thing. Awesome, the number one thing happening in OpenStack is the stats tracking board, according to the media. So you can't, like there is no way to summarize. That's one of the nice things about hierarchy is you can summarize. You can't summarize OpenStack, that's a drawback. We don't seem to care, but okay. I wanted to close with a note on authenticity. The nice thing about driving community and scaling community around culture is it's very authentic, right? If you're just like, look, we're just all alcoholics who like to write Python, that's our culture, that's what our community is about, that's kind of what our software is about. Then you never have to remember what lies you've told. Right? It's like, ah, it's kind of, and this doesn't just apply to open source, you can do this for building a company. This is my co-founders of Piston, right? This is our official team photo, it's like us. We like bow ties and hats and it's not that we like, this will be great branding for our business. We should be all about fancy dress. No, it's like, actually, I like bow ties. Let's make that a thing, now it's a thing. I don't have to remember to be like, oh yeah, I'm supposed to look like a GQ model or something. No, I'm the guy in bow ties, because that's what I like. So authenticity for any open source project or actually any project is so much easier than doing anything else. If you're a small company, don't pretend to be a big company. If you're a big company, you're probably not gonna get away with pretending not to be boring, but you can offer up other things like, hey, we have free coffee or something. Red hats, yes, exactly. Great hats. You know, I started out by talking about Conway's Law. I wanted to come back to closing with Conway's Law. Authenticity does scale. It's so much easier than anything else. And this idea of leveling the playing field, the idea that we started out with a community of peers and what works about OpenStack is that it's a community of peers. That's the one you have to stay on top of. That is, I think, the only cultural element that will drift away if you're not careful. People will be like, well, I've been here for longer so my voice should be more important. The reason we have flat voting systems is because that's important. People are gonna leave, people are gonna come. That's just part of that natural life cycle. Starting out with a hard problem, saying we're just gonna go hard, solve this hard problem and ignore everything that could be a distraction to that, that's really helpful, because it keeps you focused. It keeps you focused on this is what we're gonna do. We are not making decisions based on an arbitrary date or an arbitrary stakeholder. We're making decisions that we decided to solve this problem and that's the goal. Yeah, closing it with lying. Lying does not scale. It is way too hard when you're drunk to remember the last lie you told. So if you're lying to yourself or you're lying to your community or you're lying to the media, there is no way to scale that up. Nobody inside OpenStack has ever pretended that OpenStack was anything other than what it was. Which is awesome. It means the perception of it is very confused. But that's probably okay. I have time for questions. I've probably left all sorts of time for questions. Whee! I will take questions until people are bored and then we'll finish early because I bet we could get a drink. Oh, bourbon. You seconded me. I got a plus one for bourbon. Awesome. No questions. Oh yeah, Stefano's got a question. So when you were talking about the culture and the initial team sets the pace for what the future will be, you also added you need to be nice. Can you argue what have, I mean... Yeah. Not nice, what have? The hardest thing about scaling a community is that you're adding people to a team that already exists, right? We do this all the time at Piston. We're very deliberate about it. So one of the, I did a bunch of things at NASA. One of the things I did on the side while we were working on this cloud computing thing was I did systems architecture for the human research program in Texas. And their job is to figure out how to keep people alive in space long enough to go to Mars and back. It's like three years. So far, we can't keep a small group of people locked up inside a tin can for more than six months before they go crazy. Actually, the number one risk we have is psychological. Russians can do it for nine months. I think it's the vodka, but I'm not sure. But regardless, they actually, they are better at not going crazy than we are. I think they also start out a little more crazy. But yes, the number one thing about teams they put in space is team cohesion. And there's a difference between team cohesion and social cohesion. So social cohesion is I like you. We like the same things, maybe we play the same sports, we get along. It's actually not helpful in space. That doesn't make a good and productive high-functioning team. High-functioning team needs only two things. You have to believe in a shared goal. So I said, having a bold mission of like we're gonna go solve this hard problem is one of the easiest ways to build team cohesion. And the second is you have to believe that everybody else on the team is contributing towards that goal. Mutual respect. You don't have to like them. You don't have to have the same backgrounds or the same values or anything else. But you have to all believe in the same goal. You have to all believe that you're moving everyone towards the goal. So there are a lot of tricks when you're adding people to a team to foster team cohesion really quickly. And the easiest one is self-identification. You gotta feel like you're part of the group. So this is why people wear team jerseys. This is why you wear uniforms or you give out t-shirts. Is you're very rapidly creating a sense of self-identification as a member of a group. And then you start to mirror the values and the behaviors of the group. People love to feel part of the team. It's a natural part of our biology. We're wired that way. The most important thing you have to do if you're growing a community is let people feel like they're part of the team, right? And that means across the board. It's not just that I got a t-shirt but there's no inside jokes that I can't become part of. That it's cool to feel like there is a culture of this team but it's gotta be accessible. I have to be able to become a part of it. I have to be able to contribute. I've gotta be able to also crack jokes. I've gotta be able to become a peer because nobody wants to spend their life as a noob, right? Noob is a derogatory term. We never call people noobs. So that's, I mean, being nice does not mean we like each other. There's a lot of animosity inside OpenStack the same way. We're a lot like a family at Thanksgiving dinner, right? Like there's a drunk uncle, people are probably, I mean, there's literally, there are people that come to OpenStack parties and take their pants off. Huh? We are hiring, yes. We are always hiring. Everybody in OpenStack is always hiring. We do this, I mean, super, at Piston, literally we have a thing called the hatting, right? So we have this reputation, we like fancy dress, we all wear hats. The first week of somebody's employment there, we take them out, we help them pick out a hat. At Gorham Brothers, we buy them a hat and then they wear it. And everybody applauds when they come back first all hands meeting, they've got their hat, now they're a part of the team, right? It's a little tiny, it's totally contrived. And I tell people when I do this, I'm like I'm deliberately fostering team cohesion by giving you a sense of identity with a group. The best thing about hacking your psychology is I can tell you and it doesn't make any difference. It still works. So yeah, that aspect of being nice, and I think we've done a great job. And the nice thing about OpenStack is it is a lot of tiny other little smaller teams, right? Every project has a sub team and everybody feels like they're part of OpenStack and they're part of Neutron or they're part of Havana, you know, Savannah or whatever it is. It means they can have their subculture too. They can be like yeah, we're really proud of the stuff that we did with Storage this week. And we're really proud of the object store, whatever it is. But we watch really carefully to make sure those projects don't become competitive with each other. And that's really the goal of the TC and the board is to say let's never have our teams competing with each other inside OpenStack. It's not healthy, it just, you know, it's like what happens when two brothers fight, or you know, there's stories in the Bible about that, right? It goes bad, yeah. How the culture should be a committer or how to select to be a committer from a contributor? Sure, there's no such thing. OpenStack doesn't have committers. We have contributors and actually, Stefano and I have been working on a thing called counting.rst. So we have hacking, or it was originally hacking.txt and then it was hacking.rst, and it's the style guide, right? This is why we think code looks pretty if done this way and it's easy to read. We're gonna want now that it's like, this is how we think our community should be measured. If we're gonna have metrics and everybody wants metrics, don't count lines of code, please stop. It's a spurious number, it's annoying. And if you're gonna do it, you know, at least do it inside one language as opposed to measuring lines of Java committed versus lines of assembler committed, like that's totally confusing. So we're trying to set up these sense of community standards. As far as contributor goes, the term contributor inside OpenStack means a contribution is you're a user and you provided some feedback or you filed a bug or you contributed to documentation or you hosted a meetup or you wrote some code or you gave a speech about OpenStack and it inspired some other people or you designed a logo, anything is a translation. Thank you, I always forget translations. I knew there was another one I'm leaving off. Any one of those things is a contribution. So active contributors measures any kind of contribution. As far as actually having patches landed, every one of those sub-projects has a core team. And nominations to core are really simple. They happen on the mailing list. Somebody who's on the core team says, hey, I think we should nominate so-and-so. They've been doing a lot of reviews. They match the style guide. They've been an active member. Other people say, okay, yeah, plus one, plus zero. They need, I think, a couple of plus ones and no minus ones. Just nobody on the core team saying, for some reason I don't think this person should be part of core team. So each of these projects, I mean, I think Nova's got what? 40 or 50 members of core and that's probably big, most of them 20 or 30 people. So every patch goes in through Garrett and goes into code review and it needs, you can suggest anybody should review the code, but you need two positive reviews from core and no negative reviews. And it has to pass the automated test suite. So the test pass, the gate passes, you get some plus twos, and maybe you need one plus two. I think you need two, a plus one of these, huh? With Garrett. Yeah, oh no, I mean in open stack specifically. I think it's two positive reviews from core. And then it gets merged automatically. So that whole CI infrastructure is running the test gate, the unit test first and then testing full build constantly. Yeah. So you mentioned that it's really important to have good culture at the beginning. Unfortunately, some of us come into projects late or whatever and we have a culture already and sometimes it isn't quite as functional, shall we say. Do you have any kind of feedback or hints or tips or anything for making changes to an existing project to improve a project along the lines of these issues with culture and stuff? I'm really, really tempted to say fork, but I'm, no, start drinking. Yeah, I mean you gotta figure out what the problem is, right, so if you think about it in terms of team cohesion, like are we not all clear on where we're going? If we're not, let's figure that out and that drinking helps for that. Let's sit down and actually talk about it. If we're all clear on where we're drinking, where we're going, I am clear on where we're drinking. If we're all clear on where we're going but we don't feel like we have mutual respect, that you've gotta figure out and usually the guidelines aren't clear enough. That was a thing that helps a lot about hacking.txt is it just makes it super clear. The whole review process makes it very obvious what the expectations are, right? So the entire process from saying, I have an idea about a feature I think I'd like to add. Okay, well the right way to do that is to write a blueprint. Anybody can do that and there's a template for what a good blueprint looks like and you can get reviews and you can talk to people in IRC and say, here's a blueprint. So if you figure out what part of the process is broken in terms of is it that people don't feel respected? Is it that they don't respect each other? Is it that there's general animosity which is maybe historical? So I've been in some communities where there's a lot of historical animosity. It doesn't necessarily even have anything to do with the people that are there today. It has to do with the feeling that in the past there were people of some class, new people, people that wanted to take the project in some other direction, whatever it is. And we're angry about that because we wanted it to be this and the community wanted it to be that. Honestly, sometimes a fork is a good thing. Sometimes a fork is the best thing that happens to a project. It says, well, if half of your community wants to take it in a different direction and this core team wants it to stay being this thing, maybe it's two things. Maybe you don't have a single-shared goal that you're ever gonna get rallied around, right? This is, and that's okay. We had a, I mean, actually the CloudStack presentation was right before this. CloudStack offered to donate CloudStack to OpenStack early on and it didn't make any sense. We had different cultures. Certainly we had different cultures at the code level. There's was Java and ours was Python. That was like as a starting point because it doesn't make any sense. And I think it was better for them that they went their way into the Apache Foundation and we went our way with Python than for us to say, okay, well, we're gonna try and make this work but we're gonna end up with one community where we don't really see the world the same way. We don't have the same ideas about code and process. We don't think this project needs to solve the same problems. Like, sometimes two projects is much better. I, on the other hand, would really like KVM and Zen to merge. Sorry. Did I answer your question? Sort of? Problems aren't necessarily major. Oftentimes it's just like, there's dysfunctions here and there and I think that the part where you were talking about like identifying the problem and fixing it type of thing kind of makes sense. There's also, never underestimate the power of the introduction of the third element. So sometimes if you have, you've got polarized opinions like we had this early on and we're like, is it twisted or is it tornado? Is it this or is it that? Add something else. Find a compromise. And sometimes a new person, a new community member can be incredibly powerful because they can just be happy and naive. They're like, I don't know, I wasn't here for any of the baggage. I just think this would be a neat idea. We've had, occasionally we've had interns have great impact on the community because nobody can get angry with an intern. Right? How can you get pissed off of an intern? They're so adorable. And they're not getting paid. So, you know, it's not really fair. And so you can take the hot button topic and be like, we really have this contentious, deeply seated conflict around X. The change to POSIX semantics or something. Okay, well let's use an intern. Or a consultant. Consultants also, if they screw it up, you throw them out, right? So, and they're used to that. Any other questions? If you get five minutes, you can almost get a drink in five minutes. All right, well thank you very much for listening. I hope that was useful. Thank you very much. Thank you.