 The basic point of this talk, just so everybody understands, is I think we're doing some interesting experiments in OpenStack in terms of governance, and I feel like I'm learning a lot from that and in terms of how I think about how projects can be run effectively. So I'm just trying to share some of my, I guess, insights or thoughts of what we're doing with OpenStack. So it's not so much here's exactly how we're doing it and here's how we're amazing, but it's more here's some of the interesting things going on in OpenStack that I'm learning from and perhaps you all can learn from too. I'll apologize in advance a little bit. This talk, I only found out last week that I was giving this talk so it's not usually well prepared. I haven't done a run through. This could be two hours long or it could be 20 minutes long. I've no idea. But it's something I like talking about so hopefully you guys will find it interesting. So about me, my name is Mark. I've been involved with OpenSource now for 15 years or so. 11 years of that have been at Red Hat. So I guess I'm a Red Hat lifer at this point. I initially started out on OpenSource working on the GNOME project. But for the last, I'd say maybe eight years or so, I've been kind of working on virtualization stuff kind of all over the map on virtualization. For the past three years or so I've been working exclusively on OpenStack. Contributing to the project a lot. I was the PTL of a project called Oslo. I was on the NOVA project. I was on the OpenStack Technical Committee, the OpenStack Foundation Board. But just in the last few months I've kind of put a lot of that aside and I'm focusing more now kind of on an internal management role I guess at Red Hat as the technical director of OpenStack at Red Hat. So yeah, I mentioned GNOME. And that for me was my first kind of real exposure to OpenSource. And I really described that as a kind of formative experience for me. I guess GNOME has always been and is still hopefully a healthy, kind of diverse, large project. Lots of people involved, lots of sub-projects, lots of people with very different interests from everyone else. You know, a really positive community in terms of how people interact with each other. Some really difficult controversial issues over the years that had to be worked through. You know, a lot of times, a lot of external interest and speculation about the project. A lot of negative feedback towards the project if you think about how say GNOME 2 or GNOME 3 was received. And I guess, you know, I spent a good few years being part of all of that, seeing how we worked through all that. And you know, I didn't just, I guess I didn't just live it right. I actually thought about all of this and enjoyed thinking about how we were dealing with it and what it meant. So, you know, I described this talk is about governance and you know, I think most people when they hear the word governance, you know, think of bureaucracy and process and rules and elections. And you know, it's generally, all of that stuff is recent. So governance is so boring, even the technology is falling asleep. All right. So governance isn't boring, honestly. Where was I? Yeah. So you can picture it as all these processes and rules and bureaucracy and all that kind of stuff. For me, it's really not that at all. It's a very, you know, it's a very personal thing about just how we as humans work together in a project, how we collaborate, how we work through issues. You know, we can make, put a lot of rules in place to help us, you know, deal with work through stuff and, you know, define rules for how we work together or we can, you know, make it a lot more ad hoc and, you know, both models, I guess, have their merit. You know, when I say governance is personal, actually, I think back to, you know, one of the, one of the really, something that really stands out in my memory from my early days working on open source. It was an incident in the GNOME project where, you know, if you know any of the people involved with the GNOME project, you might know of Michael Meeks, who now works on, on Libre Office. Michael is a phenomenal person for dealing with new contributors and mentoring them and, you know, I sent him my first patch, my first contribution ever to an open source project and he said, your code is awful, your coding style is awful, but I think I can turn you into a good productive, healthy, or a good useful contributor and he did that in pretty short order and, you know, I always had a lot of respect for him for that. And we worked together on something called Binobo, which was kind of using CORBA within the GNOME project. And then we had the likes of, you know, Havett, Pennington, Owen Taylor, maintainers of the GTK project, who, you know, as far as I was concerned, immensely smart guys doing really, really amazing stuff for the project. You know, I really hugely value their leadership, but, you know, the Binobo camp, the GTK camp were in violent disagreement about the use of Binobo, the use of CORBA, how we should do these things. And, you know, I just remember an incident whereby Havoc got so annoyed, so frustrated with Michael at one point, that he just replied on a mailing list, you know, deleted the whole thread, deleted the subject, and I was like, fuck you! Like, just like shouting up Michael. And I knew these guys were like, they'd worked together for a long time, I respected both of them, and how did this happen? And how did things get to that stage where they were literally boiling over with rage with each other? To the extent that I think Michael had to go to Raleigh, they had to sit down, they spent, you know, a few days trying to work through the actual technical issues face to face. So for me, that's what governance is all about. It's how we can, you know, as individuals work together, you know, really care passionately about what we're working on, and, you know, really want the best for the project that we're working on together, and then, you know, drive that forward in a kind of a constructive way that doesn't rip our communities apart, doesn't result in forks, and, you know, positive outcomes come from it. So even yesterday, it was yesterday, yeah, even yesterday made lots of subtle, really interesting points, but two things struck out for me in terms of, you know, governance and open source and all that kind of stuff. He used the term non-hierarchical collaboration, which I've never heard of before. But, you know, I would talk about healthy communities and what does healthy collaboration look like? And maybe the best way of defining what healthy collaboration looks like is it's non-hierarchical collaboration. That's the kind of, that's the form of collaboration we're trying to bring to the world, I guess. We're trying to get away from places where we define strict hierarchies of, you know, and depending where you are in that hierarchy, you have different levels of influence and that's how decisions are made. Instead of that, we kind of value the kind of diversity of interests and the collaboration and the kind of rough consensus and running code type model. And so that's what non-hierarchical collaboration is about. And so how does your project's governance enable non-hierarchical collaboration? But then also he talked about how we in the open source world have been successfully building bridges to profit making organizations. And I guess it harks back to maybe earlier times with an open source where, you know, we would have feared the involvement of big companies in our projects. We might have felt that they would, you know, that their profit motive would disrupt what we're trying to do, it would, you know, bring the projects in directions we don't want and we would have tried to keep these companies separate from our projects as much as possible. But over the years, we've started kind of building bridges with these companies and bringing companies, I guess, closer to our projects. Without, like, bringing, we've managed to do that without undermining that goal of non-hierarchical collaboration. So if I'm going to talk about open stack governance, I think I should give a quick overview for those of you who don't know anything about open stack, you know, how we govern ourselves. So the project has a six month release cycle. I describe it as having multiple fiefdoms. When we do a release, it's, you know, each project is releasing its own code and that project is essentially self governing. You know, so you might be talking about it in an integrated release, something like 10 projects. And each of these projects have their own core teams. And these, you know, these are the group of people who are, you know, the main contributors to the project, the main code reviewers on the project, the ones who have control over what code can be accepted into the project. And the contributors to each project elect project leads. And these project leads essentially act as, you know, the dictators of the project for a six month cycle. But you know, there's an election every six months. And then the contributors to all of the projects overall elect a 13 member technical committee, which then have kind of overall kind of oversight, I guess, of the projects and how they interact with each other and the kind of standards that each project should follow. So I describe that as we have a self governing project, right? The contributors to the project, govern the project and have control over the project's direction and so forth. But yet we have something called the open stack foundation. And so if I'm describing the project as self governing, what role does the open stack foundation have? So foundation is a nonprofit foundation. And its mission is to protect, empower and promote the project. I think a lot of people make assumptions about what foundation's role is with an open source project. In our case, we have very explicit mission. And I love to remind everyone involved, don't make assumptions about what the foundation is doing. It's there to protect, empower and promote the project. So the foundation has over 200 member companies. And you know, everything from a platinum members who pay half a million dollars a year for their membership to, you know, lots of, you know, hundreds of smaller kind of sponsor companies. We also have a silly number of individual members. And I say silly number because I think it's up to something like 15,000 individual members. And, you know, if you compare that to the number of people who, you know, are actively involved in kind of any way to the project, whether it be, you know, even attending meetups or anything like that. I think we are talking about, you know, and, you know, far greater number of people who are members of the foundation than the number of people who you could say in any way are kind of actively involved in the foundation. So the foundation has a $10 million a yearly budget. And, you know, a good portion of that is spent on, you know, big, too big events that we have every year to bring all our contributors together, but also to bring the kind of broader ecosystem around the project together. So I said the mission of the foundation was to protect, empower and promote the project. And, you know, I, there was a whole bunch of stuff I could have talked about here today. I picked a random bunch of topics that I thought would fit into the lot of time. And somehow, quite a number of them fitted under this protect umbrella. So let me see. Different ways of interpreting the word protect, right? You could imagine the foundation is setting up like, you know, a defense around the project and keeping out the evil hordes of people who wanted to destroy the project. Or you could imagine the foundation kind of taking it almost a parental role with the project. It was like stopping the project from hurting itself almost. And I think, you know, both interpretations are somewhat true. And often, you know, often this protection role comes down to dealing with legal concerns. So I thought I'd pause with a lawyer's joke. And I can tell lawyer's joke because my wife is a lawyer, so I can't be accused of me in a complete anti-lawyer bigger. But anyway, so lawyers occasionally stumble over the truth. But most of them pick themselves up and hurry off as if nothing had happened. So that was Winston Churchill apparently. Okay, so we're going to start with contributor license agreements. So in the early days of the OpenStack project, the Apache license was chosen as our license. I guess it's hard to tell in retrospect why it was chosen, but I guess you could assume that it was chosen because a permissive license seen as being, you know, good for a project that wants to attract a lot of companies to build products on it, even companies that want their products to be proprietary. But I guess also it's a permissive license with some patent grants in it there and those patent grants are kind of seen as a positive thing for this kind of project. So often, but not always, alongside the Apache license, you'll also see Apache's contributor license agreements. And these are agreements that contributors sign to basically explicitly say I'm contributing code under the terms of the license agreement. The terms of the license agreement are very, very similar to the terms of the Apache license. But the foundation receives contributions under the contributor license agreement and then it publishes or releases that code under the terms of the Apache license. Yeah, I think that about summarizes contributor license agreements. But the problem was, you know, I guess a number of us within the project, it was never one of our greatest concerns within the project, but I guess a number of us who cared about these kind of things, you know, I think we gradually grew aware of each other being, really uncomfortable with the use of, with our use of contributor license agreements. One thing I forgot to mention and Richard Richard, but the Apache software foundation in their use of contributor license agreements actually enforce contributor license agreements very, very differently from how the OpenStack foundation does it. So the Apache software foundation tends to only require contributor license agreement for, you know, large contributions of code on the OpenStack side. And I think it's probably down to our emphasis on automation and are, you know, not liking when people have to make, I guess, subjective decisions about policy that we'd like to just enforce a, you know, a very well-defined policy. We require basically every contributor, every new contributor, when they join the project before they can submit any patch, no matter how trivial, must sign the contributor license agreement. And that really is in contrast to how the Apache software foundation views these agreements. And so a number of us within the project, I guess, were uncomfortable with what we were doing here. We're aware that there were other mechanisms. And I guess we're aware primarily of the mechanism of that the kernel uses where, you know, you've got a license in that case, the GPL. But also all contributors for every contribution sign something called the DCO, the developer certificate of origin, where you put signed off by, in each commit. And I guess a number of us within the project felt kind of intuitively that there was something wrong with us having contributor license agreements. It seemed like a necessary level of red tape for new contributors compared to, you know, the very simple process of the DCO, which appeared to achieve pretty much the same thing. But I think a more subtle element of our concern with contributor license agreements was that, you know, we felt, or some of us felt that these license agreements gave a perception of OpenStack being, you know, kind of a corporate controlled project or something like that, that there was this sense of the project. If you're not, you don't know much about the project and you look at it externally and you see that it's a project that uses CLAs, you know, it gives kind of a sense of the project that we didn't feel comfortable with. So in order to make, oh, the use of CLAs is in OpenStack, OpenStack foundations bylaws, right? So it's almost, you know, like a core part of the setup of the foundation that we use contributor license agreements. So it was never going to be an easy thing to change. So Richard Fontana, sitting there in the audience and I kind of spent a long time really working through the issue and really understanding and writing down, you know, what contributor license agreements are, what they're trying to achieve, how the Apache software foundation uses them, compared in that OpenStack, comparing alternative models, trying to look back in the history of OpenStack, why they were chosen in the first place. And then we spent some time, I guess, talking first to members of the technical community, right? So the developers on the project, the contributors to the project, how they felt about CLAs and whether there was any sort of consensus that there would be a preference to move from CLAs to an alternative model. I think, you know, you could describe the outcome of those discussions as, yes, there's consensus that it'd be better to move, but you know, there would have been also a large kind of majority of people who just didn't really have an opinion, didn't really care, but those who did have an opinion generally wanted to move. So anyway, Richard and I took all this stuff and brought it to the OpenStack Foundation Board, because in order to, I guess, adopt an alternative model from the DCO, we needed the board's support to put forward an amendment to the bylaws to the membership for voting. And I would say we were, when we brought this proposal forward to the board, we were greeted with, wouldn't be greeted positively, I'll put it that way. We either greeted with hostility from a small number of members, but generally just confusion about CLAs seemed really useful and this seems like a really obscure issue and why are you guys, you know, making a, sorry, it was an Apache style, yeah, no problem. So anyway, brought it to the board, a lot of discussion, a lot of debate, a lot of heated debate, interestingly enough, but I'd say at the end of it, there was general consensus, not everyone agreeing, but general consensus that for individual contributors, especially people wanting to contribute, you know, relatively small patches, that we should certainly be accepting contributions directly under the Apache license without a CLA being signed with the DCO instead. And I think that's where things have mostly ended up. I think those of us involved maybe have run out of some energy at this time in terms of actually taking it to the next step and actually get it further. But I think the lesson I wanted to, or the reason I brought it up here, was it was an interesting experiment in that, you know, I talk about the project being self-governing, I talk about the foundation being there to protect, empower and promote, and this was one case where, you know, it was, it was a really interesting case where you felt there was a desire on the part of the project to, you know, change its policy around copyright, essentially. It wasn't about change the license, but it was kind of changing our policy around copyright. And for me, you know, if you think about any project, one of the first things you think about is what a license choice is, right? Like it's a fundamental part of the project and its culture and what it's trying to achieve and what it values. This kind of area is so much part of that. And in this case, it was a question of, you know, whether us as a self-governing project really had control over that choice herself, or whether, in fact, we, you know, we had no ability to change that, because the foundation associated with the project was in complete control of it. So that's CLAs. I've talked about that for a long time, but another similarly, a similar issue going on around the same time is the Open Stack Foundation's trademark license agreements. So, you know, like any project, right, its brand, its trademark is one of its, you know, core assets, I guess. And in our case, it's the Open Stack Foundation who is responsible for that asset, for the integrity of that asset, and licensing the use of that asset for commercial products. So we had a number of, we have a number of trademark license agreements for commercial use of our trademark. You know, I'm talking about like Open Stack Powered or Open Stack Compatible or Open Stack Training, these kind of license agreements. The Open Stack Powered license agreement currently requires you to be compatible with the Open Stack API and ship two of the projects, the code or two of the projects Nova and Swift. But those requirements are quite vague and quite lax and quite, you know, don't necessarily make a lot of sense these days. And so there's this being an ongoing effort over the last two years, I'd say, even longer to improve those requirements for the specific trademark license program. And the idea was we would define a very concrete set of API tests that these commercial products must pass, and these products would self-certify as having, as being compliant with these API requirements, but also that these commercial products would be required to ship a very specific subset of the Open Stack code base. So that this wouldn't be just a compatibility test, but would also be kind of, you know, the products must actually be, you know, substantially based on Open Stack code. And so this is defining these new rules is kind of a process that was kicked off as kind of a working group of the Open Stack Foundation. It was called Deathcore, and it went on for a very long time, and I think it's quite close to resolution now. But one of the challenges we struggled with all the way through this was how much of the policy here, how much of the decision making here should be made by the Open Stack Foundation. And, you know, specifically think here about the Open Stack Foundation being a number of corporate member companies. It's a board of, I should have said this earlier, but it's a board with 24 people on it. 16 of those seats are seats you literally pay for, like companies pay large amounts of money to occupy these seats. Only eight of them are elected. So what you have to think about here is the Open Stack Foundation being, you know, I guess the representatives of some of the larger companies in terms of Open Stack. And what we were struggling with in terms of these trademark license agreements was should the body of kind of corporate representatives being the ones deciding the trademark policy or should it be more kind of on the technical side of the project, should the contributors be the ones deciding the trademark policy. And unlike the LA case, I think the interesting thing here is it's actually worked out very positively for the kind of the foundation and the corporate representatives there to be the ones making these decisions because if you think about the alternative, if it came down to decisions on trademark policy that meant that different companies could or could not use the trademark and if those decisions were being made by the technical community, you would now have members of the technical community now dragged into, you know, very explicitly representing their company fighting for their company's interests, as opposed to just kind of representing their own personal individual, you know, goals or feelings for the project. So in this case, I think we've come up with an interesting and useful separation here where the foundation board are the ones that are essentially responsible for the license, these trademark license agreements as they relate to the commercial ecosystem and making decisions that are kind of best for building the open-stack commercial ecosystem and kind of having lots of companies involved and lots of companies that are shipping products that, you know, are good, useful, compatible, open-stack products without that really, I guess, disrupting the technical community in terms of, you know, potentially creating divisions within members of the technical community. So that's trademark license agreements. I think the interesting point, the point I'm trying to make here, is that these two cases, I think, are cases where we've really gotten to see where the boundaries are in terms of our governance between the self-governing technical community, the technical meritocracy, we call it, and the foundation board, which is primarily about, are largely about the kind of representatives of the corporate players in the project. And so these two cases are almost like proxy wars between the technical community and the kind of corporate representatives within the project, and I think we've actually achieved quite a nice balance and, you know, quite a nice balance that actually allows us to make forward progress together, but you know, it definitely shows that it's a very tenuous balance, right, that you really need to be very careful about where the balance of power between these two groups lie. I'm going to, I'm running out of time, so I'm going to skip a couple of slides here, and I'm going to stop talking about legal issues. No, I wanted to make one point on legal issues. In the, in, as part of the OpenStack governance, there is a subgroup of the OpenStack Foundation Board called the Legal Affairs Committee, and the Legal Affairs Committee, I guess, are the ones who are, you know, it's a group of lawyers from different member companies, and they're the ones essentially with the responsibility for, you know, thinking about IP policy, thinking about legal issues, and formulating, you know, recommendations and, you know, policy proposals for the OpenStack Foundation Board, and one, one issue we've really hit there, I think, and it's really a lesson for anyone setting up something similarly is, in this case, and in this case alone within OpenStack, it's a really non-transparent body right now. The meetings are generally you know, it's a small number of people on this committee, they don't meet in public, and there's no agenda published in advance, there are no minutes published afterwards, and it's really, that makes it a completely, it's a group making very important, not decisions, but policy recommendations, and considering very significant issues for the project, but it's almost impossible for members of the project to actually track what's going on there, or contribute, or just be involved at all. And I think the point here is that even with something like the Legal Affairs Committee in OpenStack, it really is important to set everything up to enable this kind of non-hierarchy collaboration. We set up a hierarchy here, we've assumed that there's a very small number of people who are interested and have any right really to be a part of these kind of discussions, and I think that's not a healthy kind of, you know, it's not a healthy mode of collaboration, we're not enabling kind of healthy collaboration here. So to switch focus a little bit away from that to what's going on in terms of the governance of the project itself, and the kind of technical development side of the project, one of the really interesting things going on right now is we've had a concept called the integrated release, so every six months we do a release of all our projects together. It's a typical kind of release process that you can imagine from an open source project like, you know, we have a period of, you know, rapid development, we go into a feature freeze, we go into a bug fix freeze, and we all kind of release together. The interesting governance question has been around which projects are part of the integrated release. When we do a release at the end of the cycle, which projects do we include, and it's, you know, it's almost gained, it's almost come to a point that in terms of how you think about what defines OpenStack, or what's part of OpenStack, or what isn't part of OpenStack, the question comes down to what projects are part of the integrated release. So in the past we've had, or up till now we've had a process where new projects come along and they apply for what we call incubation, and after a number of release cycles if they met a certain amount of criteria they now become part of the integrated release. And as the OpenStack project has gained new projects, as it has grown in scope in the last six months or so I guess, we've noticed that there are a number of issues with this. Number one, that, you know, as the project grows in scope, there is kind of a lot of demand for kind of cross-project resources, there's a lot of, you know, these new projects tend to put a lot of pressure on people who are collaborating cross-project. One of the more significant issues we've seen is that, you know, as new projects are added to the integrated release, I think most of us within the project would see that as a signal for distributors of the project, of distributors of OpenStack to take this new project and start, you know, making it available to the users of that distribution and gathering feedback. But some operators of OpenStack had, I guess, interpreted the adding of new projects to the integrated release as the projects are, you know, mature, they're ready for production usage, they're ready for large-scale usage, and that turned out not to be the case predictably, so we've had somewhat of a backlash of feedback in terms of new projects being added that aren't quite really ready for production use yet. And thirdly, I think a more fundamental issue we've seen from a governance perspective is this, you know, this status of being part of the integrated release was seen as kind of like the be-all and end-all of any project. So we were starting to see behavior with projects that, as they were added, you know, they really had this relentless focus on being added to the integrated release to a level that was, you know, quite unhealthy for the projects. We felt it was kind of just a very unhealthy focus for new projects and kind of unnecessary to achieve what we wanted to achieve in terms of kind of consistency between projects in terms of, you know, projects kind of being released at the same time and that kind of stuff. So there's a bunch of work ongoing at the moment to really fundamentally change how we think about the OpenStack technical governance and a lot of the result revolves around changes to how we think about the integrated release. So we're basically going to stop thinking about the integrated release and instead adopt a number of tags that will attach tags to the projects. So the idea would be that we would say we might have a tag that kind of represents the projects that are kind of core, kind of compute projects. We might have a set of tags that represent projects that have been deployed at large scale. Just a whole different set of tags and metadata that actually gives useful information to distributors, to users, to operators and focus our decision-making around these very kind of explicit qualifiers associated with each project, rather than just a single, you know, almost quality judgment about a project, about whether to be included in the integrated release or not. So part of, I hear someone laughing at the quote, this quote comes back from again, my GNOME days. I must be very nostalgic about my GNOME days this week. Miguel de Casa on GNOME piracy often used to start shouting at people, focus you baboons! And it kind of became a thing within GNOME about, you know, a way to focus our attention, I guess. So within OpenStack we're seeing, you know, a lot of backlash against the fact that the project is growing quite large in scope before it's necessarily, you know, become very, very mature in terms of its core. So people kind of look at the project and say, why are you adding, you know, multiple new projects that do lots of new things when you can't even, you know, scale this service past 100 nodes or something like that. So there was this kind of fundamental question from outside the project about whether developers were on the project were appropriately focusing on things that matter. So in the context of one really interesting governance discussion we were having about one specific project and the proposal on the table for this project was that there would be a fixed number of new features that could be added in the next release cycle and each of these features would be given what was known as a runway and that each kind of feature would have a number of sponsors that would do the kind of code reviews and the design reviews to bring that project through to, you know, being merged in the end and the kind of assumption there was each feature takes a number of resources apart from the actual developer doing the work and there's a fixed set of these resources and so we need to kind of decide at the start of the release cycle which are the projects that are which are the features that really matter and which are the ones that will get that prioritization and be brought through. So I thought during the discussion one of the contributors made what I thought was a kind of self-evident point where he said we don't have direct control over the contributors' activities, right? So in an open source project, in a healthy open source project, you have lots of people contributing to the project, it's lots of diverse interest, lots of people just scratching an itch and so you would hope that what we're doing is kind of welcoming these people with different sets of diverse interests and kind of bringing them together and allowing them to basically do whatever it takes amongst themselves to bring features and get them merged and that this notion that we can you know define what focus is for release and kind of control people and drive people towards contributing to the things that the top level project governance decides is important that we just simply don't have that control over our contributors. A counter point made which really took my breath away when I saw it was open stack is not an amateurish project done by volunteers in their spare time. So if you assume bad faith on the part of the person making this point you could unpack that in all sorts of horrible ways and and think the person is making some really horrible points there in terms of you know other projects are amateurish projects and we're not but I think the point that was actually being made here is there's there's there's some validity to it here in terms of most contributors to open stack are employed by companies who are building products based on open stack. A lot of those companies do have shared interests, shared views of where the project should go. If you're employed by a company that company can obviously set your priorities in terms of the things you spend time on. So there is this ability for these companies to get together to decide what's important for the project and then kind of direct their developers to focus on these specific things. So I don't like the way it was phrased I don't like some of the assumptions here but there is some grain of truth in a project like this that that there is the ability to kind of control contributors. So this notion that companies are representatives of companies are you know non non developer members of companies can actually work together is also spoiling this interesting phenomenon within open stack where the theory is from some people that there isn't you know developers making decisions together developers designing you know the project and setting the future of the project we're missing the input of what would be normally product managers at companies. So you know we're missing people who are directly talking to the users of the project you know bringing feedback from those users and using that feedback to kind of set the direction of the project and so there's a number of efforts within open stack now to actually explicitly bring product managers from different companies together to kind of share experience and then to somehow kind of take all of that combined input and use it to influence the direction of the project. This is going to be a really interesting experiment over the next year in all my time of open source I've seen a very small handful of product managers successfully kind of get involved with the project and meaningfully kind of contribute and influence the project forward in a way that developers value and kind of react to and here is a very concerted effort by you know I'd say dozens of product managers to kind of get together and provide that kind of input. How effective that's going to be is going to be really an interesting one to watch over the next year. So I'm just about out of time and just to draw that was a whole bunch of mostly unrelated kind of observations of our governance model over the last while but to draw some conclusions of some sort. When you're thinking about the product that the governance of your project are how your project runs I think one of the key things to reinforce is that we as contributors to a project we're first and foremost individuals. We might be employed by a company to work on a project but in order to have kind of this healthy collaborative model we must all act first and foremost as individuals and you know focus together on what's important for the project. But on flip side to that involving companies in your project is great right. If any of you here have not been involved with OpenStack but have heard of OpenStack it's largely down to the fact that we actually have you know brought all these companies together and pooled resources and invested a lot of money in marketing, invested a lot of money in events, you know invested a lot of money in the infrastructure that the project runs in. You know all of these resources come together has been part of OpenStack's success it has allowed us to kind of achieve what we've achieved so far. But as you bring companies into your project like this don't lose sight of what healthy a healthy collaborative project looks like and fight for the right balance between the governance of the the contributors directly you're kind of working on the project and bringing it forward versus these companies that are are bringing resources useful resources to the project yet you really think about what the balance is between those two actors within the project and fight for the right balance. So that's my conclusion and thanks for listening and welcome any questions. Thank you, you talked a lot about your early history with GNOME and GNOME has a the GNOME Foundation and GNOME Project has a different kind of governance model and do you think that well also I recollect that when the OpenStack Foundation was still an idea you proposed a sort of straw man idea for governance that was a little bit more like your experiences with with GNOME so do you think that the model of GNOME might have been better for OpenStack or maybe not as good maybe not as good at the goal of pooling resources because GNOME has the ability to get companies involved and there's an advisory board it does raise money from different companies that has rules about ensuring diversity of representation but obviously a very different kind of nonprofit organization model. Yep, absolutely. So as you point out when the Foundation was being formed and this was a point that Red Hat was just starting to get involved with the OpenStack Project and part of our evaluation I guess of the OpenStack Project I guess was just how healthy a collaborative model was going to be in this project and as the Foundation was being formed my big fear was that the companies involved was going to have too much control over the project so yes I proposed an alternative set of bylaws just as a kind of discussion point and what did draw heavily on GNOME's governance and the big distinction there what would have been that the the top level Foundation Board would have been entirely elected from people who are contributing to the project contributing in many different ways not just contributing code but there also would have been what GNOME has which is an advisory board which is made up of member companies who are contributing money to the project and so the elected board would have been the top level board and the advisory board would have advised the top level board I guess and for me that really would have really enforced that balance between the technical contributors having the control and the companies being kind of closely involved but not directly being able to control the project and I have I guess the problem with that is you know from companies perspectives there isn't a huge there isn't so much value in just being members of this advisory board rather than having more kind of explicit input to the governance so you might these companies might be less incentivized to contribute large amounts of resources to the project and so the balance with OpenStack was more about making the involvement of companies more meaningful so that they're willing to contribute more to the project while also not upsetting that balance it's a really interesting experiment and I have to admit that you know a lot of my fears were unfounded I think and we actually have managed to achieve a very good balance here and I guess you know the cases I talked about like the Contributor License Agreement and the the trademark license agreements are relatively small issues and they are the only cases where we're seeing any sort of conflict at all and I think we're actually we're generally getting the balance right between reviewing these kind of the two actors within the project we're out of time okay cool thank you we have a gift for you from the team thank you very much thank you