 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. 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 is the OpenStack project. And those projects only exist through the contributions of the companies and individuals. 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 plan. 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 making the resources to make it happen. 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. Users of the distro are actually confronted to. That's something I wanted to really fix early on in the OpenStack project, make it really easy to contribute tricks. The first one is using the Python language. But 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 based on what we call the four opens that you might have already seen, actually licensed, we're discussing we hold no meetings in private. These are the design summits 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. It's open development, that is every change that is proposed to one of the OpenStack projects will end up in our code review system. And that includes infrastructure changes. So this is public, you can actually see why changes are accepted or insights 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. In the rest of my ways to look at it, one way is the core services that we deliver. That's far from being the only project called the library project. There is an OpenStack common, soon to be renamed access those core services. We have what we call the gating project. 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 gate infrastructure, all the software we're using to deploy OpenStack in that setting. You can also contribute to areas of 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're 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. Contributions, the obvious contributions. There is a new feature, or a new bug fix. That's contributions that will end up in the code. But also in Garrett, there is a race management, and of those six months, there is a stable maintenance. Backporting all the fixes, all the interesting bug fixes that were found in the current development cycle to the stable releases of OpenStack, and making points releases so that you can actually upgrade your stable infrastructure and inherit all the bug fixes. There is a vulnerability differences. Is there a better place, or better? What's important is not where or how you're contributing. It's actually why. Typical contributions are also bug fix for a bug that you encounter in your precise use case. It acts well with OpenStack. Those are drawbacks. Those are valuable contributions. I mean, the OpenStack wouldn't be where it is today. Those made OpenStack where it is today. But they have had a number of drawbacks. Expand the scope of the project to add the technical depth. Fewer resources into release, and you dilute 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 find strategic contribution areas when it's commonality, making sure that 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 tag, but also it's also consistency in behavior, done in the same way across all the different OpenStack projects. There is security, making sure that the software is actually safe for our users to use. Fixing bugs, not only that affects your use case, but I have. So there are a number of two 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. Strategic contributions are essential. It's what will make OpenStack win in the 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. 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 OpenStack. It's actually good for you to fund those strategic contributions that are essential to OpenStack. So in summary, if you don't contribute anything to OpenStack yet, you should start now. And if you have a choice, please consider doing strategic contributions rather than in the same way. Mark's scripts actually account for a launchpad activity. So all the bug handling, you participate to, like, there is also the ambitions, if you're a more assistive-mint type than it does. Yeah, I guess, like, he specifically said you're an architect, so I guess all of the OpenStack 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. 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, 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, all first. I think the first thing we were trying to figure into was diverse and self-governing, as it seemed, from the outside. And really the best way of figuring that out, kind of see how your contributions are welcomed and received and how easy it is for you to actually, 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'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, making a suggestion or proposing something. And so you might be proposing it because you think it's really important to the project itself, because it's specifically important to your company. And by default, I think we like our developers to kind of gain, really assumes that when we speak, we're speaking to a 100% Red Hat's point of view. We'll actually, we'll say it. With my Red Hat hat on, I think we should do X. That's where you're kind of stepping outside your normal mode of operation. 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 an 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 the way to approach a project when you engage it. It's a really look for the parts of the project where you can see that success might be damaged by a certain project, 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. That actually, Thierry didn't talk about, was gaining expertise based on OpenStack. You really refer it to be customers to trust that you're on this. 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 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 a project and 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 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 contribution. Here's some of Red Hat's OpenStack team. And I guess what I wanted to get on to next was what specifically have some of these guys. And Gal, if we talk first about some of the tactile contributions we've made, I won't talk too much about these, except to show what I think of in terms of tactile contributions, making OpenStack work very well on analogies and into the project like LibGestive S and Cupid, contributing to projects that are going to be very important to some of our enterprise customers, like LDAP integration. So that's, I guess that's the 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. This was all the stuff that I really felt that could benefit from some of Red Hat developers being involved with. 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 users on reviews, I think it's really essential to be involved with code reviews. And really, it's another great way of building up because you take the time to review someone's patch in great detail and really provide good feedback that kind of gets the patch. The stable branch was something that I guess we started just around the same time that Red Hat got involved with the project. I thought that was a very important thing to the project as well, 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 kind of copied and pasted code from one another without, so OpenStack Common is trying to clean all that up and management is kind of an interesting one as well. Thierry really kicked this off and really OpenStack probably has one of the best vulnerability management processes in any open source project out there. The way security and different distros it's actually really 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. We've also been doing a lot of work around continuous integration, not so much within the kind of 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 it's 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 and I was heavily involved with the drafting of the bylaws. Red Hat's strategic contributions and hopefully that kind of shows the contrast between kind of what we mean by tactic contributions and what we mean by strategic contributions. That's the credits for some of the photos I used there, but any questions? Are you guys wearing the same shirt? Is Longstreet there? Mike Snyder, he didn't talk to you. Process perspective, I realize you have to wear them. 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 source participation as opposed to sprinkling. The hats there, it's 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. I've had it very often so I just thought I'd point that out. Yeah, so we didn't write out, 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. It does help to have some separation, but mixing the two groups is really kind of it. I would say that it's important that 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 OpenStack. So most that's swath old because said it's good if it's like the support teams as well. 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. This problem as well, 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 distros will be in space. But when I work on OpenStack, funded by Rockspace, I work for it, except that you work 100%. Thank you.