 We'll start in one minute. I've seen that done many times, but never succeeded. We're not too many. So if you want to come in front, you're welcome. It will feel warmer for everyone, me included. It actually works. Thank you, people. Much appreciated. So this talk is really about something I discovered, which is just a one-liner. Being a contributor is really powerful, more than you can imagine. And so I'm going to explain that in the context of Upstream University, which is really a big name for one training course. This is my hobby, a very time-consuming hobby. It has been for a year. It's also the professional occupation of Adolfo Brandes, the executive director of this tiny university with a single course. And in order to explain this single course, I will tell you what I mean exactly by contributor and by upstream, explaining that through my experience as an upstream and as a contributor. And then I will take an example of what is a very small contribution and what is a very large contribution, namely the salometer component of OpenStack, which is a contribution to OpenStack that was started back in March 2012. And then to show how a training course can help fill the gap between a very small contribution and a very large one, how you can speed up the process, I will explain how we design the course of Upstream University, and that will be it. That's the course. If you're here because you want technical tips on how to become a better OpenStack contributor, it won't be it. I will not disclose technical tricks that will make you all of a sudden a very successful contributor. It's mostly about soft skills and social things. Is it OK with everyone? Yeah? OK, nobody living in the room. Thank you. So an Upstream is someone who controls distribution. I take the image of a dam. Let's imagine that every patch, every potential patch to a software, let's say to OpenStack, is a drop behind the dam. Then the Upstream is the guy who controls the gates of the dam and let a little, the patches here, they pass the dam and they irrigate what we would call a free software project. In the case of most free software projects, it's just one guy who receives the GitHub pull request and he says, OK, I accept it. In the case of OpenStack, it's much more structured than that because you have this Garrett review process where it catches the patch and then Jenkins comes in, the robot testing the patch against the current master, the current trunk. And then only you have a human being coming in. The patch was caught. Jenkins is happy. The core reviewer says, OK, I'm also happy. And then it passes the gate. So in any case, the Upstream is this people, even with OpenStack where it's mostly automated. The Upstream has been, for the past 15 years, the growl of every company and every individual. Everybody wants to be an Upstream. OpenStack is the most magnificent example of a successful Upstream project. It's very impressive. It has thousands of contributors. But it's also something that is very complicated to achieve. Excuse me. Here. OK. Here. It's also something that is very complicated to achieve. When you want to chase contributors as an Upstream, you need about 1,000 users to have maybe one potential contributor. So you need to do a lot of marketing. I see here you are in marketing, to actually attract a contributor. And it poses problems then when you don't attract enough contributors, when you cannot be an Upstream and you are forced to use other Upstream projects. That's where Dave Neary talked about the cost of going it alone comes into play when a company takes an Upstream project inside and then forgets that there is an Upstream and tries to make patches internally, forgets to contribute them back. It's seen as a drawback of not being an Upstream. So a company, a very big company, very successful company, they want to be Upstreams. So it's the dream of every individual. It's the dream of every company. And to be honest, it has also been my dream at some point. What I did is during seven years, I created poker software. There is no poker software that is free software. I love free software. So I went there and I met cool 3D clients as this one in a very hostile environment where everybody was talking about proprietary software. And I tried to recruit contributors. And I was successful in recruiting contributors. So I felt really good about myself. I also made a living. We paid up to 10 salaries. So by the free software standards, by the book that was written by Carl Fosjell Producing Open Source Software, it was a success. Of course, nobody here heard about that. But for the 10, 20, 50 people involved in that, it was a successful free software project. I was happy to be an upstream. Then I stopped because one of my clients proposed to pay the invoice with a bag of money in the subway at midnight. And I decided that it was time for a change. And after seven years, I didn't know exactly what to do. So I decided to spend a year traveling the world of free software. That is, quit the dream of being an upstream and explore the world of being a contributor. What's magical about free software is that you can do that every day. So I went, actually, I looked at my screen. I say, OK, I'm using OpenStreetMap. So I go to the OpenStreetMap project. I look at the How to Contribute page. And I go to the IRC channel. I talk to people, find a bug because I am a developer. I work the day fixing this low-hanging fruit. And by the end of the day, I finish it up. And I say, OK, bye. Like the people farming during the summer, I go to the next field. And I will help for another day. Didn't always work like that because, for instance, a low-hanging fruit in LibreOffice turned out to be a two-month, really big assignment. But all in all, during a full year, I went from project to project. And it was a very rewarding experience. If you compare that to the pain I had to go when I was an upstream trying to attract people to be my contributors, to leave the upstream dream, being a contributor, I was hitting all the time. I was the dream come true for every upstream project I went to. They welcomed me. They have not seen a contributor for a month. Then I arrived. I contributed something. Of course, it always works. So I went from the world of being an upstream to the world of being a contributor. And it was so much easier. Then I got involved in OpenStack. It was beginning of last year. And so I started working on it as a contributor also. And I attended my first summit. When I went there, I saw a huge number of people. I've never seen that many people being contributors, potential contributors. It was also striking to see that a lot of them didn't manage to contribute for some reason. There was that all these discussions, people were in the summit and they were discussing about the fact that they didn't manage to have their code be upstreamed. But still, they had the proper tools. They knew how to develop. Also, in a lot of projects I saw, the manager had to be convinced that they had to give them permission to contribute. In the case of OpenStack, as you very well know, all the companies give permission. They even order their developers to upstream something. But for some reason, it was not enough. And I was looking for the problem. I told myself, it's bizarre. During a year before that, I went from project to project. And it was not uncommon to see that you had five developers working on the code base. Only one of them got the patch upstream. It was kind of common. What was striking last April was to see so many developers. So the magnitude of the project made me think about that there was a problem. But since I couldn't find, I couldn't point any problem. Everybody in this room, I think you see what I was looking for. And then I realized, most naturally, that there was no problem. Everybody can become a contributor, a successful contributor. That's what happens eventually. Let's take the example of someone from a large company used during 10 years working on proprietary software. All of a sudden, going to OpenStack, there is an adjustment to be made. Eventually, it will be made. But in the meantime, while there is some frustration, you're looking about ways to communicate with people who are not your colleagues. You see them every six months during the summit. And that's it. So there is an adjustment to be made. So I'm back with the image of the dam. There still are these many developers with many patches behind the dam, only a few going through because it takes time to adjust. And eventually, it will look like that. It will flow so much faster, in 10 years, maybe in 20 years. But could we get there faster, maybe? Instead of just waiting to become better at contributing, could we do something to be better contributor, to contribute faster when you get your patch rejected once or twice? Could you reduce that to just one? One rejection instead of two? Maybe one week spent in negotiating a blueprint, as opposed to two months? That would be a big improvement. Your manager would be happy. You would be happy. So I went to look for training programs because I'm no genius. So whenever I have an idea, I assume everybody thought about it before. And I will discover a training program. I asked Richard Stallman, who is a friend and travels all over the world, speaks to a lot of people about free software, getting better at free software, asking him, is there a training program I could use to become a better contributor, to learn new tricks, to be faster? He didn't know of any. I asked to Dave Neary, who is very passionate about communities and who he would know if there was a training program. But none of them. I asked Stefano, also, who was there at the time, say, there must be something. But there was nothing. If you know about the training program of that kind, I want to hear it. Please come to me or raise your hand. But at the time, last April, we didn't find any. So we decided, with all the people on this wall, to make a training program just to become better contributors. Making the training program was a little tricky. So I will shortly explain what I mean by a very simple contribution and what I mean by a very complex contribution, salometer, namely. So William O'Prendy is a student of the Université du Littoral in the north of France. And he was trained back in November by Upstream University. It was his first contribution to OpenStack. The class he was in, for half of them, they have never contributed anything to free software. So for them, it was really the first step. And in order for the first step to be a success, to give them a taste of what it's like to be a free software contributor, we picked a very simple OpenStack bug. OpenStack, because it's the most welcoming community I know in the world, and a very simple so that there is no technical difficulty associated to it. So as you can see, it was about replacing NovaVolume with Cinder, a simple typo. Of course, he succeeded in doing that quite shortly. But he had to go through all the process of being a contributor. All of a sudden, within a few hours of work for William, being a free software contributor changed from just being an idea to being actually something he has done. Moreover, he could be proud to say, I contributed to one of the biggest free software project in existence now. I'm an OpenStack contributor. Actually, this is not the simplest contribution he could have made. Answering with a link to a question on a mailing list, someone asked, can I contribute to OpenStack? So you send the link to the how to contribute page. That's a valid contribution. But it's not a contribution that requires permission from upstream. So one of the difficulty, one of the power of the contributor is that at some point, you get your work, you give it to someone with the upstream, and this someone takes it forever. If you disappear, then the code will leave without leave you. More difficult than a single patch is a blueprint. So that's why we are all here during the summit. We have ideas, and we want to convince people that they are worthy of being implemented. And this is something that is not just technical. Of course, if you're trying to convince someone that the blueprint is worth implementing, you better have development skills or someone with you with development skills to make it happen. Otherwise, it will stay something that is just an idea. And then there is, in my mind, the most difficult contribution of all, which would be to change the project governance. For instance, switching from a Rackspace project to an OpenStack Foundation project. This is the kind of contribution you can make to a Free Software project. It requires dedication, takes years. This is extraordinarily difficult. And more reachable, there is the example I want to give you, which is Sailometer. So I will shortly describe how Sailometer came to existence. Back in March 2012, I was with Nicolas Barcais. At the time, I was employed by Inovance, and Nicolas Barcais was employed by Canonical. All of that changed, as I suppose for most of you. And we had this problem that we needed to know how much resources OpenStack used, not just in theory, but precisely. And there was no component doing that. Moreover, we saw that it was not something that you could implement just as an external component. It was something that required every component to cooperate together. So it was more than a blueprint. It was something that had architectural consequences. And possibly, at the time, we said, maybe it could be a core component, maybe not. So we went to the summit with a blueprint, which was kind of modest, because we wanted something much bigger than a blueprint. But how do you convey an idea within the OpenStack community, if not with a blueprint? And we talked to a lot of people. And we had to change a myth that was, oh, you're speaking about billing. No, we're not speaking about billing. Billing is something completely different. Billing requires metering. But we're speaking about metering. Oh, really? Because this billing software also does metering. Or there already is some measurement coming on the bus, et cetera. So we spent a lot of time, even before trying to implement, to convince people that the idea was worth it. And to be honest, we realized, during the summit, by talking to people that we were not quite right. So the idea actually shifted, of course. But when we did that, we also acknowledged, as I said before that, we had to have the workforce to make it happen. So in this specific situation, Inovance had one employee who could be assigned to the work. And Canonical had no one. But we had one employee. So when we went to the summit, I knew that my company could dedicate technical resources to make it happen. As soon as the summit was finished, Julien D'Angous, who is now the PTL of Cerameter, started working, starting implementing code. He was soon joined by Doug Helman from Dreamhost. And together, they created the software that is now known as Cerameter. Now I could go on on the story, but the point is you can see the gap there is between William O'Prandee contribution and Cerameter contribution. Cerameter can also be seen as an upstream now, because some people contribute to Cerameter. But if you take OpenStack as a rule, it is a contribution and a large one. So how do you train to implement larger contributions faster and in a more easy way? If you are William O'Prandee, do you wait 20 years, or can you train? So we tried to design the training program as I showed before. William O'Prandee did not try to make something theoretical. He worked on an actual bug. So before the training, what every student does is pick a contribution that matters to him. So this weekend, for instance, we had students for a session, and each of them had a different contribution to work on. The goal of the training is to get the contribution upstream. So we work on an actual case. The first day of the training is live, and what we do in the morning is we go over the contribution process. It comes from how to contribute, who are you going to talk to, what are the technical difficulties, et cetera, up to the end of the process. When we go over this process, again, it's not in theory. Every student tries to apply the process to his own contribution. How will that work? Who will I talk to? Can I expect difficulties? And in the afternoon, after this theoretical display applying to the actual contribution, we go in simulation mode using Legos. So Legos is kind of used by agile training all over the world. It's a very useful tool where you do sprints and you learn to work collaboratively. It is adapted for upstream work because you always have a conflict between the agenda of your company and the agenda of the upstream. If it's not your company, it could be your own agenda or the agenda of a nonprofit you are involved with. In any case, you always have to manage, as a team member, as a contributor, you have to manage an overlap between your company agenda and the upstream agenda. If you're looking at contributing to OpenStack and there is no overlap, the patch gets rejected by OpenStack over and over, you must question yourself. Maybe you're not in the right place. Maybe you're contributing to the wrong project. So after this first day, we actually get to work. So the second day of the training is we make the contribution. Everybody, every student works on his contribution. First, by making a plan. So we take the process. They had the night to think about it. And they make 11 slides explaining how they will go about their contribution and what they will improve. In the case of someone who is already a proficient contributor, the goal of this training is to get better at it. If you already know how to patch, maybe there is something you can improve that will increase the number of patch you can upstream. Maybe if it takes you two weeks, you can reduce it to one week. And in the afternoon, we move to the online part of the program. So in order to do an actual contribution, the problem is you cannot squeeze that in two days unless you make a huge work with the PTR to make sure they are available during the training to approve the patch, that wouldn't fly. An actual patch takes weeks to be accepted because the interaction just takes a long time. So after these two days, we do a number of online sessions, one hour online sessions, where the student comes back to the mentor and says, okay, this is what I've done with the contribution and it went fairly well on this and this aspect. This is what I plan to do. And here, people train in Agile where we organize the stand-up meetings or the daily meetings. And this didn't quite work out and that's it. 15 minutes, time boxed. And then the next 45 minutes is dedicated to how can you improve the way you contribute? Maybe how can you work on a contribution that you've never done before and you have to tackle difficulties that you're completely unused to? So that's basically the training program. It applies to every individual at every level because as you already realized right now, it's much more about being coached, being trained to do that, being better at it, rather than learning a specific technique. Something you don't do on your own. I know I don't. When I take time with someone else to reflect on how I can improve myself, that works. When I try to just sit by myself, I go and do something else. And it also does not only apply to OpenStack. The first students we actually trained were Linux kernel developers. They came from a company where they were used to work on a proprietary Unix kernel. And I will not name the company. And it was a complete cultural shift for them to go to Linux to understand the community. And also the community of the Linux kernel, as you well know, is not as welcoming as OpenStack. It's much more difficult to get accepted. So they had to consciously work on their social skills to blend in. So finally, we have courses now and they address, as I said, students in the university, University of Littoral last year. This year, University of Littoral will again train students. And the University of Toulouse will open a slot for this program in their computer science department. So to teach first computer science students how to contribute. And if you are a teacher or a student and you want that in your university, Upstream University can provide all the material you need, even make the first course so that you know how to replicate it. Because Upstream University is a non-profit, it's not for profit. Yet it has to be sustainable because sometime I give the course, like I did this weekend, but when I don't have time, someone, Adolfo Brandes, for instance, is paid to do it. Or Rodolf Kiedewil, who recently joined, also give courses and he gets paid. So companies can for a fee send people who want to get better at contributing to Upstream University. And because it's a non-profit, of course if you're an individual and your manager does not want to hear about Upstream University and getting better at contributing, you can take your weekend. So we organize a weekend training for individuals for free. And if you are crazy enough to spend your weekend training for free, then you have it. And that's all I have for you. And now we have a few minutes I believe for questions if you have any. How long did I take? Okay, any questions? Nope. Yes. Oh, yes, please use the mic. I'm sorry about that, but it's recorded. You passed it to me, that's better. So, it's really terrible. So have you talked to Steph or Mark Collier about how to integrate this with the certification program that they're working on? No, okay. Steph, you mean Stefano? Stefano, yeah. Yeah, but I will. Okay, that would be great. Thank you for the tip, yes. Okay, so have you done any work or had any discussions about with any of the user groups and how there's different types of people that show up, there's the raw beginners are just showing up to find out what it's about, but there's also a contingent, usually around 10 to 20%, who want to learn how to become OpenStack developers. No, I didn't. What I found to be very difficult is to tell people you're not able to do that, I will teach you how to do that. The fact is contributing to OpenStack is so easy that anybody can do it. So I should, yes, talk to the user groups. Maybe Tim would be the guy to talk to. Yeah, or me. Or you, okay. I run the San Francisco Bay Area. Okay, so to offer training courses to get better at contributing, which works, yes. Because we've been working on and haven't quite finished it. And I'd be interested in talking to you about it, how to put together a hackathon which is basically a syllabus for training new developers. Not only in sourcing them, getting them up, and so they know the basics a little bit more than just reading a wiki page, but actually steps like you would for a university course. But also keeping them occupied right after that point. So do you give them a blueprint? Do you give them a list of, get the 10 high priority bugs and ideally do it in a collaborative environment like a user group. So people keep showing up week after week and they start to know each other. And there you can get peer-to-peer participation and the people are in the same area, so it works better. Yeah, that's a really nice idea. And actually, for some, there's a big fear factor about getting under IRC or the main list and actually putting yourself out there and getting over that. And during the live training, we get over that very easily, but as you say, there is a fear factor if you do it on your own, if you're with other people, then it comes naturally. Yes, yeah, that's all. Thank you for these two ideas, yes. Okay, great. Anyone, yes? Well, I'm more interesting in what was your biggest challenge making like cellular meter into getting into accepting the open stack. I know for a fact that contributing the open source is like a more like a social skills, starting with a simple patches and getting the community to know you or something. But then when, as you said, contributing to somewhere else, dreams is easy. But how do you make everybody else to contribute to your dream? Well, actually, cellular meter started by people accepting that we had a dream that we will work on it on our own, that is, they will not refuse that we make our dream reality. So it was easy in that respect. In order to move forward, we didn't have to ask to get consensus. We could move without consensus. And the consensus went as we moved. We grew more code. We got more people on board. So it's an ongoing process. This part was not too difficult. But what was the biggest challenge? I don't know because it's many moving parts. We can see now that cellular meter succeeded in a timeframe that couldn't be optimized. So we did a lot of things right. And despite the wrong things that we did, it went well. But if we had to explain, oh, you have to do that, this is the recipe to do that, I couldn't know. And the bigger the contribution is, the less it's likely that you have a recipe. It worked. And that's all I can say. It was not, there was nothing really complex. Yeah. Anyone? Okay. Thank you for listening. Thank you.