My Story with Python and Open Source
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Iarocci, Nicola
This is the story of how I (and with me, my company) went from lonely, introvert, C# developer to open-source Python author and maintainer, speaker, trainer, consultant, and all-around community junkie. With some luck, in the process, you will also hear a few hints on how to become a good open source contributor and have a chance to ponder on the pros and cons (yes there are cons too) of going full monty with open source. We will also look at what changed in my company as we slowly switched from closed, in-house eco-systems to the open source field.
 So, let me start with a couple of questions. How many of you are actually using open source in their everyday workflow, be it professional or hobby or whatever? So, like, 99% of the audience which is expected since we are here. And how many of you are actual contributors to open source and somehow, I don't know, by submitting full request? Nice, not too bad actually. So, you don't really need my talk, you can leave the room right now. Great, that's nice. So, let's say about 50% of you are already contributing to open source. This is kind of expected since we are here at the Python conference. Anyway, what I'm going to do today is tell you my story, my personal story with open source. The idea is to, of course, try to inspire people who are willing or would like to start contributing to open source. Also, I would kind of give you a perspective from the point of view of a company who has never been into open source at some point because some weirdo in the company decides to adopt open source, the company follows along and starts using open source within its own workflow and products. So, let's start. I am a number of things in my company that call me the weirdo because in their opinion, I just do too much stuff. I have too much stuff in my hands which is probably true. I had this point in time. But we will get back to this slide in a few minutes. What really matters here is that I started my professional career back in 1991. So, yes, I'm that old. And back then it was a MS-DOS developer, basically, back then even Windows wasn't yet a thing. And I was basically doing C language in the C language stuff in MS-DOS and some other environments. And what we were doing as our company was starting building Windows software back then. But back then Windows wasn't really a thing. And when we were going and introducing our software to computer shops, vendors, and users, they were like, why are you doing Windows? Nobody uses Windows nowadays. Everybody is using MS-DOS. So, you get the idea of the environment and the ecosystem we were working with back then. So, we basically were two of us, two co-founders of a small company. Back in 1991, nobody used to call new company startups. But in retrospective, we could call it a startup. And what we were doing was one of us was writing code in the office. The other guy was jumping on a car. And back then the software, by the way, was sold in boxes, actual card box boxes. And the software was in floppy disks. And if you have, I guess, you know what a floppy disk is. And basically, I had my trunk in the car filled with boxes and it would go around in Italy and try to sell my software to computer shops. Computer shops would then sell the software to end users, right? So, the next week I would be coding while my colleague was going around in Italy selling our software. And we were just copying the floppy disks from our computers and putting them into the boxes and filling the trunk of our car. That's how software was produced back then. That's been going on for a while for a number of years, actually. Windows became a thing, actually. People were using it. Our software was successful, probably because we were the first back then doing that kind of thing. So, we were really strategically well positioned to get the market, our market share in the Italian market, anyway. And yes, over time we did a lot of stuff, basically. Nowadays our main product is an invoicing and accounting application. It is a desktop application. I wrote it a number of years ago, actually, and it is a C-sharp application. So, yes, I'm a C-sharp guy at a Python conference. But the thing is that at some point the direction we were, I mean, I was just sitting in my comfort zone building my stuff, my software. I was very comfortable with the technology and the stack I was using. We were using Microsoft technology, basically. We were dotnet shop in late, I should say, in the 2000s and stuff like that, 2010. At some point I really wanted to try something new. At that point the technology or I should say the market was requiring us to write mobile applications and web applications because people using our app on their desktop, they wanted to also use, you know, printing voices or doing venturi stuff when they were moving around on their mobile applications and on the web. So, we were to write some server, some probably API that our desktop applications could talk to. And that's when I wanted to try something new. I wanted to get out on my comfort zone. And those were the years when Steve Ballmer in Microsoft was basically 2001. Steve Ballmer went and said that open source was not trustworthy, trustworthy, sorry. And that really didn't resonate with me. I was, again, a dotnet guy working with the Microsoft ecosystem, but that really didn't, I didn't really like that approach to, the approach Microsoft was taking to the solution of problems, I should say, the strategy they were looking at. So, I started looking at something as what was going to happen outside of my comfort zone. And that's when I started looking at Python and the open source world, et cetera. Long story short, at some point, I was quite proficient with Python and the guys in my company were really concerned about my, the direction I was taking back then. They weren't really sure. The idea basically was I was wasting our time. But, yes, I went to Europe Python in, I think, 2012. It was in Florence. And I went there with a talk about how to build the rest APIs with Flask. Now, mind you, I was a C sharp guy talking for the first time in English, by the way, at the Europe Python conference and doing a workshop about building the rest APIs with Flask. So, if any of you was listening to Daniela Procida talk before this one, he was about NAVE programming. That talk really resonates with me because when I went there to Europe Python, I was very NAVE and, I mean, I was speaking to Python programmers about something which was totally new to me. What I was doing there, really, was trying to validate, asking for validation about my idea on how the rest API was supposed to be working and how I would solve the problem. So, it wasn't really me going there and teaching people. But more like people, I'm doing this, I'm doing this this way. What do you think about this? And in my world, in the C sharp and dot net world, something like this, really, I've never seen something like that. And the reason I was doing that probably because the open source and the Python community was so much welcoming to me, I felt safe to do something like that in public. Now, what's interesting to the story is that at the end of the talk, people came to me and said, look, what you're doing is amazing. Why don't you release this stuff as open source? Now, the framework for building rest APIs was already in place. I was, I basically, it was ready, but it wasn't open source. So, I went back to my company, we talked about it at the end of the day. We released our rest API framework as an open source framework. I don't know if you know about it, not really important. I just want to show you that we went and released something as open source. This is something that is based on Flask and you can basically very easily deploy rest APIs based on top of Flask, basically. It is a mildly successful framework, I would say. People are using it all over the world. You can say by the number of stars that there is average adoption. Of course, it's not Django, I mean, or it's not Flask itself, but it is working very well. And then after Eve, I also released Cerberus, which is a data validation framework. It is actually Eve dependency. Since everybody does data validation, even rest frameworks need to do data validation. So, I had to do the stuff. And since I was doing it, I might as well release it as open source again. So, Cerberus was born. Now, look at the GitHub stars here. They are like five times less than Eve's, but a point I want to make is that actually Cerberus is doing three times the downloads and the user base than Eve itself. So, one lesson for this talk, probably not very important, is don't really look at the GitHub stars number as an indication of how successful the framework is. There are some super cool packages on GitHub that have maybe 10 or a few hundred stars and they are widely adopted by the community. Just nobody goes there and starts the, to start the repository. And then, because we were successful, I mean, I was having so much fun, by the way, maintaining these projects in the open source. We went back to our C-Sharp stack. And by the way, in the meantime, Microsoft was kind of catching up because as you probably know, nowadays, Microsoft does a ton of stuff as open source. And we will talk about that later. So, we are also releasing, oh, sorry, the eVecos system has been spawning, the community has been growing. And as you can see, there are a number of projects, extensions for C-COLA, C-MU, for example, for OpenAPI, or I don't know, for authentication, stuff like that. So the community has been growing around the eVe project. And a number of people, the eVe project itself is like, I don't know, 150 contributors to the project, actual code contributors. But there are people working on these extensions, for example. There are about 10 people working on it. So, yes, success, in a way or another. We went back to C-Sharp and I'm starting to release a C-Sharp and.NET open source. Now, look at the number of stars there. Of course, the factor, the scale factor is quite different in the.NET world. People are not really used to consuming and embracing, adopting open source projects as we do in the Python space. But it is happening, actually. People are using this Italian project. You probably can't understand anything about it, but it is just for the Italian market. But in the Italian market, people are actually using it widely. Just they don't even know there is a GitHub and they have to go and start it if they like it. They just download the package and use it in their own application. So in doing all this process, I learned a number of things, a number of very nice and bad things happening to me. I'm going to show you some of them. And some of them, since most of you are already, 15% of you are already contributors know everything about this. But let's just browse them because I have a few considerations and things I want to share with you. Like I did six years ago at the Flash Talk. So, new feature, of course. My company was shocked when people started adding features to our framework for free. Now, if we look at a project from the company perspective, we're getting new powerful features for free. This one is very nice because the document versioning in its essence is people can edit a document over the rest framework, delete it, yes, but edit, change the document many times. Now, thanks to this version, you can go and ask a specific version of the document at a certain point in time. You can even ask for the diff between the document like you would do with Git, for example. This feature is super powerful. I didn't write one line of code about it. And as you can see by the number of files touched by this feature, it was quite a huge contributor, contribution. And Josh, by the way, he doesn't work there anymore. But back then, this was a contribution done by a very nice and famous company. I can't really mention it because for the secure NDA regions, but let's just say that they send spaceships to the International Space Station and it is not an ESA. So, you probably can get an idea of which company it is. And they're actually the spaceships they're using to send stuff to the International Space Station. And some part of the engineering around the spaceship is actually using an EVE instance to, it is being used somehow. I don't know how within their laboratories to store information about the engineering stuff, the design of the devices, et cetera. And of course, bug fixes. This is another very important feature for the company. Company is seeing value in our products, in our open source project now because we get bug fixed for free even before we know about them and we learn about them, which is how many, how much money we spent in 25 years on the field fixing bugs that people were actually complaining about and we couldn't even reproduce them locally in our closed source company. Now things have changed. People are like, look, there is a bug and this is the fix for the bug. And so we don't, I mean, how nice is that if you are a company producing software? I mean, not all the bugs are solved like this. I'm still fixing bugs every single day, but many of them are, I don't even have to fix them. And this is very important in my opinion, quality and longevity of a project. So more I see more that's how I put it basically. Look at this contribution. Now I'd like to contribute to the project so I started the whole through basically the documentation. Sorry, not the documentation, but he went and started looking at the doc string so every single function and method we had in the framework and fixed a few types as he says. Actually, he touched the 21 files against and if we go and let's see if I can show you, yes, readable. Yes. So these guys probably doesn't know much about Python. Otherwise he would be fixing bug or finding, I don't know, issues in my code, et cetera, but he still wanted to contribute. So he went and started looking at the doc strings and there were so many errors. Mostly because I'm not an active speaker as you can tell by this little me. And so he went and fixed all this stuff. As you can see just typos, you might say stupid things, but this code has been on GitHub for four years. So how many people have been reading these doc strings in the lifespan of this project and looking at the mistakes and the typos and going like first, this Nikola guy that really doesn't know anything about English and second, they should fix it. Finally, one guy, one naive guy probably coming from, I don't know, just for the enthusiasm he had in the project, went and fixed this. And now finally, after four or five years, the doc strings are hopefully fixed or way more fixed than before. So I really value this contribution because this is the kind of approach that somebody who wants to start contributing to open source can do very easily and contribute a lot of value to the project itself. Because when the people like you, new adopters of the project, go and look at the code, don't have to mess with my mistakes in the doc strings. So many mistakes, by the way. So this is a very nice example of how even non-skilled or probably just shy people can still start and contribute to open source project and contribute value without even touching one line of code. Again, the community nowadays, when I want to change something in the framework, be it the eFrame or Cerberus or my C-sharp code, I don't go to my colleagues or I go to my colleagues, of course. But I also go to the community. I just open a ticket and I go like, I would like to implement a fluent API, for example, for this project. What do you guys think about it? So suddenly, it's not just five or six of us in our office. It's probably tens or hundreds or sometimes thousands of people talking about design feature. So we have a lot more feedback about that, how powerful and important that is. Of course, it also means that you have to spend a lot of time talking to people, which has a cost, yes, can be taxing, but it is still worth it, in my opinion. Because at the end of the day, the design is probably more sound. There are new ideas coming from people who are not on the same rails as we are in the office and can contribute innovative, new, fresh ideas and approaches. For example, by the way, here, I was about working on this new API and this Pedro guy came and told me, look, go and look at the MongoDB implementation. They already have a fluent API. So probably a good idea, but might be look at what has been already done in this space. And honestly, I didn't think about it. So it was a good idea. I went and it was inspired by the MongoDB implementation of this particular API. Another important aspect that people usually don't really consider are the language and cultural barriers. So not just how good are you speaking English, but also the cultural differences that are around the world. So somebody from the Eastern Asia or maybe from Russia might open a ticket about a bag and be, especially from the Eastern Europe, he would be probably very direct, like look, there is a bug here. Fix it. Somebody asks from Western Europe for the same bug, would go like, hey, you know, very nice framework. Thank you. I really love it. We are using it in production. Thank you. Thank you. Thank you. There is a bug. Can you probably go there and look at it, fix it? So you see very different approaches to the same exact bug. The first one might come across to me as somebody not really nice, somebody I don't really feel like helping. Maybe I look at the bug from the Western Europe guy because he's so nice. But actually the two people have the same problem and the same in the Eastern Europe guy is as nice as the Western Europe guy. It is just a cultural difference. They approach, they take the language in a different, they think in different ways probably, but they are asking for the same solution, right? I don't know if I'm getting my point across. But I want to say that people all over the world are speaking, approaching to problems, a solution in different ways. You have to learn and deal and also understand that they communicate in different ways. And also there is a language barrier, real language barrier, because we don't speak English. I don't speak English well. This guy doesn't speak English well. And Amadeo is obviously a Latin guy. He's actually Italian. He's not an English speaker either. So sometimes it really gets weird, but you have to process all of these and make sure you understand everything is the context very well. And speaking of downsides, maintenance, maintenance of an open source project can really become a burden. It actually is for my own open source projects. Right now only we have, well, actually way less than these open tickets, but just because I have bought closing tickets which are older than one here, because I couldn't handle all of that alone. But at some point in time when your project is, becomes successful, you start having just too many tickets you can deal with. So you have to really, you every single minute you get an email, probably as I'm speaking right now, I'm getting emails from people that are wants a new feature or have some issue with the framework, ask for help. And so it can really become taxing. You feel responsible for these people. There is some guy in Dubai who has a problem with my framework and I really would like to help him, but right now I have to do this and that because I'm making money there and this is free activity. I need to do that on Saturday morning, maybe on Sunday evening. I've been doing all of this for many years and I can assure you when you have a family with three kids and a dog, et cetera, it really becomes taxing. So that's probably a negative and you, if you are contributing to an open source, many of you are already contributing so probably know everything about it. At some point probably you got stressed because the maintainer wasn't really looking at your ticket. So you go and look at the code and fix it yourself and then contributed with a pull request just because you were stressed that the maintainer wasn't looking at your issue. Anybody? No, I guess, okay. That's good. And if you are into open source for making money or if you think that open source can give you money, this is what I'm doing from open source on Patreon right now, actually I have four contributors, sorry, four Patreon sites, they call them right now. So I'm making four bucks a month for my open source activity. So if you want to get it open source for the money, well, maybe you consider that and find some alternative ways to make money. I mean, there are very successful projects who are doing good money in the open source but you really need to get there if you want to make the money, like not 5,000 stars, maybe 100,000 stars, then maybe you are starting to see some money coming from this because people will look at the project, read the documentation, adopt it, make money over it and maybe even think, yes, we need to contribute to this project because it is so cool but then somehow they forget to do that, right? So you need to get creative. For example, I don't know if any of you knows about the Python podcast, it is a very nice podcast in the Python space run by Michael Kennedy and he asked me if I wanted to actually produce a course about the framework and he would sell it on his platform, I did that, it was very hard for me to do that but in the end there I'm getting some more money, more than the 4 bucks amount I'm making from the Patreon campaign. So if you want to make money in open source, there are ways but you are really to work hard to get there and we will see that also I'm making money collateral money from my open source activity but not just directly from the open source contributions which unfortunately are very low. So let's look at the consequences of my story. When I started looking at Python and the open source I was just a very shy introvert, C sharp and previously C developer working all day in my office and then at 5 p.m. I would just leave and go home and stay with my wife. Then somebody I really I went to Europe Python, I released the EVE as an open source, somebody I don't know if it was my poor luck or unlucky, went and posted the framework on EVE on Hacker News back in the day and that's when the will started to just move too fast for me. In one day I got like 1,000 stars on GitHub, people started emailing me contributing to requests that day I became an open source maintainer basically. Until then people really were not caring about my open source project. That I started or I should say I went back to speaking and I started talking about my open source project, people were actually asking me to go and talk at the conferences about my open source project or my activity in general. I had been talking about a number of topics but mainly about my own open source projects but speaking for me was something totally new. Again, it might not appear right now but I am really a shy person so for me going out and speaking about my things, my story, it was really hard for me to do in the beginning. So yes, even if you are shy and introverted you might be a very good, surely better than me speaker in the future if you want to try that. And then because I was doing the rest API stuff on the web and my framework was being adopted by many companies, I started getting consulting contract work just because people wanted me to go and for example here in Edinburgh three years ago I went to the university because they were using it in their own projects and they got in touch with me and said, look if you come here for one week you probably can do the work we will do in six months so just come here, we pay you and you fix the project for us and we move forward. And I did that, I had a lot of fun by the way, it was great, think about that, going and do contract work for your own open source framework. How many days is that? Very nice. I love that. It's been happening since then a few times. So money for my open source project finally, yeah. And also teaching, I've been teaching Python in general not just my open source projects. I started creating communities, for example this local community in my own city. So every month we meet, I try to encourage people to start speaking at these small events, maybe we have 40 people and then people start getting confidence with this and maybe start going and speaking at real conferences and not just the meetups, et cetera. And this is fun because at the end of the day, three years ago, Microsoft came back to me and for the last 10 years I've been working 50% of C-sharp and 50% of Python. I still do this, to this day I still work a lot on C-sharp space and they wanted to award me for my work in the developer technologies. But the real story was that I was trying to flee from that ecosystem and going again, you know, all about it already, I went and started working on Python. I didn't really want to work in that ecosystem anymore. And again, Microsoft very slowly but they kind of catch it up with me and now they are totally all some open source company. I probably many of you are using a voice code, Visual Studio code as a text editor. They are the main contributor to GitHub. They have a number of main open source projects. I got these awards from them and every once a year we get to go to the Microsoft headquarters in Seattle and I get to talk with the actual developers who are making the.NET framework,.NET core, et cetera. And it is funny because when I started working with Flask open source and I could see the code behind the framework I was using, for me it was a total revelation of how powerful open source would be. And now speaking to these guys, they are so excited, as excited as it was 10 years ago. They are so happy that they now can embrace open source and work on them on it and seeing them so excited about it. I know that Microsoft isn't going back. If you are afraid that Microsoft will be going back someday or try to trap you into their ecosystem as they used to do years ago, don't be afraid. Microsoft is a totally new company and because I see the guys working on the actual project, I know that you can't stop them anymore. You can't put them in a cage anymore as they used to be working in the past. So, kind of funny. Also, I got an award for MongoDB, et cetera, not really important, but and this is important actually. So, because I'm speaking, because I have open source software and every time I put a line of code on GitHub, I know that there are probably hundreds or thousands of people reviewing my code. I really have to do my job at the best I can perform, right? Which usually means that people will still find the issues with my code and review it and fix the bugs again or complain that I could adopt a different solution, but it is okay. This is a slide from a Git talk I did last year. Not really, just don't look at the code, but in order to understand Git, I mean I use Git every day. I maintain projects, pull requests, rebase, et cetera. I went and started speaking about how I use Git, but in order to talk about Git, you really need to control the tool. So, I have to learn it even more than I know it just because I need to go and teach it. So, basically for me, this means learning every single day. Every single day, I still spend one hour every morning, really early in the morning, just to learn because I need to know the tools. Every, you all do that, but because if you go in front of the, of a public, be it by speaking or because you have an open source project, you have to maintain it, you really have to do learning very well. Networking, as the French say. Nowadays, I know a lot of people in the Python space and yeah, it's extremely powerful. I can count the number of times that somebody from across the world has been helping me with something that has nothing to do with the actual open source framework. Maybe I need to fly to Dubai for a contract work. And somebody from Dubai will, I don't know, help me or even take me to their house and stuff like that. So, networking is super powerful and because I'm so grateful because of open source, I got to meet so many cool people and guys and guys all around the world. It is extremely powerful and useful also. So now, I do all of this stuff and open source to me really rock my wall. I totally changed the way I work, my workflows, the people I work with is not, again, not four or five people anymore but thousands of people. Again, I encourage you to do the same or try to follow the same route but you should start very easily, take it easy, like the guy who contributed the Dock string fix. This is my first pull request six years ago, probably seven years ago now. It was just a fix to the documentation again. So, there are opportunities out there. But if you contribute a pull request, make sure that you do your homework. For example, if you fix a bug but you don't have a test for the bug fix, probably your pull request is not going to be accepted. People want you to contribute a proper test for every single fix you contribute or feature you contribute. Just an example, it depends on the project. Of course, here, this particular pull request has been there for six months sitting because there was no contribute, no test for the feature. So, I couldn't add it. Either I go and write the test myself if I have the time. But of course, the guy contributing the feature is the more entitled one. He knows what he's doing, why he's doing that, and he should contribute the test. So, if you can't contribute the test, probably it's not yet the time to go and open a pull request to your project. There are test suites, by the way, documentations are the two features where probably 90% of pull requests die because you contribute the fix, you contribute the feature, no documentation, no test, it's a no go. And then you complain because your pull request was not accepted. Most of the time, that's what happens. And also sometimes you do everything as you are supposed to do but still things don't go as planned. This is a pull request I did. Let's go and look at it because I suspect it is still sitting there. So, this is a.NET C-sharp contribution, a pull request to align a nice project to the latest version of the framework. I contributed this pull request 70 months ago. As you can see, a number of people want this pull request to be merged because it is very nice. So, and by the way, this guy, for example, the AK Miller is a Microsoft intern developer. So basically this project which is open source is being used within Microsoft probably and Microsoft guys who want it to be merged would really appreciate that we merged but still the maintainer is not merging. And basically this is a, I suspect that it is a dead project one year ago, the last, yes, exactly one year ago. So probably this guy is doing something else with his life or just abandoning the project which is very common, unfortunately, in open source. And we are now considering forking it, releasing a deeper equal. Basically, start a new, this is actually the name was for the new project that came out during this talk. I did the Munich a few months ago. Somebody raised their hand and said, because I was like, I don't know, this is such a cool name. How can I fork and release a new project with a similar name? And it was like deeper equal. Very nice name. But I don't really want to fork the project because forking is bad usually. You don't want to fork a project and start a new project, et cetera. So I'm still hoping it will merge. But the point here is that you do everything fine. You contribute. You open a pull request. You have the test. You have the documentation and still there is a chance that it won't get merged. It's okay. It happens. Just go, I had to go forward and maybe contribute to another project. There might be reasons that go beyond your own skill and your own, and what you did. There are reasons why probably there are some guys right now complaining that they pull request to the E-project have not been merged yet. So it's okay. It happens. What am I doing? Right. And so again, Martin, a pull request. There is what I find to be a cognitive bias. There are so many contributors want to be, but they are intimidated. They feel like a to be open source contributor need to be so skilled, so cool, so capable, and smart. But the truth is it is which that it isn't true. And also there are so many open source maintainers that really can't wait for more contributors to join the project. They are willing to review your code, help you out if something is wrong with your pull request of your contribution. So we have a 50% of contributors here in the room. Let's make it a 70%, 80% will be totally also. And the open source community as a community, as a group, would have so many advantages over that. So many projects would progress faster just because new people are contributing. And by the way, contributing might just mean fix the documentation, again, fix the doc strings, add new tests, or I don't know, change the colors, review the design of the web pages. You don't really have to go and fix the super important bug that nobody has been fixed, has fixed for many years. So there is no luck in becoming an open source developer. You don't become an open source developer because of luck. It takes will and grit and also a strong desire to learn new things and to put yourself under review, validation, and just open yourself to the public. The good news is that anybody can become an open source contributor. This is not my saying. This is from Mattel Collina, who is a good friend of mine. He's also one of the Node.js members of the technical committee, a superstar in the JavaScript space. Maybe you know about him. So here there are a few links. If you want to find some good ideas on where to start, you can find the slides online so you don't have to get... Also, you can't actually read those links. So go online and find my... I will tweet about these links later on. If you go on speaker deck and look for Nicolai Arotti, you'll find the slides so you can get the links. But my advice is start from your own tool chain. For example, here I was writing an article for Code Magazine about using Python in Visual Studio. By the way, Visual Studio also has a fantastic support for Python nowadays. And again, this is because of Microsoft changing their mind and going open source full-monty, basically. And as I was writing the article, I was reviewing the official documentation for Visual Studio. And the fund found a number of errors or typos, stuff like that. And so I just went and contributed to the fixes to the documentation of Visual Studio. So even if I might say eight years old open source developer, I still go and fix Visual Studio documentation for example. So now I can claim to be a contributor to Visual Studio in a way or another. But it is just... It just came out of necessity because I was working on that. I found an error. Why not fix it? You probably have a number of issues with your own tools, with the documentation as you read it. Just go and fix it, contribute to it. This is a very nice, smart way to start contributing to open source. This is it. Here you find my links if you want to get in touch with me. Again, the links are going to be on speaker deck. They already are actually. So thank you. So is anyone have a question? Okay, thank you. Based on your experience, what are the best, let's call it information channels to announce project or get more people involved into the project? Well, in my own experience, going to conferences, for example, and talk about the project. Now, there is again a con... This idea that in order to get your talk approved, you need to be a superstar already. False. Totally false because when I went to Europe Python, I was a C-sharp guy pretending to talk about Python. I was sure nobody would absolutely vote for my talk. And in the end, the talk was accepted. I had a 90-minute talk all for me at Europe Python. So it was totally awesome and shocking. So that's one way. Of course, the simple fact that you put your project on GitHub helps a lot because if you do your homework, well, people will find out. One advice I always give to people asking is don't wait for your project to be 100% ready. If you have a stub, if you have something that a prototype, it is already working, kind of works. Just recently, a Brazilian guy released an open source framework. It's called Vibor or something like that. Anybody knows about it? Right. So it's a fantastic framework for doing basically a successor to... Pretends to be a successor to Flask or something like that. Super fast. And the framework is nowhere ready. It is not ready at all, but it has some documentation, good documentation online, excellent performance. The guy went on GitHub and posted it. Somebody else picked up the project and went on Reddit and posted it. And now the framework is like my story with you. The same happening with this guy. So the first advice I will give you is put your damn project on GitHub, right? Some documentation, even just read me with a snippet, validate your idea. Make sure that people try and see if you're doing something interesting. If it is interesting, somehow people will find out about it. We'll find out about it. Your best... Probably Google the SERP. So you go on GitHub. GitHub is very strong on Google. So your project will be found. And then try to talk to the people around you and go to conferences. It might be a good idea. Maybe write a blog post about it and post it on... I'm not really... I don't think that posting your own project on Hacker News or Reddit is a good idea, really. Just wait for the people to post it on their own initiative. That's probably what works best. Because people are going to go like, hmm, this guy is self-promoting himself. Not really appreciated, usually. Okay. Sorry, we don't have time. So if you have any question, we want to talk to Nikola for a cultural after session. Thank you, Nikola, to present the... So, I'm going to talk again. Thank you. Goodbye.
 So, let me start with a couple of questions. How many of you are actually using open source  in their everyday workflow, be it professional or hobby or whatever? So, like, 99% of the  audience which is expected since we are here. And how many of you are actual contributors  to open source and somehow, I don't know, by submitting full request? Nice, not too  bad actually. So, you don't really need my talk, you can leave the room right now. Great,  that's nice. So, let's say about 50% of you are already contributing to open source.  This is kind of expected since we are here at the Python conference. Anyway, what I'm  going to do today is tell you my story, my personal story with open source. The idea  is to, of course, try to inspire people who are willing or would like to start contributing  to open source. Also, I would kind of give you a perspective from the point of view of  a company who has never been into open source at some point because some weirdo in the company  decides to adopt open source, the company follows along and starts using open source  within its own workflow and products. So, let's start. I am a number of things in my  company that call me the weirdo because in their opinion, I just do too much stuff. I  have too much stuff in my hands which is probably true. I had this point in time. But we will  get back to this slide in a few minutes. What really matters here is that I started my professional  career back in 1991. So, yes, I'm that old. And back then it was a MS-DOS developer, basically,  back then even Windows wasn't yet a thing. And I was basically doing C language in the  C language stuff in MS-DOS and some other environments. And what we were doing as our  company was starting building Windows software back then. But back then Windows wasn't really  a thing. And when we were going and introducing our software to computer shops, vendors, and  users, they were like, why are you doing Windows? Nobody uses Windows nowadays. Everybody is  using MS-DOS. So, you get the idea of the environment and the ecosystem we were working  with back then. So, we basically were two of us, two co-founders of a small company.  Back in 1991, nobody used to call new company startups. But in retrospective, we could call  it a startup. And what we were doing was one of us was writing code in the office. The  other guy was jumping on a car. And back then the software, by the way, was sold in boxes,  actual card box boxes. And the software was in floppy disks. And if you have, I guess,  you know what a floppy disk is. And basically, I had my trunk in the car filled with boxes  and it would go around in Italy and try to sell my software to computer shops. Computer  shops would then sell the software to end users, right? So, the next week I would be coding  while my colleague was going around in Italy selling our software. And we were just copying  the floppy disks from our computers and putting them into the boxes and filling the trunk  of our car. That's how software was produced back then. That's been going on for a while  for a number of years, actually. Windows became a thing, actually. People were using it. Our  software was successful, probably because we were the first back then doing that kind  of thing. So, we were really strategically well positioned to get the market, our market  share in the Italian market, anyway. And yes, over time we did a lot of stuff, basically.  Nowadays our main product is an invoicing and accounting application. It is a desktop  application. I wrote it a number of years ago, actually, and it is a C-sharp application.  So, yes, I'm a C-sharp guy at a Python conference. But the thing is that at some point the direction  we were, I mean, I was just sitting in my comfort zone building my stuff, my software.  I was very comfortable with the technology and the stack I was using. We were using Microsoft  technology, basically. We were dotnet shop in late, I should say, in the 2000s and stuff  like that, 2010. At some point I really wanted to try something new. At that point the technology  or I should say the market was requiring us to write mobile applications and web applications  because people using our app on their desktop, they wanted to also use, you know, printing  voices or doing venturi stuff when they were moving around on their mobile applications  and on the web. So, we were to write some server, some probably API that our desktop  applications could talk to. And that's when I wanted to try something new. I wanted to  get out on my comfort zone. And those were the years when Steve Ballmer in Microsoft  was basically 2001. Steve Ballmer went and said that open source was not trustworthy,  trustworthy, sorry. And that really didn't resonate with me. I was, again, a dotnet guy  working with the Microsoft ecosystem, but that really didn't, I didn't really like that  approach to, the approach Microsoft was taking to the solution of problems, I should say,  the strategy they were looking at. So, I started looking at something as what was going to  happen outside of my comfort zone. And that's when I started looking at Python and the open  source world, et cetera. Long story short, at some point, I was quite proficient with  Python and the guys in my company were really concerned about my, the direction I was taking  back then. They weren't really sure. The idea basically was I was wasting our time. But,  yes, I went to Europe Python in, I think, 2012. It was in Florence. And I went there  with a talk about how to build the rest APIs with Flask. Now, mind you, I was a C sharp  guy talking for the first time in English, by the way, at the Europe Python conference  and doing a workshop about building the rest APIs with Flask. So, if any of you was listening  to Daniela Procida talk before this one, he was about NAVE programming. That talk really  resonates with me because when I went there to Europe Python, I was very NAVE and, I mean,  I was speaking to Python programmers about something which was totally new to me. What  I was doing there, really, was trying to validate, asking for validation about my idea on how  the rest API was supposed to be working and how I would solve the problem. So, it wasn't  really me going there and teaching people. But more like people, I'm doing this, I'm  doing this this way. What do you think about this? And in my world, in the C sharp and  dot net world, something like this, really, I've never seen something like that. And the  reason I was doing that probably because the open source and the Python community was so  much welcoming to me, I felt safe to do something like that in public. Now, what's interesting  to the story is that at the end of the talk, people came to me and said, look, what you're  doing is amazing. Why don't you release this stuff as open source? Now, the framework for  building rest APIs was already in place. I was, I basically, it was ready, but it wasn't  open source. So, I went back to my company, we talked about it at the end of the day.  We released our rest API framework as an open source framework. I don't know if you know  about it, not really important. I just want to show you that we went and released something  as open source. This is something that is based on Flask and you can basically very  easily deploy rest APIs based on top of Flask, basically. It is a mildly successful framework,  I would say. People are using it all over the world. You can say by the number of stars  that there is average adoption. Of course, it's not Django, I mean, or it's not Flask  itself, but it is working very well. And then after Eve, I also released Cerberus, which  is a data validation framework. It is actually Eve dependency. Since everybody does data  validation, even rest frameworks need to do data validation. So, I had to do the stuff.  And since I was doing it, I might as well release it as open source again. So, Cerberus  was born. Now, look at the GitHub stars here. They are like five times less than Eve's,  but a point I want to make is that actually Cerberus is doing three times the downloads  and the user base than Eve itself. So, one lesson for this talk, probably not very important,  is don't really look at the GitHub stars number as an indication of how successful the framework  is. There are some super cool packages on GitHub that have maybe 10 or a few hundred  stars and they are widely adopted by the community. Just nobody goes there and starts  the, to start the repository. And then, because we were successful, I mean, I was having so  much fun, by the way, maintaining these projects in the open source. We went back to our C-Sharp  stack. And by the way, in the meantime, Microsoft was kind of catching up because as you probably  know, nowadays, Microsoft does a ton of stuff as open source. And we will talk about that  later. So, we are also releasing, oh, sorry, the eVecos system has been spawning, the community  has been growing. And as you can see, there are a number of projects, extensions for C-COLA,  C-MU, for example, for OpenAPI, or I don't know, for authentication, stuff like that.  So the community has been growing around the eVe project. And a number of people, the  eVe project itself is like, I don't know, 150 contributors to the project, actual code  contributors. But there are people working on these extensions, for example. There are  about 10 people working on it. So, yes, success, in a way or another. We went back to C-Sharp  and I'm starting to release a C-Sharp and.NET open source. Now, look at the number of stars  there. Of course, the factor, the scale factor is quite different in the.NET world. People  are not really used to consuming and embracing, adopting open source projects as we do in  the Python space. But it is happening, actually. People are using this Italian project. You  probably can't understand anything about it, but it is just for the Italian market. But  in the Italian market, people are actually using it widely. Just they don't even know  there is a GitHub and they have to go and start it if they like it. They just download  the package and use it in their own application. So in doing all this process, I learned a  number of things, a number of very nice and bad things happening to me. I'm going to show  you some of them. And some of them, since most of you are already, 15% of you are already  contributors know everything about this. But let's just browse them because I have a few  considerations and things I want to share with you. Like I did six years ago at the  Flash Talk. So, new feature, of course. My company was shocked when people started adding  features to our framework for free. Now, if we look at a project from the company perspective,  we're getting new powerful features for free. This one is very nice because the document  versioning in its essence is people can edit a document over the rest framework, delete  it, yes, but edit, change the document many times. Now, thanks to this version, you can  go and ask a specific version of the document at a certain point in time. You can even ask  for the diff between the document like you would do with Git, for example. This feature  is super powerful. I didn't write one line of code about it. And as you can see by the  number of files touched by this feature, it was quite a huge contributor, contribution.  And Josh, by the way, he doesn't work there anymore. But back then, this was a contribution  done by a very nice and famous company. I can't really mention it because for the secure  NDA regions, but let's just say that they send spaceships to the International Space  Station and it is not an ESA. So, you probably can get an idea of which company it is. And  they're actually the spaceships they're using to send stuff to the International Space Station.  And some part of the engineering around the spaceship is actually using an EVE instance  to, it is being used somehow. I don't know how within their laboratories to store information  about the engineering stuff, the design of the devices, et cetera. And of course, bug  fixes. This is another very important feature for the company. Company is seeing value in  our products, in our open source project now because we get bug fixed for free even before  we know about them and we learn about them, which is how many, how much money we spent  in 25 years on the field fixing bugs that people were actually complaining about and  we couldn't even reproduce them locally in our closed source company.  Now things have changed. People are like, look, there is a bug and this is the fix for  the bug. And so we don't, I mean, how nice is that if you are a company producing software?  I mean, not all the bugs are solved like this. I'm still fixing bugs every single day, but  many of them are, I don't even have to fix them. And this is very important in my opinion,  quality and longevity of a project. So more I see more that's how I put it basically.  Look at this contribution. Now I'd like to contribute to the project so I started the  whole through basically the documentation. Sorry, not the documentation, but he went  and started looking at the doc string so every single function and method we had in the framework  and fixed a few types as he says. Actually, he touched the 21 files against and if we go  and let's see if I can show you, yes, readable. Yes. So these guys probably doesn't know much  about Python. Otherwise he would be fixing bug or finding, I don't know, issues in my  code, et cetera, but he still wanted to contribute. So he went and started looking at the doc  strings and there were so many errors. Mostly because I'm not an active speaker as you can  tell by this little me. And so he went and fixed all this stuff. As you can see just  typos, you might say stupid things, but this code has been on GitHub for four years. So  how many people have been reading these doc strings in the lifespan of this project and  looking at the mistakes and the typos and going like first, this Nikola guy that really  doesn't know anything about English and second, they should fix it. Finally, one guy, one  naive guy probably coming from, I don't know, just for the enthusiasm he had in the project,  went and fixed this. And now finally, after four or five years, the doc strings are hopefully  fixed or way more fixed than before. So I really value this contribution because this  is the kind of approach that somebody who wants to start contributing to open source  can do very easily and contribute a lot of value to the project itself. Because when  the people like you, new adopters of the project, go and look at the code, don't have to mess  with my mistakes in the doc strings. So many mistakes, by the way. So this is a very nice  example of how even non-skilled or probably just shy people can still start and contribute  to open source project and contribute value without even touching one line of code. Again,  the community nowadays, when I want to change something in the framework, be it the eFrame  or Cerberus or my C-sharp code, I don't go to my colleagues or I go to my colleagues,  of course. But I also go to the community. I just open a ticket and I go like, I would  like to implement a fluent API, for example, for this project. What do you guys think about  it? So suddenly, it's not just five or six of us in our office. It's probably tens or  hundreds or sometimes thousands of people talking about design feature. So we have a  lot more feedback about that, how powerful and important that is. Of course, it also  means that you have to spend a lot of time talking to people, which has a cost, yes,  can be taxing, but it is still worth it, in my opinion. Because at the end of the day,  the design is probably more sound. There are new ideas coming from people who are not on  the same rails as we are in the office and can contribute innovative, new, fresh ideas  and approaches. For example, by the way, here, I was about working on this new API and this  Pedro guy came and told me, look, go and look at the MongoDB implementation. They already  have a fluent API. So probably a good idea, but might be look at what has been already  done in this space. And honestly, I didn't think about it. So it was a good idea. I went  and it was inspired by the MongoDB implementation of this particular API. Another important  aspect that people usually don't really consider are the language and cultural barriers. So  not just how good are you speaking English, but also the cultural differences that are  around the world. So somebody from the Eastern Asia or maybe from Russia might open a ticket  about a bag and be, especially from the Eastern Europe, he would be probably very direct,  like look, there is a bug here. Fix it. Somebody asks from Western Europe for the same bug,  would go like, hey, you know, very nice framework. Thank you. I really love it. We are using  it in production. Thank you. Thank you. Thank you. There is a bug. Can you probably go there  and look at it, fix it? So you see very different approaches to the same exact bug. The first  one might come across to me as somebody not really nice, somebody I don't really feel  like helping. Maybe I look at the bug from the Western Europe guy because he's so nice.  But actually the two people have the same problem and the same in the Eastern Europe  guy is as nice as the Western Europe guy. It is just a cultural difference. They approach,  they take the language in a different, they think in different ways probably, but they  are asking for the same solution, right? I don't know if I'm getting my point across.  But I want to say that people all over the world are speaking, approaching to problems,  a solution in different ways. You have to learn and deal and also understand that they  communicate in different ways. And also there is a language barrier, real language barrier,  because we don't speak English. I don't speak English well. This guy doesn't speak English  well. And Amadeo is obviously a Latin guy. He's actually Italian. He's not an English  speaker either. So sometimes it really gets weird, but you have to process all of these  and make sure you understand everything is the context very well. And speaking of downsides,  maintenance, maintenance of an open source project can really become a burden. It actually  is for my own open source projects. Right now only we have, well, actually way less than  these open tickets, but just because I have bought closing tickets which are older than  one here, because I couldn't handle all of that alone. But at some point in time when  your project is, becomes successful, you start having just too many tickets you can deal  with. So you have to really, you every single minute you get an email, probably as I'm speaking  right now, I'm getting emails from people that are wants a new feature or have some  issue with the framework, ask for help. And so it can really become taxing. You feel responsible  for these people. There is some guy in Dubai who has a problem with my framework and I really  would like to help him, but right now I have to do this and that because I'm making money  there and this is free activity. I need to do that on Saturday morning, maybe on Sunday  evening. I've been doing all of this for many years and I can assure you when you have a  family with three kids and a dog, et cetera, it really becomes taxing. So that's probably  a negative and you, if you are contributing to an open source, many of you are already  contributing so probably know everything about it. At some point probably you got stressed  because the maintainer wasn't really looking at your ticket. So you go and look at the  code and fix it yourself and then contributed with a pull request just because you were  stressed that the maintainer wasn't looking at your issue. Anybody? No, I guess, okay.  That's good. And if you are into open source for making money or if you think that open  source can give you money, this is what I'm doing from open source on Patreon right now,  actually I have four contributors, sorry, four Patreon sites, they call them right now.  So I'm making four bucks a month for my open source activity. So if you want to get it  open source for the money, well, maybe you consider that and find some alternative ways  to make money. I mean, there are very successful projects who are doing good money in the open  source but you really need to get there if you want to make the money, like not 5,000  stars, maybe 100,000 stars, then maybe you are starting to see some money coming from  this because people will look at the project, read the documentation, adopt it, make money  over it and maybe even think, yes, we need to contribute to this project because it is  so cool but then somehow they forget to do that, right? So you need to get creative.  For example, I don't know if any of you knows about the Python podcast, it is a very nice  podcast in the Python space run by Michael Kennedy and he asked me if I wanted to actually  produce a course about the framework and he would sell it on his platform, I did that,  it was very hard for me to do that but in the end there I'm getting some more money,  more than the 4 bucks amount I'm making from the Patreon campaign. So if you want to make  money in open source, there are ways but you are really to work hard to get there and we  will see that also I'm making money collateral money from my open source activity but not  just directly from the open source contributions which unfortunately are very low.  So let's look at the consequences of my story. When I started looking at Python and the open  source I was just a very shy introvert, C sharp and previously C developer working all  day in my office and then at 5 p.m. I would just leave and go home and stay with my wife.  Then somebody I really I went to Europe Python, I released the EVE as an open source, somebody  I don't know if it was my poor luck or unlucky, went and posted the framework on EVE on Hacker  News back in the day and that's when the will started to just move too fast for me. In one  day I got like 1,000 stars on GitHub, people started emailing me contributing to requests  that day I became an open source maintainer basically. Until then people really were not  caring about my open source project. That I started or I should say I went back to speaking  and I started talking about my open source project, people were actually asking me to  go and talk at the conferences about my open source project or my activity in general.  I had been talking about a number of topics but mainly about my own open source projects  but speaking for me was something totally new. Again, it might not appear right now  but I am really a shy person so for me going out and speaking about my things, my story,  it was really hard for me to do in the beginning. So yes, even if you are shy and introverted  you might be a very good, surely better than me speaker in the future if you want to try  that. And then because I was doing the rest API stuff on the web and my framework was  being adopted by many companies, I started getting consulting contract work just because  people wanted me to go and for example here in Edinburgh three years ago I went to the  university because they were using it in their own projects and they got in touch with me  and said, look if you come here for one week you probably can do the work we will do in  six months so just come here, we pay you and you fix the project for us and we move forward.  And I did that, I had a lot of fun by the way, it was great, think about that, going  and do contract work for your own open source framework. How many days is that? Very nice.  I love that. It's been happening since then a few times. So money for my open source project  finally, yeah. And also teaching, I've been teaching Python in general not just my open  source projects. I started creating communities, for example this local community in my own  city. So every month we meet, I try to encourage people to start speaking at these small events,  maybe we have 40 people and then people start getting confidence with this and maybe start  going and speaking at real conferences and not just the meetups, et cetera. And this  is fun because at the end of the day, three years ago, Microsoft came back to me and for  the last 10 years I've been working 50% of C-sharp and 50% of Python. I still do this,  to this day I still work a lot on C-sharp space and they wanted to award me for my work in  the developer technologies. But the real story was that I was trying to flee from that ecosystem  and going again, you know, all about it already, I went and started working on Python. I didn't  really want to work in that ecosystem anymore. And again, Microsoft very slowly but they  kind of catch it up with me and now they are totally all some open source company. I probably  many of you are using a voice code, Visual Studio code as a text editor. They are the  main contributor to GitHub. They have a number of main open source projects. I got these  awards from them and every once a year we get to go to the Microsoft headquarters in  Seattle and I get to talk with the actual developers who are making the.NET framework, .NET core, et cetera. And it is funny because when I started working with Flask open source  and I could see the code behind the framework I was using, for me it was a total revelation  of how powerful open source would be. And now speaking to these guys, they are so excited,  as excited as it was 10 years ago. They are so happy that they now can embrace open source  and work on them on it and seeing them so excited about it. I know that Microsoft isn't  going back. If you are afraid that Microsoft will be going back someday or try to trap  you into their ecosystem as they used to do years ago, don't be afraid. Microsoft is a  totally new company and because I see the guys working on the actual project, I know  that you can't stop them anymore. You can't put them in a cage anymore as they used to  be working in the past. So, kind of funny. Also, I got an award for MongoDB, et cetera,  not really important, but and this is important actually. So, because I'm speaking, because  I have open source software and every time I put a line of code on GitHub, I know that  there are probably hundreds or thousands of people reviewing my code. I really have to  do my job at the best I can perform, right? Which usually means that people will still  find the issues with my code and review it and fix the bugs again or complain that I  could adopt a different solution, but it is okay. This is a slide from a Git talk I did  last year. Not really, just don't look at the code, but in order to understand Git,  I mean I use Git every day. I maintain projects, pull requests, rebase, et cetera. I went and  started speaking about how I use Git, but in order to talk about Git, you really need  to control the tool. So, I have to learn it even more than I know it just because I need  to go and teach it. So, basically for me, this means learning every single day. Every  single day, I still spend one hour every morning, really early in the morning, just to learn  because I need to know the tools. Every, you all do that, but because if you go in front  of the, of a public, be it by speaking or because you have an open source project, you  have to maintain it, you really have to do learning very well. Networking, as the French  say. Nowadays, I know a lot of people in the Python space and yeah, it's extremely powerful.  I can count the number of times that somebody from across the world has been helping me  with something that has nothing to do with the actual open source framework. Maybe I  need to fly to Dubai for a contract work. And somebody from Dubai will, I don't know,  help me or even take me to their house and stuff like that. So, networking is super  powerful and because I'm so grateful because of open source, I got to meet so many cool  people and guys and guys all around the world. It is extremely powerful and useful also.  So now, I do all of this stuff and open source to me really rock my wall. I totally changed  the way I work, my workflows, the people I work with is not, again, not four or five  people anymore but thousands of people. Again, I encourage you to do the same or try to follow  the same route but you should start very easily, take it easy, like the guy who contributed  the Dock string fix. This is my first pull request six years ago, probably seven years  ago now. It was just a fix to the documentation again. So, there are opportunities out there.  But if you contribute a pull request, make sure that you do your homework. For example,  if you fix a bug but you don't have a test for the bug fix, probably your pull request  is not going to be accepted. People want you to contribute a proper test for every single  fix you contribute or feature you contribute. Just an example, it depends on the project.  Of course, here, this particular pull request has been there for six months sitting because  there was no contribute, no test for the feature. So, I couldn't add it. Either I go and write  the test myself if I have the time. But of course, the guy contributing the feature is  the more entitled one. He knows what he's doing, why he's doing that, and he should  contribute the test. So, if you can't contribute the test, probably it's not yet the time to  go and open a pull request to your project. There are test suites, by the way, documentations  are the two features where probably 90% of pull requests die because you contribute the  fix, you contribute the feature, no documentation, no test, it's a no go. And then you complain  because your pull request was not accepted. Most of the time, that's what happens. And  also sometimes you do everything as you are supposed to do but still things don't go as  planned. This is a pull request I did. Let's go and look at it because I suspect it is still  sitting there. So, this is a.NET C-sharp contribution, a pull request to align a nice project to  the latest version of the framework. I contributed this pull request 70 months ago. As you can  see, a number of people want this pull request to be merged because it is very nice. So,  and by the way, this guy, for example, the AK Miller is a Microsoft intern developer.  So basically this project which is open source is being used within Microsoft probably and  Microsoft guys who want it to be merged would really appreciate that we merged but still  the maintainer is not merging. And basically this is a, I suspect that it is a dead project  one year ago, the last, yes, exactly one year ago. So probably this guy is doing something  else with his life or just abandoning the project which is very common, unfortunately, in open  source. And we are now considering forking it, releasing a deeper equal. Basically, start  a new, this is actually the name was for the new project that came out during this talk.  I did the Munich a few months ago. Somebody raised their hand and said, because I was  like, I don't know, this is such a cool name. How can I fork and release a new project with  a similar name? And it was like deeper equal. Very nice name. But I don't really want to  fork the project because forking is bad usually. You don't want to fork a project and start  a new project, et cetera. So I'm still hoping it will merge. But the point here is that  you do everything fine. You contribute. You open a pull request. You have the test. You  have the documentation and still there is a chance that it won't get merged. It's okay.  It happens. Just go, I had to go forward and maybe contribute to another project. There  might be reasons that go beyond your own skill and your own, and what you did. There are  reasons why probably there are some guys right now complaining that they pull request to  the E-project have not been merged yet. So it's okay. It happens. What am I doing? Right.  And so again, Martin, a pull request. There is what I find to be a cognitive bias. There  are so many contributors want to be, but they are intimidated. They feel like a to be open  source contributor need to be so skilled, so cool, so capable, and smart. But the truth  is it is which that it isn't true. And also there are so many open source maintainers  that really can't wait for more contributors to join the project. They are willing to review  your code, help you out if something is wrong with your pull request of your contribution.  So we have a 50% of contributors here in the room. Let's make it a 70%, 80% will be totally  also. And the open source community as a community, as a group, would have so many advantages  over that. So many projects would progress faster just because new people are contributing.  And by the way, contributing might just mean fix the documentation, again, fix the doc  strings, add new tests, or I don't know, change the colors, review the design of the web pages.  You don't really have to go and fix the super important bug that nobody has been fixed,  has fixed for many years. So there is no luck in becoming an open source developer. You  don't become an open source developer because of luck. It takes will and grit and also a  strong desire to learn new things and to put yourself under review, validation, and just  open yourself to the public. The good news is that anybody can become an open source  contributor. This is not my saying. This is from Mattel Collina, who is a good friend  of mine. He's also one of the Node.js members of the technical committee, a superstar in  the JavaScript space. Maybe you know about him. So here there are a few links. If you  want to find some good ideas on where to start, you can find the slides online so you don't  have to get... Also, you can't actually read those links. So go online and find my... I  will tweet about these links later on. If you go on speaker deck and look for Nicolai  Arotti, you'll find the slides so you can get the links. But my advice is start from  your own tool chain. For example, here I was writing an article for Code Magazine about  using Python in Visual Studio. By the way, Visual Studio also has a fantastic support  for Python nowadays. And again, this is because of Microsoft changing their mind and going  open source full-monty, basically. And as I was writing the article, I was reviewing  the official documentation for Visual Studio. And the fund found a number of errors or typos,  stuff like that. And so I just went and contributed to the fixes to the documentation of Visual  Studio. So even if I might say eight years old open source developer, I still go and  fix Visual Studio documentation for example. So now I can claim to be a contributor to  Visual Studio in a way or another. But it is just... It just came out of necessity because  I was working on that. I found an error. Why not fix it? You probably have a number of  issues with your own tools, with the documentation as you read it. Just go and fix it, contribute  to it. This is a very nice, smart way to start contributing to open source. This is it. Here  you find my links if you want to get in touch with me. Again, the links are going to be  on speaker deck. They already are actually. So thank you.  So is anyone have a question? Okay, thank you. Based on your experience, what are the  best, let's call it information channels to announce project or get more people involved  into the project? Well, in my own experience, going to conferences,  for example, and talk about the project. Now, there is again a con... This idea that in  order to get your talk approved, you need to be a superstar already. False. Totally  false because when I went to Europe Python, I was a C-sharp guy pretending to talk about  Python. I was sure nobody would absolutely vote for my talk. And in the end, the talk  was accepted. I had a 90-minute talk all for me at Europe Python. So it was totally awesome  and shocking. So that's one way. Of course, the simple fact that you put your project  on GitHub helps a lot because if you do your homework, well, people will find out. One  advice I always give to people asking is don't wait for your project to be 100% ready. If  you have a stub, if you have something that a prototype, it is already working, kind of  works. Just recently, a Brazilian guy released an open source framework. It's called Vibor  or something like that. Anybody knows about it? Right. So it's a fantastic framework for  doing basically a successor to... Pretends to be a successor to Flask or something like  that. Super fast. And the framework is nowhere ready. It is not ready at all, but it has  some documentation, good documentation online, excellent performance. The guy went on GitHub  and posted it. Somebody else picked up the project and went on Reddit and posted it. And  now the framework is like my story with you. The same happening with this guy. So the first  advice I will give you is put your damn project on GitHub, right? Some documentation, even  just read me with a snippet, validate your idea. Make sure that people try and see if  you're doing something interesting. If it is interesting, somehow people will find out  about it. We'll find out about it. Your best... Probably Google the SERP. So you go on GitHub.  GitHub is very strong on Google. So your project will be found. And then try to talk to the  people around you and go to conferences. It might be a good idea. Maybe write a blog post  about it and post it on... I'm not really... I don't think that posting your own project  on Hacker News or Reddit is a good idea, really. Just wait for the people to post it on their  own initiative. That's probably what works best. Because people are going to go like,  hmm, this guy is self-promoting himself. Not really appreciated, usually.  Okay. Sorry, we don't have time. So if you have any question, we want to talk to Nikola  for a cultural after session. Thank you, Nikola, to present the... So, I'm going to talk  again. Thank you. Goodbye.
Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_0_143.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_144_2063.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_2064_3035.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_3036_13175.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_13176_14291.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_14292_14951.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_14952_15887.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_15888_16427.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_16428_17435.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_17436_18563.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_18564_18803.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_18804_21959.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_21960_23207.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_23208_24095.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_24096_24191.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_24192_24323.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_24324_24575.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_24576_24827.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_24828_24875.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_24876_25931.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_25932_25991.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_25992_26507.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_26508_26675.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_26676_26855.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_26856_28499.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_28500_29183.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_29184_32339.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_32340_35039.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_35040_36683.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_36684_38003.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_38004_38051.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_38052_38531.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_38532_39119.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_39120_39563.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_39564_40787.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_40788_42395.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_42396_43043.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_43044_46139.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_46140_46247.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_46248_48431.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_48432_49619.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_49620_49739.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_49740_50147.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_50148_50795.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_50796_52883.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_52884_53135.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_53136_53231.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_53232_53579.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_53580_53627.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_53628_53771.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_53772_53819.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_53820_53999.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_54000_54371.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_54372_55763.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_55764_56531.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_56532_56603.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_56604_56663.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_56664_56711.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_56712_58955.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_58956_59231.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_59232_59579.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_59580_60095.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_60096_60671.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_60672_62519.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_62520_68171.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_68172_68219.png Nicola_Iarocci_-_My_Story_with_Python_and_Open_Source_7c-2I3vYkhw_68220_68327.png