Designing and Scaling a Python Library in the Open: Architecture, Automation and Community

Speaker 1 [01:00]

Hi, I'd like to invite everyone to occupy the seats in the front, please. Thank you. There's plenty of seats over there. All of these empty ones can be filled, I think. And the ones who are, like, if you see a free seat on the left of you, also can move so that the people coming in can have more seats. Thanks again. Thank you. Okay. Let's start. This is the final talk of this session before lunch. So we're very happy to have Camilla Maia, who will talk about designing and scaling a Python library in the open architecture, automation, and community. Let's welcome her with a warm applause.

Speaker 2 [02:41]

Hello, people. How are you? Good? Good? Okay, thank you very much. So, if you want to see this presentation, there is like in the PyData website, but also here. So, just grab the QR code, and let's get started. here. So, first, I'm Camila Maia, I come from Brazil, more specifically from the south in this island that is called Florianopolis, and which the next... This is quite a beautiful place, I have to say, kind of biased here, but where the next Python Brazil will happen, so Python Brazil will happen in Floripa, everyone is more than invited, you just let me know, And then we can go for a pie bar there. It will be amazing. It's the biggest pie cone in Latin America. It's massive. And it's beautiful. So talking a bit about me, I work more like I already work a lot as back-end engineer in these latest years. I have been working with developer experience. So I'm working a lot with dev tools about how to make the whole experience of the development better. Also, I'm a co-founder of this organization that is called CumbucaDev. And just as a curiosity, Cumbuca means bow. So here it's not bow, it's Cumbuca. And so it's a Brazilian organization that we mainly care about four things. First, it's like education. So it's focused on education and underrepresented groups, and we teach technology via open source. So via open source, we help educate and teach underrepresented groups, not just to enter in the field, but also to ascend in it. I identify myself as a woman. I'm lesbian, and I have a disability, so I have low vision, so if you make any signs to me and try to say, hey, it's missing ten minutes, I will ignore it because they will not see it. So please scream. And thank you very much for all the support of the diversity committee for making this all happen. Okay. So let's get started with the subject. Let's start with the moment that you have a new idea. I have a beautiful idea, and I just start programming, and I created a new Python library. And there you are, like, super happy. I made it. That's it. Usually, we think that about, like, open source is about coding. Sometimes. I think most of the time, it's not about it. I mean, in the beginning, yes. Afterwards, there's a lot of other work that you have to do. So, you're there, happy. But then 12 seconds later, You start receiving a lot of notifications about issues, people complaining or people asking for new features, and you start getting a bit overwhelmed. Also with the PR, so you start receiving a lot of PRs, you are not able to manage this huge demand, and then you start, like, going a bit crazy. Also this, because then you have libraries that you are depending on, you have dependencies in general, so you start checking that they are upgrades, they have like security vulnerabilities, you need to be aware about them, you need to be always updating them, so you get like in a stage that you are like, okay, it was fun, but now it's getting a bit complicated here. So then you start thinking, okay, how can I fix this or how can I improve this whole process? So now we are going to talk about the project that I created and that I had, and I felt like this problem, that is the scan API, I created it in 2019, this is the website where you can check all the documentation, scanapi.dev, and basically what it does, it gets some specification that you write about your API in YAML, so you say this is the main URL, this is like this endpoint, and then you just describe it and you write some tests in Python, and then ScanAPI, it's a CLI, so you go in the terminal and say, hey, ScanAPI, run this specification for me, and then ScanAPI will hit the endpoints and will run the tests. So this is a library framework for testing that you can use for any API. So it doesn't matter if it's written in Python or not. The only thing that you can use Python to customize your test. So you hit the endpoints, and then you create a report that is more or less like this. So you list all the endpoints. You say what are the expected behaviors for each one. And then ScanAPI will hit them and create this report with the tests, errors, and showing to you how it is your API in that exact moment. So you can check the health of your API in that moment. So we already had some small companies here supporting the project. Last year, we were one of the 71 projects selected for the first sessions of the GitHub Secure Open Source Fund. So besides that, they gave money. Also, they gave us three weeks of intensive lessons of security with people from Microsoft and GitHub in general. It was nice. Also, they invited me to go to the GitHub universe last year. So I went there. And then we managed to record a podcast talking about the whole experience in this program. So if you want to check, there is us talking about security. And, okay, so just saying this, that with all these things, I was like that. I was, okay, I was feeling the same pain that I was describing in the beginning, like a lot of PRs, a lot of issues. I'm definitely the bottleneck of the project, right? So, okay, how can we improve this? So here we are talking about scaling, so how we can scale an open-source project. but maybe you're thinking scaling just about performance. This is not only, so let's try to put here what we are thinking when we talk about scaling this presentation. So scaling it, yes, a lot of people using it. So a lot of users, I mean, since it's a Python library, it means that a lot of downloads, a lot of people consuming it, so a lot of people asking for features and so on and so forth. Also, that it shouldn't be super slow, right? You need to perform it well. So this was probably what more or less you were thinking about scaling. But also, we are thinking here about scaling the whole life cycle of this open source library. So imagine receiving a lot of contributions from different people, from different countries, different cultures. like receiving a bunch of commits, like, forks, and then, like, how can you manage to not go crazy with this? It's basically... I should change the title of this presentation, like, how to not go crazy with this? And also, like, how can you keep the mountains, like, how you manage to not be overwhelmed with it? And... Okay. So, I will start talking some stuff that we did in Scan API. And let's see if this helps you if you already have an open source library or if you're thinking about having it. I hope this doesn't motivate you and only motivates. So first, talking about code, exactly what you were expecting about performance, yes, of course, it does help, it helps a lot in this case for scaling. So first, one thing that we did is like separation of concerns. So we separated basically three phases. When we are first receiving the input, so we are receiving the specification files, so basically loading this specification, and then parsing or checking and validating it and doing all the tasks related with it, then we care about the execution which means going there and running the, like, calling the points itself, so, calling and getting, grabbing these results, and the third part is about the output, so, like, writing the summary, writing this report, this HTML file, right? So, with this, we can have, like, three separate pieces, and which also helps, of course, for maintaining, but also for having more people contributing because you need to think that there are a lot of people contributing. If they need to change always the same file, it will generate a lot of conflict. It will be a mess to merge. So if we can manage to make things separate by these concerns, these concepts, it helps a lot also for creating new code. Another thing here is about, of course, performance in the sense that we need to ensure that ScanAPI will handle a lot of requests and having a huge API with many endpoints. So for this, we're using some laser evaluation and using Python features for it. For example, here, when we run the scan API, so the execution part that we are going to call the API itself, we don't call, we don't make the call directly. We use a generator. So then this generator will be responsible to get this result when it's time. So otherwise, we would have everything in memory. Imagine, I don't know, that you have like 1,000 anti-points to test. And then if you do this without this generator, you would have all this data, all the results in the memory, and that could go getting worse and worse. So this is one strategy that we adopted to be able to keep going, doesn't matter how many requests you have. So for example, we are going to only start evaluating that generator, really calling the function and doing the call of the request when we are creating the report, and it's incremental. So, every time there is, like, okay, I'm going to write the line here to show the results for this report, so then it goes, called the API, and then comes back, and then it goes like this, and then it's storing the results for the summary, so the summary goes afterwards because it needs to wait for all this to happen. Okay. But now we're talking about code, but let's talk a bit about when people go to your project and then they have, like, the first look, like, what is this? So the first look usually is, like, about documentation. So first thing that usually people do is, like, reading the readme. Sounds a bit expected. So here, if you have like a good readme that can also show, like guide the users, the different people, the different audience from your project, for example, for the users, people that will use, in fact, your tool, or people that will contribute to it. So here, it's like where you're going to guide these people to where they should go. Also license, that is really important in open source. So you need to tell people what are the constraints for using, modifying, and distributing your software. So this is quite important. And this is like... It's important... Oh, my God. Wait. Here? Here. Okay. So it's also important because the more it grows, the more you need to be aware that this is established and people are aware of it. Otherwise, your code will be, I don't know, could be shared or modified, and people start receiving money with it, or people can use it for other things so that you are not agreeing. So this is quite important. And for the audience that they are the users, also it's important to have a good documentation about Quickstart, what you can do, what are the commands that you can use, in general. In general, how people use your library. Also, a tutorial is quite nice to have. So step by step, then people, because there are people that they learn more reading the theory and then going afterwards to doing. But there are people that prefer to start going crazy. So this approach is nice, because then we cover these two options. And also, it covers the option that the person will read a sheet and go to ChatGPT and ask, because then ChatGPT will have done everything for you. And then you will be able to understand anyway. So we are feeding the AI here, too. Besides that, we also, if it's a library that there are people using, you need to tell them what is changing during the time. Because otherwise, people will start trying to guess. And then these will bring you more issues. They will try to understand. So everything that you make it more clear, it will give you less work in the future. So change logs saying which version had each change. And for the contributors, then, the main document that we use for open source is the contributing.md. There, you go and check exactly how to run the project, how to create a change, how to propose a change, what is the process that you need to find an issue. And this is important to remember that it's more or less like you are entering a house of someone. And then you need to check which are the rules that they are using. So you go and you see, for example, there is a commit mess. You're going to commit something. So you check, hmm, let's see how people are committing here. What is the pattern? If these things are not explicit, they are not explicit in the contributing file, so you need to have this idea that you are joining someone else's project. So here, the same for the other side. So if you are the owner of the project, you need to make it as clear as possible. For then, people don't need to guess. And they can follow what you are expecting. And again, because if you don't make it clear, probably people will make it in a different way. And then you need to tell them what is the right way. And then these will make an overload. And then you're going to do it again and again. So also, conduct of conduct, this is important to tell how the people should behave in the open source project, because in the end of the day, it is a community. So there will be people contributing, talking, suggesting ideas, implementing ideas. So the same that we have here for Parcon, we also need this for open source projects. Issues, OK. So then the person went there, took a look at the readme file, the contributing, and then the person went, let's say, so here you are going to be able to see all the issues on GitHub at least. So if you have issues, this helps a lot for people to keep contributing, even keep contributing with code or asking for features, reporting bugs. And if you have issues templates, it helps a lot, because then you will ensure that people will follow some structure that you are already expecting. Because a lot of times, if you don't have it, people will try to describe the problem, but maybe it's not that clear. So this also helps to avoid this back and forth. So issues templates help you a lot. So also labels help you because then people will go more directly to the point that they want. So let's say, for example, that it's a first contributor. So if you use the good first issue label, they will already try to get these issues that are a bit more beginner-friendly. And then you will have probably less conflicts or less back and forth to guide this person to deliver the future. Also, automations help a lot here. One thing that we notice is that specifically when we do, like, sprints, it's kind of messy to manage the assign, because imagine that you, I don't know, you prepared a sprint with 10, 15 issues, and then 20, 30, and then people will start, like, working on them, and then Then everyone would say, like, hey, can I work on this issue? Hey, can I work on this issue? And then you are there, like, needing to assign everyone and say, yes, you can go. You can go. So then we create a bot that is, like, you put dips, and then you automatically assign this issue to you. It helps a bunch. Okay. And then the person got the tickets, the issue, is happy, and then it will start making the change. So we configure here GitHub Codespace, so then you don't need to, I mean there are three options for the person to run scan API in the dev environment, so one is with Codespace, and also you can use like Codespace in your machine, or manual setup, but this is nice because you need zero configuration, you just click in a button, and then you're already ready to contribute, and also we configure it in a way that you have access to one repository that is called examples, that we have examples of specifications for real APIs like GitHub API, Trello API, so then you can already start testing in development with real APIs. What else? Also one thing that helped us a lot is to use make files, like make commands, so then Then we can use these commands both in local environment and also in the pipeline. And then we ensure that all the dependencies match because what was happening a lot was like we were formatting things locally, and then it was passing, and then when we were going to the pipeline, it was breaking, and then what's going on? And then I don't know, like the linter was in different versions, for example. So putting this as a standard helped us a lot. So every time that we need to do any of these tasks, we use the makefile and then make commands. So some examples of commands that we have is like makestyle that already saw the pre-commits and the git hooks. Also make tests for the PyTest unit tests. Make format with lint. Make check that checks both the lint and the type checks. make run to run the API itself, the scan API itself. So here also is like what we do locally, that is we install these pre-commits and get hooks. So it's always, every time that you commit in your machine or in your dev environment, it will already check and format things for you. So this avoids to have to go there in the PR and say, hey, could you please format your code? hey, could you please use spaces instead of tab or whatever. So, okay, and then the person did the contribution, did the change in the development environment, and now going to open the PR. So what are the strategies that we use to help in this scenario? So first is like PR templates. So when a person opens a PR, it already gets pre-filled with a lot of information, so the person needs to kind of fill this form. So this is how it looks like afterwards, after filling. So we have a checklist, and the checklist points to the documentation. So, for example, it says you need to check if your change needs a change log entry. And then it points to the change log documentation that explains what needs to go to the change log, what doesn't. So, this we ensure that the person at least, I mean, we ensure, no, but we try to make it clear that the person needs to follow these steps for having the PR reviewed. And this also helps us to review the PR quickly. And for the PR reviews, there is something that I learned a long time ago is that people hate way more us than the robots. So if you say something like, hey, could you change this title? It's not falling. The person will go, eh, these maintainers. But if you put a robot, all good. So this is like a really good strategy that we use a lot. So if they want to hate someone, hate the robot. And so the first one is like we use the first interaction. So we check if the person is like a first contributor. and if yes we say we send like a welcoming message saying like hey thanks for contributing here is the contributing guide if you want to read it would be amazing and all this and also um yeah and also there is one thing i mean i will talk about this afterwards but it's uh when we merge a pr of someone we invite this person to join the organization so then the person will be able to have this kind of API there, their GitHub profile. And sometimes it helps for portfolio or, I don't know, just because people like badges. So we use this strategy. So every PR measured in any repository of ScanAPI, you are invited for joining the community. Also, so talking about the PRs, we use these make commands to run a lot of checks. So then we ensure that both in dev and in the PR, they are being already evaluated. And we have some other nice workflows. For example, there is one that validates the PR title because we follow the conventional commits. And we use Squash. So the title of the PR will be the commit when merged. And then we validated it. And then we put the robot to say nice things like, hey, bro, please. this is not falling, this is like, and then we say, like, the options, and we give examples, so trying to help, and if the person fixes it, then the comment disappears, so nothing happened here, and nobody saw it, all good. So also we have, like, one workflow that run the example, so about this repository that I was talking before, that is the examples. So this is a workflow that goes and clones this repository, and start testing your new version of ScanAPI with the changes with these APIs, and to ensure that everything is working. So it's more like an integration test or an end-to-end test. So then we are covering the unit and also here in the whole flow. Yeah, so then when you run, we run against these three APIs. And then in the artifacts, you can see the report. So also, this helps a lot when we are with, because the checks tell the person like, hey, something still needs to be done to have this PR approved. So with this, we can guide easier. Like, hey, thank you for the PR. It's nice, but these checks are not passing. Do you need help to fix them or not? So it helps in the interaction. Another thing that helps a lot is the saved replies. I have a complaint here on GitHub that you can only have saved replies for the user account. So we cannot have the saved replies for a scan API organization, for example. But it helps to keep the vibe, because sometimes you are tired, and then you're going to write like, ah, yes, please fix this, and with zero charisma. But then if you have saved replies, You can put there and say, hey, thank you very much. Thank you. And then you ensure that even like your friend that maybe doesn't have that skills communicating can use this. So it would be really helpful if you could do this like in an organization level, but these we put like in the documentation, like people, hey, if you want, you can copy and use this. Also, code owners are for the reviews. It helps a lot. We create like some groups. Here we have the core team and the maintainers. And then depending on where they change the file, which part of which file they change, it will trigger like an automatic request for review from these specific groups. So then we ensure that everyone is notified to review and the PR will not be there like stale. And then once the PR is merged, Here is the message like, hey, thank you very much, your first PR was completed, if you want to join the organization, we are going to send you an invite, and all this. Also, afterwards, it runs again the pipeline, so it checks everything again, run examples, run tests. So, and then we know that this was, like, this is also working on the main branch. And then we have the release. First, I was doing the release in my machine, which was kind of painful because everyone was like, hey, Camila, can we have a release? And, I mean, so, and also because you need to have, like, the PyPE token. So, then it's like, ah, you need to give access to someone to have. No, no, no. So then we use the token from the PyP directly for development, and then we edit it. So every time that we create a version, we use semantic version here, we create a version on GitHub, then it automatically creates the release on PyP. It's not 100% automatic because we still don't trust in our process. So we need some time still. I prefer to have the, I don't know, go there and check and everything fine, yes, and then doing this one-click thing. But yeah, maybe we would be more mature in some time and then we'll say like every two weeks the release happens. About security, let me check my time. About security, there are a lot of things that I could talk because the more contributions that you receive And the more people using your library, probably you are going to have more issues with security. So let's try to keep it safe. Some things that you might know, but for me it was like a lot of them were new. So if you go in settings and then you have like advanced security, you have a lot of options to tune your repository. And also, if you go to the security and quality tab here, you're going to see the results of these configurations. So some things that I want to highlight that are quite important. First is code scanning. So GitHub uses CodeQL. So with CodeQL, it has a static analysis, so it checks your code before anything, and then it gives you inputs about, I don't know, here this code could have some injection, so it gives you some idea. Secret scanning, so GitHub helps you to avoid, and if it happens to alert you, that a secret is being published in a public repository, which might be quite bad. So this helps you with this mistake. Security advisors also are amazing. I didn't know about this before, but you can go, if you configure it properly, you can open, like people can open issues private. Because imagine that you have like a security issue and then you open there in the tablet. Oh yeah, if you do this, you are going to destroy the system. And then other people will see it, right? So it sounds basic, but when I saw... And we have, like, one security issue that was open, I don't know, like, 2019. And it was all this time they're open. We didn't have any complaints so far. But then when we did the security training, we were like, ah, maybe this shouldn't be public. So the security advisor is nice. And you can even, for this, you can even make, like, a private fork to solve this problem. So then, because imagine that you were doing, like, open a PR there in public, or your fork, public fork, then people would be able to see it, right? So, this is a pretty nice feature. Also, if you configure your security MED with, like, the instructions, when you open, like, an issue, it already points to this and also points to the security advisor. So, it avoids people to also post the issues directly there. and also I would recommend branch protection so then you ensure that things that you are not expecting will not go to the main branch for example code depend about checking for the securities and suggestion like open PRs for you to fix them one thing that was kind of tough to define it was like how to take decisions so we had this problem that okay how we define about, like, you know, architecture decisions or the path, new paths for this kind of API. So we implemented one strategy that is, like, creating an issue with the label ADR, that is Architecture Decision Review. So if you want, like, to talk more about it, this would be, like, both ADR and RFC, but it's, like, you talk and then we discuss. And once it's, like, defined, we create another issue with the tasks. and I think this is like one of the most important thing is like community so how you don't go crazy and like starting burning out with one project or if you have more than one project so how do you fix this so and also like how do you motivate people to keep contributing with your project this is like super hard and how do you country like how do you make new people that are like learning their first contributions how can you motivate them to also be there so you want all different types of experiences here right so and besides this you have like that problem that everyone is from a different place so then you have culture different cultures with different types of communications so you have a lot of it's a huge effort to maintain and to understand how to create this community and how they will help you. So for this, the only way to do it is with people and people working as a team. So for this, Kumbuka is trying to help a lot. It's already helping in Scan API, but I'm trying to do this also for other open source projects. So first, we have a community on Slack. So there are a lot of other maintainers there. So we talk. For example, I'm trying this in my repo here. Do you have anyone else had this problem? So then people discuss. We have and we try to have always at least two people guiding each project. So then these two people, one can go to vacation or holidays and then come back. But also, we have this community. So then if you are working in one repository, but then you think, I'm OK with it. I already work it a lot. So I can change to another repository and then teach the others to also maintain the previous one so it's like a community. Also, we create dev tools for the community in general. So if you go in kombucadev slash shared workflows, you have a lot of these workflows that I was mentioning, like validating tide, auto-sign issues. And then you just need to copy three, four lines and put it in your repo, and it will already work. So this is a nice initiative. Also, we create, like, templates with the documentation already placed so you don't have that much work to create everything from scratch. But just one thing that for starting, please don't go crazy and try to do all this, right? So this is, like, for projects that they are scaling and you're filling this need. For starting, you go with your license, your README, contributing, create issues. I mean, make it available for people to create issues, and that's it. So don't go crazy. With this, for me, it's crazy because when you start already creating issues, somehow people start finding your repo. So I really think that with these four things well-structured, you can already start, you will see already some traffic of people trying to contribute with your project. So how you can get involved? If you like it, something that I was talking here. So we have ScanAPI Office Hours. This is another strategy that we use for the community. So every first Friday of the month, we meet in a Google Meet online conference. And then we talk about what we are doing, what are the problems, or if someone is using ScanAPI and is having problems. I am trying to adopt ScanAPI at my company, but this use case is not working. So we discuss this basically one hour. So every first Friday. The next one is May 8th. So if you like it and you want to join and see what the crazy things we are doing, just join. What else? If you would like to give a star, that would be amazing because it helps a lot for people reaching out and seeing and growing the visibility of the project. So it would be amazing if you could give a start there. So then these things happen. Like, for example, GitHub, Red Hat, they started seeing us and helping and using. Also, yes, if you want to support Scan API in any other way, you can share with your friends. You can use it. That is already amazing. Create issues. You can complain. You can ask for features. you can help. And also if you have some extra money and want to give some for ScanAPI, we have GitHub sponsors too. This is all the money we use to keep investing in the project. Also if you like the idea of CumbucaDev, if you think that it will be helpful for someone else or for you or if you want to be a volunteer, here you can get our contacts. And the idea is that the same Kumbuka is like we try to create things for the community, so we create tools and we create the whole structure for the community, so if you want to support us. And here are three more GIFs that I couldn't fit in the presentation, but I really love them, so they are just for this. We have some Brazilian sweets here with stickers from Kumbuka and Scan API. Once we finish it, please feel free just to grab them. And thank you very much.

