 Good morning. Welcome to DevConf 2019. First of all, thank you for everyone who woke up this early. It's way before programmers should wake up. So thank you for coming here. My name is Alon Mureinik, and I work for a company called Synopsys. I'm... Excuse me, Jitl. I manage Node.js and .NET agents for Seeker, which is our IAST product, or maybe more appropriate to say the best damn IAST product out there, but the talk isn't about IAST, so I'll move on. So I've been working with Open Source for about 20 years, and up until last year, I've been working full-time on Open Source, both as a developer and as a manager of other developers working on Open Source. And that was actually the most intense, the most profound, the most valuable learning experience I had throughout my career. And this is what I want to talk about today. Actually, how working on Open Source will make us... You, everyone, will make us better developers, even if you don't end up working on Open Source in the long haul. I had a couple of slides here about clarifications, which I'm not going to talk about, because apparently my time is a bit shorter than I thought, but if you have questions during the presentation, please raise your hand and ask. I want to do a formal Q&A afterwards. So I'm going to skip these introductions and just get started. So if we think about the term Open Source, obviously two parts are Open Source. Source obviously relating to source code. And that is not the part I want to concentrate on. I want to concentrate about the Open, not about the source, mainly due to this reason. This is a quote from a former indirect manager of mine, Matt Hicks. So who here thinks his job is to write code? Good. Just one person. So if you think your job is to write code, chances are that you're wrong. If you aren't wrong, and if you do really understand your job description and your job really is to write code, chances are you really don't have a good manager. If that's the case, please come talk to me afterwards. I'm hiring developers. We write a hell of a lot of code, but none of our job description is to write code. Just like a competitor's job description isn't to use a hammer. A competitor builds chairs, builds tables, beds, cupboards, I don't know. Hammer is a tool. Writing code is also a tool. It's a great tool, but this isn't our job. Our job is to produce value to our customers, to write features, to fix bugs, things like that. So, as I said, I don't want to talk about code. I want to focus on the openness part of it. But I can't. I'm sorry. I've been a developer for way too long and I just can't talk about open source without talking about code. So, are there any psychologists in the room speaking of code? Good. So, no one will notice and none since I'm going to speak now. But it's more or less true. I'm not a trained psychologist, but it should be roughly correct. So psychologists have kind of a rule of thumb. It takes about 10,000 hours of practice to be proficient in something. It depends on the skill you're trying to learn. It depends on the person. It depends on the situation. Yada, yada, yada, roughly 10,000 hours. So if you do the math, 10,000 hours is about four and a half, five years of work, or about two and a half, three years if you don't care for weekends, public holidays, sleeping, useless stuff like that. So why not bring this up? Because if you want to become a good programmer, you need to put in roughly at least 10,000 hours of practice. And open source is an excellent way to practice this. Now, some of us are lucky. Some of us get to write code during our day job. Lucky you. Some of us aren't that lucky. Some of us are students who are just at the beginning of our career. We don't have the option to write codes that much. Some of us made horrible career decisions and turned to the dark side and became managers. And now they need to drag around Gira tickets and answer emails instead of coding like a proper human being. So working in open source gives us unfortunate people a chance to practice. More than that, more than just 10,000 hours of practice, it really depends what you do with these 10,000 hours. I can promise you that if you wake up every day and write down Conway's Girl of Life, this is for five years, that's 10,000 hours, you will not become a good programmer. It won't happen. If you spend 10,000 hours solving programming puzzles on Stack Overflow and answering questions, you will not become a good programmer. Trust me on this, I have 180,000 reputation points on Stack Overflow and I still had to become a manager. That tells you how good that is. It's what you do with these 10,000 hours. Working on open source gives you the opportunity to write so-called real code to solve real problems with real constraints, real difficulties. Practicing that for 10,000 hours, if you do it correctly, will make you a better programmer, definitely. Sorry, I took a detour. I talked about coding although I said I wouldn't. Sorry about that, interlude. Let's go back to talk about what I wanted to talk about, about the open part of open source. We all know that open source has a lot of process around it, a lot. You can't just write your code and fix a bug. You need a commit message and your commit message needs to explain what you're doing and needs to have a sign off by at the bottom of it. It needs to have a link to a valid Gira ticket or Bugzilla or whatever you're using. That ticket needs to be approved by the Friac process in some products. You need to do it in the right sprint because thanks a lot for making the backend processing 10,000 times faster. This sprint is about Gira improvements. Come back next week. A whole lot of process. A whole lot of finagling around just to get your code in. Now, this sounds really annoying. Honestly, it is really annoying but this isn't unique to open source. This is a skill that will serve you in any big organization you end up working for. This ability to get stuff done and not only write the code and fix whatever bug you're fixing is invaluable and it will take you further in your career. Another big trait of open source is communication. A lot of communication, specifically async communication. When I say async, I don't mean AMQP or RabbitMQ. I mean communicating with people. Usually in a big or real open source project, there's very little you can do without communicating. It's a lot more than writing code. You find yourself engaging in communication. Some of this communication is obvious. You have your IRC channels and you have your Slack channels or HipChat channels. You have your mailing list and forums and Discord channels. What are cool kids using today? Still on IRC? Still on IRC. That's a lot of obvious communication but that's not the only communication you have submitted a patch. You want a maintainer to review it. You're communicating with him. There's a big difference between if he needs to reverse engineer your code then if the commit message explains exactly what you're doing and why you're doing it. That's communication. Have you ever submitted a bug? That's communication. There's a big difference between saying, I opened the software. I clicked on menu X then Y and it crashed. I'm working with version 1.2.3 installed on Reddit Enterprise Linux 7.6. I opened the software. I clicked here, here and here. Here's a screenshot. Here are the logs. Here are the call dumps. This is what I expect to happen. Both these bugs describe exactly the same situation. One of them will be fixed. One of them will be closed works for me. You can guess which one is which. The difference is communication. Have you ever reviewed a patch? All of these are forms of communication, even if you don't notice it. And like with the process, your ability to excuse the language. I'm sorry about the swearing and I don't know if I need to mute. But your ability to get shit done is often a lot more about how you communicate a change than how your ifs and for loops and while loops and code is set together. And again, people who take working on open source as a learning experience and learn how to do this effectively will be effective wherever they work. So far I've discussed a couple of things which are not unique to open source but are kind of exaggerated in open source. I want to move on to speak about things that are a bit more unique. I can't say more unique, but unique perhaps to open source. If you work on any commercial software, regardless if it's closed source proprietary or open source and backed by some commercial company, you have exactly one goal in the project to make money for your company. No other goals. Now, making money is great but sometimes conflict was best engineering practices. Who here ever had to ship a fix quickly to solve a critical bug? They had to do a horrible hack in the code that they were ashamed to tell anyone about? Shave hands. Okay, so some people are raising their hands. Some people aren't. Those who aren't raising your hands, you are either really early in your career or you're lying. So this happens a lot. When you're working on open source, you sometimes have a slightly different experience. Now, this is a typical experience I had as a manager managing development in open source was one of my engineers. So you agree this is a critical bug? Yes. And you agree this patch fixes it? Yes. And you agree we need to ship the version tomorrow, right? Yes. So are you going to commit it? No. What? No, no, we can't commit this fix. The community won't have it. The maintainer won't have it. It goes against the code basis philosophy. It fixes a critical bug for a customer. It pays us millions of dollars, please put it in. No. As a manager, this drove me nuts. Before working at Red Hat, I had a much darker hair and a longer hairline. The whole recession is from that experience. As a manager, this drove me nuts. As an engineer, this is excellent. As an engineer, you want to learn how to... Not even want to learn. As an engineer, one of the key skills you don't want to learn, you need to learn is how to take a big problem and break it down into smaller components, into layers, into microservices if you're a hipster. Microservices, by the way, are a lie. So just components wrapped with an HTTP API. Nothing new there. But this is a critical skill to learn as an engineer. And working on open source doesn't just teach you this. It kind of forces you to learn this because it's really not... It's really hard to bring in these external requirements. We don't care about customers. It's an open source project. You want to sell this, take your own fork. Now, once you've learned to do this properly, you can always break these assumptions and have your horrible hacks for your own customers. But you do this kind of from a place of understanding the trade-offs, a place of, yeah, that compiles what do I care, ship it. Ten years later, you can't maintain this mess. Another key difference, something really unique about open source, is the diversity. And I don't necessarily mean the diversity of contributors, but then people of different ages, races, genders, sexual orientations, political affiliation, cultures, countries, you know what else, all collaborating together. And I don't want to talk about that not because I don't think it's important. I think it's critically important. But I'm not going to discuss that for two reasons. First of all, I don't think I'm an expert on that. Okay, let's be honest, straight white dude. Not sure I'm the one that needs to talk about this. Actually, a bit later on, there's a talk by Jonah and Christie. I hope I'm pronouncing the first names correctly. I do not remember the last names, my apology. But it should be a bit later, I believe, in this room, all about diversity and building a diverse community. I intend to attend it, I encourage everyone else to attend it too. And the second reason I'm not going to discuss diversity in that aspect is because I don't think we are there. I don't think we're doing a good enough job, all of us, as an open source community. I think it's very, very premature to say open source does diversity better than closed or proprietary source. So putting that aside, I still want to talk about diversity but of a slightly different kind. I want to talk about the diversity of interests. When you are working on a proprietary code base, your code belongs to a company which again has exactly one goal to make money for the company. You do this by selling your product or service or whatever to your customers. So by definition, this is the only thing you care about. Open source allows different companies and different individuals and NPOs and NGOs and whatever to collaborate on the same source, on the same code base, sorry. And now you suddenly introduce a different kind of diversity. You introduce a diversity of interests, diversity of constraints. You suddenly can't just assume the software will run on Reddit Enterprise Linux. Maybe it needs to run on Ubuntu. Maybe someone wants to run it on Open Solaris. Maybe, God forbid, someone wants to run it on Windows. That happens, unfortunately. Maybe someone wants to take your enterprise virtualization software, which you assumed everyone will have $4,000 pieces on your really heavy and really impressive GUI and he wants to run it on a computer lab in a junior high school with laptops donated 10 years ago and it can't really handle your requirement for 4G or 10G of RAM. Yes, true story. Quite painful true story, actually. This happens in open source. This diversity creates much bigger challenges, much bigger problems to solve. Bigger challenges make better engineers. If you want to be a better engineer, work on open source. Work on a diverse open source project, where it's not just one company that just opened up its 10 million lines of code and said, yeah, everyone can contribute, but good luck of understanding what's going on here if you aren't part of the company. If you work on a really diverse open source project, you will become a better engineer. I guarantee it. The one last differentiator, something that is really unique to open source, is the way it breaks down this false dichotomy between passive consumers of your product or project and active participants, active producers. In open source, you don't have this distinction, or at least potentially you don't have this distinction. In theory, the project is open, everyone can become one of the people who make it. How much time do I have? Okay, so I have a time for a short example. So I'm working on a closed source project, product, sorry, and early on when I just joined, one of my tasks was to support Spring MVC. So I sat down and wrote a spec and understood that Spring MVC, which is a framework in Java to very easily build REST-type APIs, has a couple of ways to pass parameters to Java. So you can pass them as a string, coded, tested, done. You can pass them as a map, coded, tested, done. You can pass them as a multi-map. Spent a day just trying to make an example to work. I couldn't. Spent another day, still did not work. And I said, hey, wait a minute. Spring is open source, why don't I just read the code and see what the hills are doing under the hood there? So spent an hour reading the code, spoiler, there is absolutely no way Spring MVC can pass get parameters as a multi-map. It does not work. Could never work, never has worked. So I'd love to end this presentation with, and I wrote a patch to Spring to support multi-map parameters, but that would be a lie. I'll end this with, and I wrote a patch for Spring to fix the documentation and remove stuff that doesn't work. But hey, it's still open source. If I want to sum up everything I said in the last 20-something minutes, all of this can kind of be summed up in one word, teamwork. And this, for me, is really the big difference between people who write code and software engineers. We don't write code ourselves. We write code as part of teams, part of organizations, part of some bigger purpose. We interact with others in order to do that. And once you learn to do this properly, this will serve you anywhere you take your career and make you a better software engineer wherever you choose to go with that, whether it's open source, closed source, proprietary, whatever. Having been a software engineer for about 20 years and going from writing closed source to the point of two people know the code and no one else can touch it to working in open source to going back to closed source, there is no better way to learn these skills, specifically the skill teamwork, than working in open source. I think I have kind of a minute or so, if there are questions, I'd be happy to answer them. Yes, you have to have a thick skin. Unfortunately, this is our world. One of my first contributions in open source was in Apache Commons lang. I optimized some calculation. A couple of days later, I got a lengthy review from a professor of mathematics saying that it may look like an optimization, but you haven't formally proved it. People like you are better not writing code and please never touch this project again. Okay, well, I didn't formally prove it, but the tests run five times faster. Here's the patch, then want it, then take it. What can I do? A week later it was accepted without a formal proof. You really need to check your ego at the door and if you're easily offended or if you take critiques of your work as personal critiques, you'll have a bad time working in open source. I think we have run out of time. If you have any more questions or want to talk to me, if this interests you, my contact details are here. Obviously, share the presentation and I'll be around for the entire conference. So catch me up. Thank you for your time.