Pitfalls of building public goods with permissionless work

Transcript

[Music] all right uh hi I'm Andre uh I work at Carmine uh we are a risk management platform uh but what I work on currently uh is that I'm building koha which is a Tok for thousand shut basically if you need some governance functionalities on ethereum which is for compound right if you need a staking curve it's just for curve but there's nothing such in stut because we are not the evm and that

needs to be built uh and we're building that as a public good uh we have funding from the St Foundation through only dust uh and they are doing this to help on board new developers to the ecosystem how only does works is that the contributors get paid for every PR that I merge uh we set the amount and they can either fix an existing issue that's open or they can also uh add their own PR so yeah uh it's live in multiple ecosystems uh there are even some bigger projects you might know like Viper or wreath uh what's very cool is that the the contributor can actually just set

what they work on right so let's say I want to there there's a library that I use and I need to fix a book and now there's this dilemma of kind of like do I fix it myself and do I Upstream it or not and it helps to push the last yeah because we pay you we help you uh get over that last hump it's really good for the contributors especially as a first experience because you get hands- on help on a real project which is usually much better than school right because it's a real project and they're

actual there's a actual business context right it's as I mentioned very good for the open source contributor and uh it's usually also a present surprise like my first experience with indust was when I fixed a bug in a library that I were using and then I got a message from the maintainer and he was like oh yeah I didn't find your only dust I was like what's only dust and uh he told me I'm just going to get paid a few bucks for that which was super cool let's look at how does it look like from the project perspective when you have these contributors who decide what to work on and have no commitment right obviously

they are quite FL and you can't use it as the main way to get work done because they usually don't have the context of the whole project they try to work only on the issue that they are assigned right it's basically impossible to assign hard inter dependent task where you need to get the whole context of the project uh in mind but still it helps a lot and it helps on boarding developers so it's fun usually also uh the time managing the contributors is more than the time I would spend doing it myself but that's a cost right and that goes down with time so what did I learn doing this one

thing is that students are actually the best contributors uh partly because everyone has to be a student right even those they are technically not in University they are super eager to climb the learning curve and to actually get the work done contributors procrastinate a lot what I found helps a lot is just to ask them can you set yourself a deadline and you need to do this even for tasks that are not not critical like I don't care whether this task is done in a year or 6 months or 3 months but if they don't have a deadline they will just keep postponing it forever obviously what's Maybe

not quite obvious is that if you get plain B code it's very hard to give feedback on it right you can point out a few issues with it but they fix these issues but if it needs a big refactor like I would just refactor it myself so which is why I have the contributors open a draft PR and check their first comets and if it doesn't look like they will be up to the task I just asked him are you sure that you are handling this and it actually really works well because obviously they have a good idea of how well they're doing because they spent the time uh doing the initial work

right excellent writing is super necessary for this to work at all because the contributors will usually read just to read me a bit of the docs and the issue that they that they got they will not read the code and you need to serve all the information they need to get the issue done on a silver platter and make sure that they don't build something else than you want to build uh all right that's it uh do you have any questions okay yeah are you using are you using any tooling like wonderverse

or dwork or any of those platforms that allow you to have distributed teams in Dows uh no and I'm not sure what these tools do to be honest uh I just use GitHub if that makes sense cool thanks thank you [Music]