Speaker 1 [41:29]

Thank you, Camila. Let's go to questions. Okay. The first one is, are you already getting or preparing for AI slob PRs? Any recommendation on how to manage this situation?

Speaker 2 [41:45]

So it is not, I'm surprised that this has not happened yet. Or at least that I noticed. Because like I went, like last year I went to the GitHub universe and we had a day only with the maintainers, like maintainers of huge open source projects. And we were there and everyone was already complaining about it. I don't know what happened. We still didn't have this problem. But for sure we will need to do some, I mean, we will need to open a conversation, like an issue there to discuss like what will be the guidelines. If you are going to say like hey, there are this limit or we need to I don't know, the PR please don't put something that only was generated by AI so besides the AI itself opening things so we didn't have this problem yet thank you but we are waiting for it unprepared I don't know what you're talking about.

Speaker 1 [42:44]

Did you provide the full documentation like tutorials right away or was it built incrementally?

Speaker 2 [42:59]

it was like the basic it was really like draft but I tried to from the very scratch what I was doing I was documenting because if I have this I can have the support of people to help me so this is like something that for me was important to always have the readme and the contributing and the issues there because sometimes we think about no I will create the whole project and then I was then it I mean you can already receive the help before so and also I think that people that join the beginning they usually get more emotional attached with it you know so then they're like yeah let's build this together so for me it was like really basic really not well structured with website clicking but it was basic there was there was always a documentation there

