 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 requests? No, it's 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 your Python conference. Anyway, what I'm going to do today is tell you 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, I was a MS-DOS developer, basically. Because back then, even Windows wasn't yet a thing. And I was basically doing C-language staff 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, end users, they were like, why are you doing Windows? And 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 companies 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 cardboard boxes. And the software was in floppy disks. Any of you that I guess you know what a floppy disk is? And basically, I had my trunk in the car filled with boxes. And I would go around in Italy and try to sell my software to computer shops. Computer shops would then sell the software to end users. 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 our market share in the Italian market anyway. And yes, over time, we did a lot of stuff, basically. And 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 printing voices or doing inventory 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 of my comfort zone. And those were the years when Steve Bollmer in Microsoft was basically 2001. Steve Bollmer went and said that open source was not trustworthy. Trustworthy, sorry. That really didn't resonate with me. I was, again, a dotnet guy working with the Microsoft ecosystem. But I didn't really like that approach. 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, guys, 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 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 Proscida talk before this one, he was about naive programming. That talk really resonates with me. Because when I went there to a Europe Python, I was very naive. 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 a REST API was supposed to be working and how I would solve that 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. 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 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 this stuff. And since I was doing it, I might as well release it as an 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 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 ecosystem has been spawning, the community has been growing. And as you can see, there are a number of projects, extensions for SQLite, 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 this extension, 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 C-Sharp and .NET open source. Now look at the number of stars there. Of course, the scale factor is quite different in the .NET world. People are not really used to consuming and embracing adopting the open source project 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. It's just download the package and use it in their own application. So during 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, 50% of you are already contributors, I know everything about this, but let's just browse them because I have a few consideration and things I want to share with you, like I did six years ago at Flask 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 for the secure NDA regions, but let's just say that they send spaceships to the International Space Station, and it is not NASA, 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. 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 the 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. The 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 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 typos, as he says, actually he touched 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 listening to 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 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 a design feature, so we have a lot more feedback about that, how powerful and important that it 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, and 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 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 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, it would be probably very direct, like look, there is a bug here, fix it. Somebody asked 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 is so nice, but actually the two people have the same problem and the same 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. What I want to say is 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 the context very well. And speaking of downsides, 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 becomes successful, you start having just too many tickets that you can deal with, so you have to really, every single minute you get an email, probably as I'm speaking right now, I'm getting emails from people that 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 I now 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 we have a family with three kids and a dog, et cetera, it really becomes taxing. So that's probably a negative and 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 poor 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 but 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 reconsider 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 Torque Python podcast, it's 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 and but in the end there I'm getting some more money, more than the four 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 contribution 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 I went to EuroPython, I released Eva as an open source. Somebody, I don't know if it was by poor luck or unlucky, went and posted the framework on Hacker News back in the day and that's when the will started to, you know, to just move too fast for me. In one day I got like 1,000 stars on GitHub, people started emailing me, contributing poor 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've 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 a 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, to do contract work for your own open source framework. How meta is that? Very nice. I love that. And 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 project. 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% on 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 story, 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 a totally old song open source company. I, probably many of you are using a voice code, Visual Studio code as a daily text editor. They are the main contributor to GitHub. They have a number of main open source projects. I got this award 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 it and seeing them so excited about it. I know that Microsoft isn't going back. If you're 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 work 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 started speaking about how I use Git, but in order to talk about it, 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 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 rockin' 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 doc string fix. This is my first pull request six years ago. No, 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 add 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 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, a 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, 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 up full request, you have the test, you have documentation, and still there is a chance that it won't get merged. It's okay, it happens. Just 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 requests to the E-project that have not been merged yet. So it's okay, it happens. What am I doing? Right. And so again, Martin pulled request. There is what I find to be a cognitive bias. There are so many contributors wanna be, but they are intimidated. They feel like to be an open source contributor need to be so skilled, so cool, so capable and smart. But the truth is that it isn't true. And also there are so many open source maintainers that really can't wait for more contributors to join their project. They are willing to review your code, help you out if something is wrong with your pull request or your contribution. So we have a 50% of contributors here in the room. Let's make it a 70%, 80% will be totally awesome. 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 webpages. You don't really have to go and fix the super important bug that nobody has been 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 Matteo 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, also you can't actually read those links. So go online and find my, I will tweet about these links later on. And if you go on speaker deck and look for Nicolai Aroce, 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 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'm, 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 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 and 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, this idea that in order to get your talk approved, you need to be a superstar already, force. Totally force 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 minutes 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 isn't 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 him, the same happening with this guy. So the first advice I will give you is put your damn project on GitHub. Some documentation, even just a 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. Your best ally probably is Google, the SERP. So 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, this guy is self-promoting himself. Not really appreciated, usually. OK, sorry, we don't have time. So if you have any question, want to talk to Nikola please call to after session. Thank you, Nikola, to present all of the talk again. Thank you. Bye.