 Good afternoon, ladies and gentlemen. I would like to welcome you to this, the final actual talk of DevConf in this room this year. There is one more event in this room, which is the grand finale. I recommend you stay after this talk to win some, to have the possibility to win some fab prizes. But without any further ado, I will introduce you to Alon Murinak, who's going to present this final speech. Thank you. Thank you. The mic is okay. I'm Alon Murinak. I manage Rev's storage R&D team. And upstream, of course, I work on Overt, upstream project, open source data center virtualization solution. I contribute to some of the projects we have there, mainly to the Overt engine. Overt is a fascinating topic, which I will not discuss at all, except for these two sentences. There's been a bunch of sessions on Overt beforehand. Go look them up. They were awesome. So welcome to the last session of the last day of DevConf before the grand finale. First of all, I'd like to take the opportunity to say thank you to the organizers, all the volunteers, all the other lecturers. This was an awesome DevConf. Thank you, guys. Second, now that I've given credit rates to you, I've got a brand to pick with all of you. You kind of screwed me over. So I've presented in the two previous DevConfs, and came 2016. I was going to present a DevConf again. So I submitted a talk and some technical work with it and Overt. And I wasn't accepted. There were just too many good sessions this year. And, well, I said to myself, at this point in time, it's unacceptable for me not to present in Overt in DevConf, of course. It was just too awesome the last couple of years. I have to present in DevConf. What will I do? What will I do? What will I do? So let's try to submit a talk about something I'm really passionate about. And hopefully all of you are too. Open Source. So this is going to be kind of a Lessons Learned presentation for me. What I've learned in the last couple of years doing Open Source, managing in Open Source. And hopefully some of my lessons and my mistakes can help other people here. So I'd like to start off with a confession. In the dozen or so years of, dozen or so first years of my career, I was a really bad Open Source citizen. I started out in, started out working in the defense sector for about six years. And then I moved on to a smallish company of only 7,000 engineers. And we were later bought by a much less small company of about 350,000 engineers. And none of these companies really got Open Source or had any policy in place about Open Source. So I had a ton of Open Source stuff when I was growing up as a programmer. On the very bottom, you know, from operating systems, compilers, IDEs, your basic shell utilities, your LS, your CD, your RM. Used a ton of Open Source. But that's it, that's just it. Never occurred to me to give back. Who here ever encountered a bug in an Open Source project? So those of you who aren't raising your hands are either lying or not listening. So over these first 12 years of my career, I encountered a ton of bugs. Never even reported any of them. If I had to do something, I would kind of work my way around them, try to circumvent the issue. That all works until you encounter a really, really severe bug. So what do you do when you encounter a really severe bug in Open Source where you can't work around it? You fix it, it's Open Source, they give me the sources. So I took a look at the sources, found the bug, fixed it, recompiled it, and had my own personal version of Hibernate that was back in the day, which just worked perfectly for my solution. Awful, right? So every couple of months, Hibernate would come out with a new version. I had to take the sources again, reapply the patch, which of course was hell because back in the day it wasn't even in Git. So I just manually applied the patch. I usually broke the damn thing three different times until I got it right. But it kept moving on and it kept working. But this is not good Open Source citizenship. This is a really wrong way of using Open Source. And, well, frankly, despite the haircut, it's... I was just following orders. I'm not really that a bad person. I just did not grow up in a place that had an Open Source culture to it, an Open Source policy. Didn't know better. Didn't have anyone around me to slap me upside the head and say, hey, what the hell are you doing? This is not the way we work. So when I started my career, we had this really clear vision of just us and those people out there that do Open Source. Do you know these? Anyone met one of these people ever? Those people, they do Open Source. So who does Open Source? Or who do we think does Open Source? So now in Red Hat, if you ask us who does Open Source, well, obviously we do. We are God's gift to man. We are the upstreamers. We fight the good fight. We do things properly. Okay, yeah, sure. Don't get too hung up on yourselves, but sure. If you ask anyone from outside, so you have those people that do Open Source, these supermen, they sit down and write stuff that we use for some altruistic reason. And so we don't have to. Again, not a bad place to be. Just then get too caught up to yourself, with yourself, in yourself. It's too late for me to be thinking in English. And then again, those people who don't really get Open Source. Some people just like the closed source environments. I think the most extreme example I have encountered were database administrators, DBAs. So anyone here know any DBAs? Good. So I call myself two dog DBAs for two reasons. First of all, I have been one for a very long time. And second of all, I'm hoping there are no DBAs over here. And if there are, none of you know where I live. So as DBAs, we like our closed source environments. We like our Oracle Enterprise Database. We like our Microsoft SQL server. We like our robust complicated solutions. We like it where developers come to us and say, please, sir, my query is running too slowly. Can I please have an index? And you look at him, because obviously you've just been to lunch four hours ago and you can't really concentrate on work right now. No, of course not. No index for you. Come back one year. So we DBAs don't really like this concept of open source where everyone does what he wants. Database is mine. I don't want to share my toys if anyone has been to terms keynotes. If we talked about sharing, we can't not talk at least to some extent about ideology. I had a really interesting conversation with Jan Wilde Ball. I have no idea how to pronounce his surname. And he was telling me that he used to go into banks and these corporate America kind of companies and talk about open source and they would accuse him of communism. Because we don't like to share. But so there is definitely this view about open source. This is of course complete crap. Excuse the language. In the four short years I've been in Red Hat besides some sort of shared notion that we need to open the source and share information and stuff. I've met right wingers, left wingers, religious people, atheists, people of every gender affiliation, any age, any political affiliation, anything and everything. Open source is definitely not this closed anarchist club. You don't have to come with your citizen V mask or Guy Fox mask. But some people for some reason still think we do. If we continue talking about misconceptions, some people, let's say people from about a generation ago, let's say my parents, then get it at all and then get me wrong. I love my parents. I love my parents to death. They cannot fathom working five days a week on software, getting to your weekend, waking up an hour later because it's a weekend, yay, and doing some more software. They don't get it. If anyone has ever heard the saying, find a job you love and you'll never work a day in your life. So in that perspective, I had software in my free time and Red Hat is the stupidest company ever. They pay me to do this. What the hell? Truth be told, open sources are like any other programmers. We put down our pants one leg at a time. We wake up in the morning. We go to work. We get back at night. We just do things a bit differently. Someone say a bit better, maybe. But, okay, so far for misconceptions. So let's talk about some more misconceptions. Who here works on an open source project? Hopefully all of you, right? Okay. Who here ever started a new project and dumped a bunch of sources on GitHub? Or your favorite source control? Who thought that that made it open source? So, yeah, technically just dumping your sources on GitHub makes it open source because everyone can see and access your sources and everyone can modify them and do so privately or send you a pull request if you can ever understand how GitHub works. But that's besides the point. But open source in its essence is much, much more than that. It's not just about opening the sources. Open source is about communities. It's also about understanding that you don't just put your sources there openly because GitHub is free. You put them there because you want people to look at them and you want people to contribute to them because more people with more expertise, expertise, sorry, in different disciplines just create better results. And it's really neat to just dump your sources up and say, hey, I'm doing an open source project and, well, the world sucks because no one else is helping me out with this. Anyone had this experience ever? I did. It's not enough. You have to be proactive. You have to put the documentation up and make sure the documentation makes sense in version 3.5 even though you started writing it in version 1.0 and a few things have changed over time. You need to make it super easy for people to contribute. Do you have an issue tracker? Is it open? Are you publicizing it? When the program crashes, do you have a little message? Hey, we did something wrong. You might consider submitting a bug to http.colon, colon, blah, blah, blah. No, then do that. HTTPS, colon, slash, slash, blah, blah, blah. Much better. But you get the point, right? Is it a really good project or really out going, speaking of databases? Has anyone here ever tried contributing to Postgres? I did. Awesome project. So they have a landing page with open issues like we all have, but with issues that are suitable for new contributors, divided to skill levels, divided to areas of interest. So you could just go there and say, hey, I know Java and I'm pretty good with this JDBC stuff. Okay, here's a small issue I might handle, or I'm a really good C developer and I'm really proficient with storage. Here's something I can tackle. They really make it easy. They really make it inviting. They show you how to get help if you're stuck. More open source projects need to do this. If this is resonating with any of you, the best recommendation I have, there was a talk either yesterday or two days ago by Joe Brockmayer and again, I hope I'm pronouncing the name correctly. If you didn't go to it, check out the YouTube, check out the screencast. It was excellent. Joe just really resonates with you. Just ping him up. He has his details on the last slide and just ask him for help. Joe, if you're listening to this, I'm sorry I'm pimping out your help, but hey, you said please ping me up, so I'm delegating. So this was a hard lesson to learn about open source. Okay, what else did I learn about open source? Nobody knows you're a dog until you prove it. So for the dozen or so first years of my career, I started out in organizations that were really hierarchical, really compartmentalized. That's a $15 word for you. Really broken up into verticals. Everyone had his position. Everyone had his rank. I knew I was the database guy, so whenever you needed anything done with databases, people would come to me and I would hopefully help them. That's a really, really easy way to get things done quickly. It's a structure that creates really little place for debate. You come in, you have a short argument, hey, I need an index, you don't need an index, but my query is slow, go rewrite the query. Yes, but, yes, but, yes, but, stop. Are you the database guy? What, what, what? No, I didn't hear you. Are you the database guy? No, you aren't. I'm the database guy. Go rewrite your query. Really simple way to get stuff done really fast. Also a really simple way to reduce the amount of friends you have in the organization as you move along. And this is kind of a mentality that gets kind of ingrained in you. So I started at Red Hat. I started on the Rev project, so upstream over it. It was recruited mainly due to my database skills. So, excuse me. So I started and had my orientation and figured out where the kitchen was and where the toilet was and actually got to do some work. So I sat down and wrote a patch and sent it. So, well, yeah, I fixed the issue. I sent a patch, all done, right? No. So I turned aside to the person sitting next to me, a really nice guy called Omer. He said, hey, well, you know, I pushed it. What's next? I said, no, no, no, you don't get it. You aren't done. What do you mean I'm not done? I pushed it. It's in. I'm done. No, no, no. It's in source. It doesn't work this way. You need to send it and someone needs to look at it and review it and then we have these called maintainers that will take your patch and put it in the source tree. What the hell? I'm the database guy, right? Well, okay, fine. This is a weird way you work here. Sure, whatever. So I figured, yeah, I'll wait a couple of minutes until someone picks it up and merges my obviously brilliant patch and it took about 10 minutes and I got the patch back with 15 or so negative comments. What the hell? I'm the database guy. What just happened? Okay, fine. These people still don't know me. Let's try this again. So I fixed a couple of the comments and a couple of the comments I explained why I thought the comments were wrong and I repushed it. And I went to get a cup of coffee, came back and saw my patch back again. This time was only seven negative comments. What the hell? It took me a minute to understand I obviously did something wrong with my coffee. I obviously used a teaspoon of ego instead of a teaspoon of sugar. Don't do that, it tastes horrible. But, okay, I took another look at the patch set and I fixed it up again and sent it back and it came back again. It was another couple of comments and we went back and forth for two or three days and eventually this patch got merged. So on my first patch at Red Hat it took me about three days to do something I would have done in 10 minutes with any of my previous employers. This sounds ridiculous. But, but, but, but, but, but, that's a really bad way of measuring time. The real measure of time is how much work do you need to put into the damn thing. Not the first time you do it, but from now till the project dies. These two days or three days I don't remember of review cycles probably saved five or six different bugs that I wasn't thinking about because I didn't know the project that well and didn't know all the use cases. And it took two days instead of 10 minutes to get the first drop done. It also took two days instead of probably four weeks to get it done completely and never have to look at it again. This patch has been in for four years now. Zero problems in that area. So we did something right. This is a big plus of opening stuff up. You get more eyes on it. You get people to look at it. Even if you are the database guy, there are other smart people in the world probably much more than you because you're just someone who thinks he's the database guy. People actually know the stuff and it gets done in a much higher quality. This can be really annoying when you just start out. Definitely as a manager, it can be really, really annoying because there comes a time where you say hey, we need to get this version out. Tomorrow, can you give me a break from this upstream discussion? This is how we're going to do it. Just do it, get it done in 10 minutes and let's ship it. You can't do that. That's really annoying for a manager really, really annoying. But it does get better results ultimately and that's why we're here. The other really cool stuff about this is that it works both ways. This is a slogan Red Hat doesn't use anymore. I'm actually really sad we don't use it anymore. I really like the slogan. But as the slogan says, truth happens. The ideas have a way of becoming reality if you push them enough. If you're able to, if you have a good idea and you can really articulate it properly and explain it and defend it and convince people, it will happen even if you are just a dog or even worth a database guy. I started out with the Overt Engine. It's a pretty large Java project. The day we had 750,000 lines of code took 35 minutes to build. Does anyone here have the patience to build a 35 minute project? No, of course not. It's ridiculous. Out of those 35 minutes the main portion was running the unit tests. So what most people did was just MVN clean install, minus D skip tests. Hey, we build it in two minutes. We just didn't run the unit tests. Well, there's a much better way of doing that in that case, just remove them because what's the point in having unit tests if you don't run them? It's completely pointless. And that really irritated me because I really like unit tests. But I'm really impatient when I went around looking for 35 minutes once I run. So I dug a bit in the code and I figured out that one of our main problems is Power Mark, generally. So I don't know how many of you are Java developers here. I don't want to get into too much specifics. Long story short, Power Mark is a library that lets you mark stuff that traditional marking libraries like Easy Mark or Moquito don't. Specifically, it lets you mark static methods that are so by bytecode manipulation. Now, that's a really cool idea. I'm not smart enough to have written something like that. But it's really, really slow. It's really slow. So I sat down and looked at it a bit and understood that one of the reasons we use Power Mark is because our production code isn't set up to be tested. So I took this one class and hacked around the production code a bit just to expose a couple of endpoints and re-wrote the test without Power Mark. And that single test, I got to run in 15 seconds instead of a minute and a half, something like that. That's a times-eight improvement. So I... wrote a little patch, sent it upstream, got four negative reviews from four different maintainers who were already trying to be polite because in Red Hat we recruit nice people. But if you strip away the fake niceness, they were all basically saying, you're an idiot. We never touch production codes just to make your unit tests run faster. What the hell are you doing? Who recruited you anyway? So I tried to explain why this was a good idea and I tried to defend it and I tried to show that it was a really innocuous refactor to the production code which gave a really neat benefit to the testing part. And I took about a week and eventually that patch got in. So, okay, that took just a week. Cool. I can do things in week long sprints. So I did the same thing for another class. This time I only got three maintainers calling me an idiot in the first go. So I went through it again and I did the same convincing and kind of showed how it helped and eventually that one got in too. So one patch followed another and then two and then three and then a series and then all of them. So it took me about two months to read the code of power mark completely or almost completely. I think there was one little corner I couldn't solve. And I cut the build time down from 35 minutes to about three or four minutes. That's a time tense improvement. I'm not... If you look at my business card, I'm not a senior software testing engineer. I don't manage the JUnit team. I don't have Makito anywhere on my business card or in my org chart. I just am interested in these things and I'm passionate about them and I think we can do them better. So I just went on and did them better and convinced people we can do them better. And to the day, in over the engine, despite not having any official position, I somehow became the testing guy and people who try to do complex stuff with JUnit come up to me and say, hey, we're trying to do this. It doesn't quite work. Can you help us? Do you have any advice? Blah, blah, blah. Truth happens. If you have a good enough idea and you can explain it intelligently without resorting to I'm the database guy so it must be true, it will work and it will happen. And that's a really cool thing about open source. You don't need the title, you don't need any official credentials. Okay, since I do have 10 minutes, I'll, excuse me, want to talk about one last misconception people might have about open source. Has anyone heard about the land of open source that everyone does what he wants and just all send code all over the show and it somehow comes together by magic unicorns or something? So no, it doesn't work. That's another misconception closed source people have about open source. Open source bites very nature since we're built on collaborating with so many different people from so many different geos, so many different time zones and languages and cultural barriers. We can't resort to anarchy. Open source has bureaucracy around it, a ton of bureaucracy. Frankly, in many cases, much more than any closed source project because closed source projects are easy. The database guy commits the database code, that's it, end of story. He doesn't need to ask anyone, it's his code. We can't do this in open source. We have to have processes in place. We have to make it really clear how code gets in and what qualifies for codes that's good enough or not good enough and how we plan to release and now we move on to do features or do bugs or what bug prevents us from releasing a version. These things have to be really clear and really defined and they can sometimes be quite tiring but we have to have them because otherwise it's anarchy. And yes, this isn't freedom. This isn't free as in free beer but communities in general, societies, even if you forget about coding and open source and stuff. Society by its very definition is a bunch of people coming together waving some of the freedoms in order to live and prosper together and this is what we also strive to do in open source. We don't just commit code anywhere however we want. We wave some of these freedoms. It's not our private GitHub repo but we want to wave these freedoms because we want to be better together. So that was my 35-minute blurb about open source and the lessons I've learned. I hope you enjoyed it. I hope you at least take something from this. Since this is open source and we talked about communities so much so feedback is highly appreciated. Here's the link to the DevCon feedback page. If you prefer more private media feel free to shoot me up an email, a Twitter, a message in LinkedIn or just catch me here after the session. Thank you very much. So the question was where should I start with open source? Frankly, you need to go with a passion. Start with something you use. Start with something you care about. I care about databases deeply. The first place I looked at was open source databases. Postgres was my SQL. If you care about doing web pages in PHP look into WordPress. There's a ton of stuff they need solved. So you start with the passion because otherwise it's just another job and you don't want that, you already have a job. Then tier two is the expertise. You probably want to try to contribute to something you know about or have the technical skills to do. So if you're a Java programmer I wouldn't look into the Linux kernel as your first project. Might be not that it's that difficult it's just a different skill set. And the third tier of decision should be the community around it. So look around a bit, read the mailing list, read the issue trackers, see if they have any onboarding process if there are people willing to help you can shoot out an email. Hey, I'm a new contributor. I know X, Y, and Z. I want to help. What can I do? If it takes two weeks for someone to answer maybe not the best project to get involved with as your first one because it will take another four weeks for someone to take a look at your page later. Does that kind of answer your question? How do you want? Sorry. And if you're maintaining an open source project and you want to attract new contributors make it accessible. Don't make them look for stuff to do. Have your page. Here's stuff I want done. These are low-hanging fruits appropriate for students, appropriate for first-time developers. And here's my email. Shoot me up for help. Any other questions? Yes. Well, first of all the really, really basic rule is don't be a dick if you'll excuse the language. Yeah, I've had many projects where projects where Centerpatch got back this load of negative feedback, which again, negative feedback is feedback but there's a big difference between saying hey, this patch might not be the greatest idea because you haven't considered A, B, and C to you're an idiot why are you touching my precious project? First of all, after you make the whole first of all you have to make the whole process much easier. Once it's easy and accepting and whatever you have to deliver value because it's really easy for me to fork your project, fix it locally, and the hell with upstream. But if you continue delivering a good project and now it's my responsibility to keep on rebasing my fixes on top of your upstream which is good, and stable, and gives me new features that's a ton of work for me might as well just contribute upstream and have it in. And it's also nice to show recognition and a lot of projects do that you put on your issue tracker this issue fixed thanks to a long murening's contribution and have a nice start next to it. It sounds stupid but it really is. I know that everyone any Java developer who takes a look at the comments laying somewhere down in the release notes will see my name and see how I solved the null point exception somewhere. It's important. Any other questions? I believe now we're really done. So thank you again. You two guys come over and collect your scoffs and see you DevConf 2017. Thank you. Come on in. Am I presenting now or am I too early? So guys, is this thing on? Can everyone hear me? Okay so before you sit down you need one thing from these nice girls over here a red and green paper, piece of paper. Everyone has to have a red and green piece of paper if you want to win something unless you want to just sit here and do nothing.