Speaker 1 [43:51]

Are you measuring the health of the project? If yes, could you share more?

Speaker 2 [43:56]

Yes, so we use, like, deep source that helps use, that it's in the pipeline, and it checks, like, for example, static analysis and also test coverage and documentation, doc string coverage. And we also have, like, other tools that they do this. I mean, they are there in the internet, and they do it already. Like, for example, I think it's Nick. I don't know if this is how it's pronounced. So if you put, like, scan API health, And something like this, scan API library help, it already gets in a lot of websites, and then it gets a score. So it checks, for example, how is the maintenance? When was the last commit? If there is all these files with the documentation, it checks a lot of things. It checks about downloads. So we also are aware about this, and we check from time to time.

Speaker 1 [44:56]

Do you have any tips on how to build a trustworthy core team maintainer team?

Speaker 2 [45:03]

Like the team itself, okay. It's complicated. It's like the same as, I don't know, you have a company and then you need to find someone to help you. You need to somehow have a trust. So what I do is usually like first people is like the people that I know and then it's like, hey, do you want to build this with me? A lot of times it doesn't work. So then it seems that my persuasion is not that good, so I need to improve on that. But still, I had some people that I was like, I don't know, someone. But if you get one or two, it already starts good. And then afterwards, for me, it helps to see the involvement of the person. So if you start seeing a person that contributes three, four times, five, after some time, the person is still there and talking and discussing, And then you say, okay, maybe you want to help us maintain it, and then you give more tasks, and then you see. But you are never safe, you know, like the world is wild. So I don't know if you give ownership for someone else. So you need to, it's an important part of the governance of this.

Speaker 1 [46:18]

Do you have recommendations for single developer open source projects? How to reach out to others who could be interested in contributing?

Speaker 2 [46:26]

Yeah, so this is usually what I say, because the GitHub search for me doesn't work that good for discovering open source projects that you could join. So what I usually suggest is go for something that you already work with or that you like. So for example, you are using one library there in your project or in the company that you are working for, and then you like it a lot. Okay, then you go there and start checking, you know, the read me contributing seems okay to contribute, there are open issues and then you go like this because also it will be nice because you're going to see the results because you're an user, right, so I like this approach of trying to go in an environment that you are already kind of used to it.

Speaker 1 [47:20]

All right, with that, I'm going to stop the Q&A session. But feel free to reach out to Kabila around during the conference. And with that, let's thank Kabila again for a very nice talk.