 We'll get started. This session will be about contributing to OpenStack. First of all, I apologize for my voice. I lost some time yesterday. Don't remember exactly when. This, in the first part, I'll introduce topology of the different types of contributions and why some are more interesting than others. And then Mark will explain how Red Hat contributes to upstream projects in general and OpenStack, in particular illustrating the points that I will work on. So as this summit proves, OpenStack is now a giant ecosystem that has attracted a lot of different companies. And at the heart of this ecosystem are the OpenStack projects. And those projects only exist through the contributions of the companies and individuals from our community. And that's because OpenStack is an open innovation project, which means an open source project where multiple companies will contribute as equals to a common independent technical playground. And in this type of setting, it's not really the producers on one side and the consumers of the software on the other side. It's not us versus you. It's really we are all in it together. And I was quoted as saying, you should not ask what OpenStack can do for you. You should ask what you can do for OpenStack. Because the best way of having something happen in OpenStack is actually to contribute the resources to make it happen within the common project. So I worked for Linux distributions before. And it's quite difficult for consumers of the distributions to become producers of the distro. Because the barrier of entry is quite high. It's difficult to learn all the distribution policies, all the languages that are involved in distribution packaging is too far away from what regular users of the distro are actually confronted to. And that's something I wanted to really fix early on in the OpenStack project, make it really easy to contribute. Did that by two different tricks. The first one is using the Python language. Python is easy to learn. It's easy to read. And it's also very friendly to the population of users we have, which are mostly systems administrators. So they can look into the code when it fails and see why it fails and then propose a bug fix. So it's really easy for them to go from consumers of the software to become a producer as well. The other part of it is maintaining an extremely open development infrastructure, an extremely easy one that is extremely easy to contribute to. We base that on what we call the four opens that you might have already seen. Open source, so the source code is available. It's up in GitHub. It's also Apache licensed. It's open community. We have technical meritocracy. We have public meetings that are logged. All our meetings are happening on IRC where they are logged. So it's quite easy for you to see what we are discussing. We hold no meetings in private. It's really transparent to open design. So we have the four days of the design summit that are happening during this OpenStack summit where everyone that wants to contribute a new feature or wants to work on something for the next six months will be able to confront these ideas with other developers that are forming the OpenStack developer community. And finally, it's open development. At least every change that is proposed to one of the OpenStack projects will end up in our code review system, and that includes infrastructure changes. And this is public. You can actually comment and participate in the review. You can see why changes are accepted or rejected. You can contribute your own insight to this. So it's really an extremely transparent process and inclusive process for people to turn from consumers of the software to producers of the software. So in the rest of my time, I'll introduce a topology of the different types of contributions. And there are multiple ways to look at it. One way is where does your contribution actually land? So we have what we call the core projects. Those are the main deliverables of the project, the core services that we deliver. That's far from being the only project that you can contribute. We have what we call the library project. There is an OpenStack common, soon to be renamed Oslo. That takes all the common code between the different core projects and make a common library that is used by multiple core projects at the same time. And client libraries, which are used by clients to access those core services. We have what we call the gating projects. Every change that is proposed to one of the OpenStack projects ends up triggering what we call the gate, which is a series of tests. Make sure that you didn't break anything in the process of proposing that change. So there is all the gating infrastructure. We basically deploy OpenStack at every change and pass a battery of you can contribute to that gating infrastructure, all the software we're using to deploy OpenStack in that setting. You can also contribute to the integration test suite that we are running to make sure that we didn't break anything. Last but not least, we have the supporting projects. There is the documentation without which all the code that we are producing would probably be useless. There is all the other core infrastructure projects ranging from the Garrett RC, but that we have in our RC channels to the Jenkins system that we are using for continuous integration. And all this is expressed as code that lives in a code repository. So if you want to participate in the administration of our core infrastructure, you can just propose changes to those projects. It's not just code. It's also documentation. It's also puppet recipients, lots of different things. So where? It's one way to look at it. Another way to look at it is how, what form does your contribution actually take? So one form is what I call the direct contributions, the obvious contributions. There is a new feature or a new bug fix that's a contribution that will end up in the code of also indirect contributions, like bug tree aging, making sure that all the incoming bug reports are treeaged and prioritized correctly. There is a raise management, but I'm just making sure that we deliver something at the end of those six months, making sure that we have all the development process follows the right canons and reason. There is a stable maintenance, back porting all the fixes, all the interesting bug fixes that were found in the current development cycle to the stable releases of openslack and making points releases so that you can actually upgrade your stable infrastructure and inherit all the bug fixes. There is a vulnerability handling that is making sure that you handle all the security reports that are reported to you, trusted parties. And finally, there is a general technical advocacy at conferences, making sure that openslack is well known. And you might ask where should I contribute or how should I contribute? Is there a better place or a better way to contribute? There is no best area to contribute or a best way to contribute. What's important is not where or how you're contributing, it's actually why you're contributing in openslack. And there are two different types of contributions if you look at that aspect in particular. There is what I call the tactical contributions. Tactical contributions are, if you, for example, propose a bug fix for a bug that you encounter in your precise use case. Or if you contribute a feature that makes sure that your own software, software that you're producing in your company interacts well with openslack. So those are made because they matter primarily to you and your company, and not necessarily to openslack in particular. And those are a number of drawbacks. Those are valuable contributions. I mean, the openslack wouldn't be where it is today close to tactical contributions. Those made what openslack what it is today. But there are a number of drawbacks. They tend to expand the scope of the project to add the technical depth. And if you don't put equivalent QA resources in openslack in power, they have to release and you dilute the quality of the end result. The solution to that is what I call strategic contributions. In strategic contributions, you are making the contribution primarily to ensure the long-term health of the project and making sure that the end result is of better quality. You can find strategic contributions in four different areas. One is commonality, making sure that you reduce duplication of effort. You actually refactor code so that you end up using the same code in the different projects. That is one aspect. Another is consistency, consistency both in the feature set but also making sure that there is no gap in the feature set of openslack but also it's also consistency in behavior, making sure that logging or configuration is done in the same way across all the different openslack projects. There is security, making sure that the software is actually safe for our users to use. And there is about fixing bugs, not only that affects your use case but that affects a large proportion of our users, so fixing the high priority bugs rather than your bugs. So there are a number of drawbacks with strategic contributions. Usually, tedious tasks, time intensive. So funding resources towards strategic contributions is expensive. And it's difficult to sell because there is no short-term return on investment. It's not beneficial directly to your company. It's actually beneficial to openslack in general. But strategic contributions are essential. It's what will make openslack win in the end. You might win because that's what will openslack a success. Also argue that it's actually good for you and your company as well. Doing tedious tasks and time intensive tasks, you end up gathering good karma within the community. And the way we are structured, the technical meritocracy that we are using, this karma quickly translates into respect. And that respect quickly translates into influence over the direction of the project. And so it's not just good for openslack. It's actually good for you to fund those strategic contributions that are essential to openslack. So in summary, if you don't contribute anything to openslack yet, you should start now. And if you have a choice, please consider doing strategic contributions rather than just tactical contributions. I've actually had a hard time figuring out how to actually contribute. All the indirect contributions are not code contributions. You could argue that they are not measured in the same way. Mark's scripts actually account for a lunchpad activity. So all the bug handling you're doing is actually recorded. But it's true if you participate to stable release management or release management, it's not accounted for. Or security, if you're proficient in one foreign language, you can also contribute translations. There is also the ability to contribute projects where it's not really code that ends up being deployed to more configurations. If you're a more seasoned main type than a developer type. Yeah, I guess he specifically said you're an architect. So I guess all of the openslack design discussions either happen on the mailing list or happen in the code review system. So I mean there's a huge amount of opportunity for people who aren't even contributing code to actually get involved with those discussions and really kind of drive the direction. Never used one of these clickers before. OK, so theory is given I guess kind of the theoretical background, made some really great distinctions between different contributions. And I really like the distinction it makes between tactical and strategic contributions. I guess for me that put into kind of crisp words something that I've always kind of believed strongly in. So it's good to see this being talked about. So we're going to talk specifically about kind of how Red Hat engages with projects and how we tend to make a lot of strategic contributions and why we do that. So it's trying to put, I guess, more meat on the bones of theory's argument here and kind of give a specific example. So just to give some background initially about Red Hat and OpenStack, we got involved with the project first just over a year ago. And really when I got involved first, I think the first thing we were trying to figure out was whether the project was really as kind of healthy and vibrant and diverse and self-governing as it seemed from the outside. And really the best way of figuring that out is just to actually get involved with the project and contribute and kind of see how your contributions are welcomed and received and how easy it is for you to actually make an impact in the project. All the signs were really, really good with OpenStack from the very first day that I submitted a patch to OpenStack. So to me that's a really key indicator of OpenStack's future success. So just some more background. At Red Hat, we'll often talk about wearing hats. And that's not just because we're called Red Hat. We'll talk about, for example, whether you're wearing your upstream hat or your distro hat or your corporate hat. And what we mean there is, I guess, like Thierry talked about, when you're making contribution, why are you making that contribution? Even when you're discussing something, it can be helpful to be clear about why you're making a suggestion or proposing something. And so you might be proposing it because you think it's really important to the project itself. Or you might propose it because it's important to distributions of OpenStack. Or you might propose it because it's specifically important to your company. And by default, I think we like our developers to gain the trust of the community that the community assumes that when we speak, we're speaking with our upstream hat on. And when we specifically want to represent Red Hat's point of view, we'll actually say it. We'll say, with my Red Hat hat on, I think we should do X. That's where you're stepping outside your normal mode of operation, where you are thinking specifically about the project and just thinking about what Red Hat in particular wants. OK, so I guess, why make strategic contributions to a project? So the first reason to me is the success. If you're a company getting involved with OpenStack, you're probably building a commercial product around it. And if you're basically on OpenStack, you want OpenStack to be around for a long time and you want it to be hugely successful. And really, you can't just stand around and wait for other people to do that. You need to be in there making OpenStack a success. And to me, that's the way to approach a project when you engage it is to really look for the parts of the project where you can see that success might be damaged by a certain part of the project not being funded or resourced, I guess. So like an example might be, if you see that bug triaging isn't handled very well in a project, although bug triaging isn't a very sexy thing to do in a project, it's really important to a project. So that's a good place to get involved. So it's really looking for the places where you can really make an impact to help OpenStack be a success in the long term. But another thing that actually Thierry didn't talk about was gaining expertise. If you have a commercial product based on OpenStack, you really, for it to be for customers to trust that you're going to be able to deliver on your promises, you really need to be seen as having a lot of expertise in OpenStack, really understanding the technology, but also understanding the dynamics of the community, who things are going to evolve into the future, and the last reason to make strategic contributions, as Thierry did point out, was influence. And so if you're involved with the project and then building a commercial product based on OpenStack, you really need to feel that you can deliver on your promises by actually getting the features, getting the direction of the project set in a way that kind of delivers on your promises, as I said. So to do that, you really need a lot of influence within the project, and the best way to gain influence, as Thierry said, is to build up that karma, make lots of contributions that help make the project a success. So here's some of Red Hat's OpenStack team, and I guess what I wanted to get onto next was, what specifically have some of these guys, and Gal, there is one Gal, what have they been up to to OpenStack? So I thought I'd talk first about some of the tactical contributions we've made. I won't talk too much about these, except to kind of show what I think of in terms of tactical contributions. So making OpenStack work very well on Fedora and RHEL, integrating some of Red Hat's kind of technologies into the project, like LibGestive S and Cupid, contributing to projects that are gonna be very important to some of our enterprise customers, like LDAP integration and Quantum and stuff like that. So that's, I guess, that's examples I'd see of tactical contributions, very important. We absolutely need to be doing this kind of work, but I guess we're here really to talk more about strategic contributions. So these are some of Red Hat's more strategic contributions in the project, and it's really a mixed bag of stuff. And really, to me, this was all the stuff that I really felt that could benefit from some of Red Hat developers being involved with. And I think we made a good impact on some of these things. So the first one is kind of infrastructure issues. So it's the basic technical infrastructure of all the different projects, how configuration files are handled, that kind of stuff. Bug fixes, and again, not tactical bug fixing, but looking at bugs that are being reported by users in all different sorts of contexts and actually helping getting the bug countdown by fixing some of those bugs. Code reviews, I think it's really essential to be involved with code reviews and really help drive the project in a good direction by contributing your thoughts to code reviews. And it's another great way of building up kind of respect and influence, because you take the time to review someone's patch in great detail and really provide good feedback that kind of gets the patch in a better direction. I think that's something that's valued by people. The stable wrench was something that, I guess, we started just around the same time that Red Hat got involved with the project. So I thought that was a very important thing to the project as well, and that in terms of if you start using a release like Essex, you really want to be able to get bug fixes for that Essex release without having to upgrade to Falsum. So I think that's been really well received as well. OpenStack Common, as Thierry mentioned, is a library, and to me it's an effort to clear up some of the technical dash within OpenStack where you've got all these different projects that are quite similar in infrastructure, and so they've copied and pasted code from one another without thinking about the long-term impact on the maintenance of the projects. So OpenStack Common is trying to clean all that up and bringing it. Vulnerability management is an interesting one as well. Thierry really kicked this off and really got things going well here, and I think OpenStack probably has one of the best vulnerability management processes in any open-source project out there. The way security reports are handled and disclosure coordinated with all the different distros, it's actually really, really good. So we got involved there very early on, and helped out there. Release management, I guess, I've been pitching in a little bit with release management around the stable branch. Bug triage, if you want to help out with Nova in particular, triaging bugs in Nova is actually a really big problem that the Nova project has at the moment, just trying to keep on top of the number of bugs coming in, and just making that initial triaging of whether the bug is valid, whether it's important. And so that's a great way that anyone here could help out with contributing to Nova. We've also been doing a lot of work around continuous integration. Not so much within the core projects continuous integration infrastructure, but one of our guys, Dan Prince, has been working on a project called SmokeStack, which really tries to do even more continuous integration around catching problems as they appear in trunk and basically catching those quickly and getting them fixed. And I guess the last thing, everything we talked about there was kind of technical strategic contributions, but we also made a big effort to really try and help with the establishment of the foundation and make that a success. So around debating how the foundation should be structured. One of our lawyers, Richard Fontana, was heavily involved with the drafting of the bylaws. So I guess that's all of, a lot of red hat strategic contributions and hopefully that kind of shows the contrast between kind of what we mean by tactical contributions and what we mean by strategic contributions. So that's pretty much me, me questions. Well, so that's the credits for some of the photos I use there, but any questions? Are you guys wearing the same shirt? He did notice that. Is long sleeves. Yeah, long sleeves. Mine's nicer. He didn't talk to you. Process perspective. I realize you have to wear multiple hats, right? Just everyone has to wear multiple hats, but have you found more success among different companies and this is both for your own companies as well as others that you're aware of in terms of participation, in terms of having dedicated groups that really focused on open stack participation or open source participation as opposed to sprinkling that. We do, in red hat we do tend to, actually you mentioned hats there. This is quite unusual for me to actually stand up here and really talk about red hat. I'm actually not used to wearing my red hat very often so I just thought I'd point that out. Yeah, so within red hat we tend to have a little bit of a split between say the guys who are doing a lot of work on rail for example versus the guys doing a lot of work on the upstream kernel, but you do need that mixture. You do need the upstream guys being able to, you know, pitch in at crunch time with the kind of red hat specific work. So, you know, I think it does help to have some separation but mixing the two groups is really kind of important too, I think. I would say that it's important that the people that you push to the projects actually contribute a significant share of time of their time to the project because otherwise they don't reach the visibility level inside the community that is necessary for you to reap the benefits of contributing to open stack. So there are other companies that are close that swath old because they just contribute like 20% of their time. So I would say that it's good if it's people that can contribute 80% or 200% of their time working on the upstream project so that you can reap the benefit as a contributor. But I agree with Mark with, it's also important to have people involved in open stack in all the teams, like the support teams, the distro teams as well because otherwise there is a disconnect. During those people have that 80% time available, it can actually be quite difficult because even from the perspective of the developer himself often they might feel that their work isn't valuable unless it's really kind of red hat specific work. So you often kind of have to really reinforce with people that we really value your upstream work. And often within red hat we'll say that kind of rail work can just suck up 100% of your time, just any available capacity of your time, it'll just suck up your time. So you really need to kind of ring fence that time to be upstream work time. And I used to work for canonical before and there was this problem as well where the distro work is like, it's really a time-sucking thing. So if people from the distros are the ones that are contributing to the upstream project, generally the distro will eat all the time space. But when I work on OpenStack funded by Rockspace I worked 100% of my time on OpenStack and actually made it difficult to switch to other companies because they wouldn't accept that you work 100% not on company stuff.