Open Source Development - What Are We Doing Wrong?

Transcript

Okay, here we go. Um, hello everyone. Glad to see you here even though if it's only for the air conditioning. Um, I'm Belma. I work at Chain Safe as VP of engineering. And yeah, today I wanted to talk a little bit about open source. Uh, especially kind of at the contributors part. So yeah, spoiler alert that's that's the part that we could do do better. Um yeah, this is coming just from kind of a personal observations and also like our experience at uh chainsafe with multiple years of open source development.

Uh requirements for this talk is that you understand what is uh free and open source software. So I won't get into what and why of that. We don't have time but happy to always talk about it. Um we have some audience here so maybe we can do a little bit of show of hands. So how many people here ever contributed to an open source project? Okay. How many maybe tried and gave up? Okay, that's a good confirmation. We'll fix that. Um because yeah open source is kind of a really a crucial component uh in in our ecosystem in web 3. We all love to say

like yes uh we are open source but mostly it's about that GitHub visibility button and yeah uh I don't think that's enough. So in reality uh we are still kind of a bad at open source and we could be doing much more. um you maybe have friends and there are actually a lot of people that want to get into web 3, a lot of engineers and yeah usually the advice is yeah everything is open source so just start contributing and that's really still a fair advice I think it's it's valid and I also recommend that uh and I've onboarded a lot of people to web 3 but

the reality is I even had like hard time like finding projects for them like finding the right stage of the projects depending on the programming language and everything. So it's it's really not so easy and um kind of a first challenge and the people that want to start contributing want to kind of go and learn about web 3 uh they'll look into okay documentation and everything but then they'll try to kind of take a task but the reality is that a lot of uh projects don't actually even label the good first issues. Um yeah, so I went definitely through a couple of popular projects, less popular

ones. Yeah, no one no one cares about that part. Um and yeah, that's really the kind of a first first blocker, first barrier for for the people to enter. And long term, this is really the self-sabotage to industry because we need more people, we need more engineers to achieve all the things that we want to achieve. You can also say yeah reach out to devs uh go on discord ask them uh to take something on again valid advice but um discord are actually empty like the the chats there um have yeah a lot of times there are no answers I mean people are

busy but I also talked to a lot of contributors the one that have contributed to chain safe and other projects and really the main reason that they said like why they give up on contributing to a certain project is lack of communication. So again this is kind of a uh another barrier that's kind of a another blocker for for people to get in and long-term again self self- sabotage for us. Um this this kind of a community standards is a like very small uh feature into in inside the GitHub insights. I think it says it's yeah projects health or whatever. It's not a

perfect feature but it's really a basic basic checklist and I tried to use it and uh went to check a few projects. I didn't name them intentionally but everything looks like it's missing really kind of the basic hygiene. So I looked at protocols, libraries, everyone just yeah misses even basics. So again that's kind of a one of the problems. Um and yeah I've heard a lot of reasons kind of a why people don't put the effort. Um I mean I've heard it from from the engineers in Jain heard it from others like we don't have time. There are like a lot of newbies there's spam.

Um yeah there's we need a lot of more more time to kind of review PRs. Uh I don't think every reason is justifiable but um I think we can you know increase uh increase uh kind of how we do things and I'll get into some tips a little bit later kind of how to address those challenges so you can be maybe a little bit faster with those but uh yeah I don't think there are fully valid excuses. Um yeah, again with so so many blockers uh there there is kind of uh this this barrier that's kind of a hard to get people in web 3. So if we don't get those contributors then someone else

will um okay except the kind of a building the open-source uh community trust uh and culture uh might be wondering okay what are other like project benefits? So some of the like direct project benefits for you are for at least your organization and your project is u new features or bug fixing like a lot of stuff that we do is built for developers. So if they're your users and they're not the one that will contribute to your project then there is a problem there. So generally users want to help and contribute and if you have users who are devs then you should enable that.

Um fresh perspective is kind of always u a good one like a fresh pair of eyes on the project is uh usually valuable uh in software development. And third is um hiring. Um that's kind of where we gain a lot of experience. I'll go a little bit more into that. But we all hate the hiring process. It's um yeah uh it's frustrating like you yeah need to come up with job description you need to go through the interviews recruitment communication um yeah do a lot of things and then when you finally hire someone you still need to onboard them so like with

contributors you're just looking kind of for for the onboarding time so you're replacing everything else uh four thing that I don't want to emphasize but it is True. It's kind of a free labor uh because payment is not a main motivator for a lot of contributors. So you kind of get extra for you. Um a really good example in kind of a web two world that I like, it's not the only one, but the one that I'm mostly familiar with is um Kubernetes. Um so I just wanted to give it as a really northstar uh example that we can look up to. uh because it's really a communitydriven

open source project. So there are no really employees of Kubernetes but the kind of the decision- making governance releases uh all that is has been done by these 150 maintainers. I think they have 150 active maintainers and yeah generally thousand contributors monthly that just come in. Um so yeah these these maintainers uh they have kind of a hierarchies how they kind of organize the decision- making process and the governance uh and you can also like climb as a contributor. So kind of a similar has you have if you have like engineering growth ladders in in your companies that's kind of how they have the

contributor ladders. So you kind of a grow within within the uh contributions contributors. Um so yeah all this kind of a process is basically the communitydriven and if you kind of want to start working on on this problem and be more kind of a more like Kubernetes more open source friendly then um you can look at their docs. They're really, really, really good, especially kind of at the guide and how to start contributing, how to do things. So, yeah, definitely recommend checking it out as as something to yeah, take on and apply.

So yeah, we don't have really in our community, we don't have like a web3 Kubernetes uh in a sense that we don't have such a high degree of open source engagement as Kubernetes does within web3 projects. Um so yeah, how can we create that? I don't have an answer today. It's not one sizefitsall solution. I think we need to get get there a little bit. So I'm starting with this talk but I'm going to share now like um a few few ideas and tips and share our experience um that helped us with with some of the things. So yeah especially want to achieve kind of the the long-term

impact. So uh in Jane um yeah as I said we have been doing open source development for years. uh one of the two things that I want to emphasize today is external contributors program. This is really what came out from our protocols team because yeah first of all hiring it was super hard to um hire hire for protocols. So uh with kind of a contributors and hiring directly the contributors um yeah we made much uh better when it comes to retention and keeping keeping really the people

um you can't always hire. So uh if we don't have that option then we would reach out to contributors and offer them to be part of the paid program uh just because we wanted to count on people and have also their life uh sustainable. Um so yeah that's kind of a an option because yeah you can't always hire everyone. Um and yeah second thing is kind of a finding finding talent. Uh what worked for our protocol teams is um yeah great community group uh I mean uh protocol fellowship but that is only Ethereum and that is um only protocol but yeah very

very good um collaboration with them and who wants to be a contributor definitely recommend it um uh but yeah that's Ethereum but I don't know if if I was to look for Rust contributors Then I would also go to Ross community groups and yeah try to find people there. Um um yeah for for another project what actually worked for them in attracting contributors is streaming. Uh so yeah we have an engineer that streams uh coding on on the Twitch profile. Uh yeah apparently people watch that and want to contribute more. So yeah, that's kind of

one one of the ways. I think other people do like YouTube and de relish stuff, but yeah, this is this is been something that also like attracted the contributors to the same project. Um I mean reputation is important. If no one knows about you, you're going to have a hard time, but that's kind of at the part where you have to be maybe more more proactive and do reachouts. Um, social media is kind of an important one. As contributors know other contributors, they're kind of in this this network. So, if they have a good experience, they'll share it. And yeah, it word of mouth so might attract others. Um again if you want to be proactive and you need to be proactive

in finding those then um you can look into like existing contributors and see where else they contribute because yeah people who occasionally contribute to open source it's just that it's not just one project but they do to multiple and they're always looking for other opportunities. So if you want to be proactive, I found that tool to be a like really good one and to understanding what's going on and uh what what people are are doing and where they are contributing. Um few tips to share. One is contributor license agreement. Uh just to kind of a protect yourself from from the legal troubles. Uh and you can have a bot that

checks every PR for that. Fairly simple. And yeah, second one is the review time the problem that I mentioned before. So how to how to decrease that like engineering time, the context switching and everything? Well, um you can't disable it completely, but you can do maybe a few things that can improve that. One is of course maintain the nearest owners file so the right people get notified. Use the automation tools. So yeah, those those also like help do all the checks uh making sure it's green on that end before someone looks at it. And third is a thing that we are experimenting with,

but that's AI code reviews. Um I think they should be good to some extent at least to kind of um uh help with the new BPRs or help with spam or whatever and yeah should at least check the code style, check the basics. So when an engineer comes in, they have like um they don't need that much time to check really everything everything and make every comment manually but the AI can do that. So there's like less less human uh intervention and there's like less time uh wasted on addressing the smaller things or less complex things.

So still testing that um but definitely should help to some extent. um additional potential strategies that you can maybe use is um enabling contributions. So people start with docs. That's kind of the easier way to do it. Um I think for a lot of people like contributing to just code and making a PR is um is scary. Uh so yeah and starting with dogs is kind of what what people would maybe like to do. Uh second thing is bounties. Um those are kind of fairly simple and in sense you have a task and you want to outsource it

to the community. So you can create a bounty, put a prize on it. There are like really good good GitHub systems that do that. It looks really nice with labels and everything. Um this is good because it also also opens up um to a larger um target. Um because yeah, more people are kind of interested in in bounties as well. Uh and yeah, what happens also with this is that you um also get more more engagement in terms of stars or whatnot.

So if that's kind of important to you, that's an extra effect. Um, third one is recognition. And I think that's something that sorry I think that's something that um not a lot of people really look at or it's like underestimated but um I think for a lot of contributors we should be thankful for their contributors for their contributions. So it's not just looks good to me in a PR but uh rather you go kind of a extra step for for for their recognition. Uh you can do basic stuff just kind of a readme list or whatever.

You can go more more sophisticated and advanced with POPS or experience systems but yeah doing kind of additional small thing I think is really good for retention and again recognition. So yeah, I wouldn't see just open source as a development model. Uh we should uh maybe build a build a culture uh for building things greater than ourselves and uh create much more welcoming uh communities.

So yeah, I think that's all for today. Uh if anyone wants to discuss, exchange any ideas, experience, yeah, feel free to reach out. I'm usually easy to find. Thank you. [Applause] Anyone want to ask a question to Velma? Um how do you feel in the balance uh contributions are that are driven by things like Htoberfest or effectively like you know airdrops that retroactively end up incentivizing people to have worked on underlying

projects. Um I mean the the first part like the the the kind of the festivals I I I don't think we have like web three specific. I mean can we don't have to like Well, GitHub does this, right? Yeah, GitHub does that. Yeah. Um I I think that's also like good way to to engage. Definitely. And it's especially it's short time. Yeah, I think it's also a good potential strategy because you can attract someone for for a short time. It's not like continuous thinking. So yeah, I think that's a easy win. And second airdrops tricky question. Uh I think a lot of airdrops were were designed just to um reward even a very small contribution.

So we started to see a lot of spam, but that's not problem on the contribution side. It's rather than the airdrop economics. Uh but I think there's less and less of that. Uh but yeah, overall uh rewarding contributors and core devs uh still still valid, but I mean it's not like they do it for the airdrops anyway. Anyone more? Great. The presentation is finished.

Thank you. [Applause]