Contributing to Ethereum and Open-Source by Danny Ryan (Devcon4)

hello I'm Danny Ryan I work with the etherion foundation on the research team work on research specifications education communication etc a lot of coordination these days I'm here to talk to you about aetherium and open source and getting involved maybe deeper with the community if you feel any way like I do at the end of Def Con you're super inspired your super enriched and excited about the future that aetherium holds and you know sometimes we need some help to figure out how to channel that that energy so before I talk about that this is a blank slide because I'm going to talk about me I don't need to put bullet points about myself I just want to kind of ground this and in a little bit of personal story I've been a firm believer in open source for many years believer in the sense that this is open source is going to drive the future that I want to be a part of the future in which we control our destinies the future in which we can enable ourselves to live live in the reality that we seek but and this is this is something that I'm somewhat ashamed of and and at the same time proud of at this time before the beginning of 2017 made pretty much zero contribution to open source although I've held these firm beliefs for a long time I just I never found my avenue and I never felt the drive to finally make that poor request and and really get involved with a project and I'm ashamed because I knew that it's something that I should have been a part of but I'm proud of it and I'm not proud of it necessarily for myself I'm proud of it for the community at this point year and a half two years later I'm working on incredibly awesome work I'm working on like high value deep infrastructure for this community and and it's not because of anything I did its up that I stepped up and try to do it it's more about the ecosystem it says how one how early the ecosystem is and how there is so much to do but also about the project maintainer z' and the people in this community and how open they are to really anyone knocking on the door and saying let me help and so I just wanted to ground you in that and that there is so much opportunity to get involved and getting involved is a good thing in terms of for yourself getting involved in this community is enriching and helping you get to where you're going so back to the talk not about me by the end of Def Con you should have this feeling of that I do at least aetherium is the future or at least the future that I want to live in and the future that I want to be a part of in the future that I want to build and but at the end of the end of Def Con you may be asking so when when are we going to get to this future and how are we gonna get there and maybe most importantly you might be asking what what can I do the answer is simple contribute to open source and this is an interesting concept in the etherium community because and in the etherium stack because most of what you're going to be doing even if it isn't building core infrastructure and building public resources is open source you're building like open source contracts open sourced apps that people can interact with and know the bounds and rules in which the games they play but I mean when I say contribute to open source I mean contributing to public goods contributing to things that don't just help you and your end user thing that you're building but contributing to things that build out the core infrastructure and enable not just you to succeed but enable the entire community to succeed before we dig deeper into that I just want to talk about this ecosystem is created by a number of diverse teams diverse projects of all shapes sizes colors it's and before you begin to get involved with any any project I want you to think about etiquette before you show up on somebody's doorstep to begin contribute contributing take a look at their repository take a look at how they how they do things how do they communicate how are they structuring issues how are they formatting pull requests what what sort of syntax and structure do they generally write code you want if you want to come in and make changes and make a positive impact on an existing project take the time to make somebody's job easier and better than making it harder and takes a little bit of etiquette and just a little bit of thought and a little it goes goes a long way so I want to give you kind of the lay of the land with the etherium ecosystem and maybe some good ways to get involved with the the various layers and one way to think about it is maybe an onion in the center we have research and specifications and clients and web 3 and and it's it is like that but it's also kind of like this it's a little messy sometimes it's hard to see the where the where the lines are drawn people work on different portions of the stack and it's one big delicious mess and I hope to help parse it apart a little bit and give you some avenues to get involved so the innermost layer I would call research and specifications so this is kind of from an outsider's perspective sometimes it's the most opaque it's the most kind of thing that maybe you wouldn't you wouldn't figure out how to most easily get involved and easily contribute and I'd say it's true that it seems that way but you can actually really make an impact in this layer and get more involved with this layer without too too much work like with papers read drafts when you're reading the drafts be an active reader fix typos find bugs like often there's like weird references that are just incorrect a great way to enhance your understanding and also enhance the contribution of the community is create figures enhanced figures and for all of these super super important create translations like most of us in this conference or English speakers but if we want a theorem to make the impact that we want on the world then we need to get this broader than just the english-speaking community saying with specifications a similar path III search check it out follow it follow it read it follow it contribute when you can all this kind of stuff you can iterate you read more you learn more and as you as you get deeper in you can contribute more and more blog posts similarly read them but write them as you were beginning to take on new concepts sometimes the stuffs pretty dense and as you understand it and as you be create the analogies and frameworks that help you understand it if if those weren't out there get them out there and again create those translations the really the core here is you need to read you need to read and then read some more and read some more and then it begins to make a little bit more sense another way to get involved with research and specifications and this is kind of my main avenue that got me more and more involved in the community is create proof of concepts often researchers post these radical new cool ideas that have really solid mathematical and algorithm foundations but often the community doesn't really know if and when things are ready and a great way to vet it is to create proof of concepts and that helps you understand it helps the researchers get a better handle on their ideas you can iron out bugs and specifications and honestly if you knock on some researchers door and say hey look what I built or hey do you think it makes sense if we do proof of concept or hey I see you have a proof of concept can I make a graphic interface like they're gonna be so receptive to you helping out like this is super super easy nup not easy it's not the right word a great Avenue to get more and more involved the next layer out is probably the clients which are the implementations of the protocol they translate the protocol specifications into a reality the cool part about this that there's so full-stack these are pieces of machinery that touch everything databases networking algorithms ui/ux you name it it's got it and so because of that there's very likely if you have any programming experience at all there's very likely a component of this stack that you're somewhat familiar with and so that's a great way there's a great avenues there and like they come in all shapes and sizes diversity is a win there's clients old and new there's a ton of them and because of that often one will fit into your realm of maybe language expertise and so a common path would be pick go find find a repository for a client that you're interested in working on find issues that are relevant to your domain if you're coming from a web application stack and you've been working in databases optimizations maybe opening up one of these clients and finding some of the database issues will give you an avenue to begin to contribute and from there you can branch out you can start taking on issues that are a little bit more outside of that domain and then Buzz five before you know it you're a client of this is actually how you do it go in and start contributing like there's nothing the difference between you and a client developer is that a client developers doing it the next layer from there we'll call the web three this is how developers interact with the core protocol how developers interact with the client implementations this really is the first step that defines our developer experience and defines the ease with which people can begin to interact with this platform and if we take the time to build clean and beautiful api's in this layer we're going to enrich and enable our community similar to the clients they're written in all sorts of different languages we need more this is really if you are familiar with language X and there is no web 3 library and language X that's a great opportunity to get involved and vegan contribute because these serve is really the main onboarding points for entire communities of developers and for the existing stuff what you can do you can as you're using this stuff like it will become clear oh there's a bug oh there's a missing feature file bug reports fix them fix the bugs build out features if you go look I'm sure web 3 dot whatever has tons of issues about potential features that they want to build they're swamped if there are features in that feature set that you can help enable and contribute go and build them increase testing optimize I don't know I write optimize these usually don't need to be optimized too much the next layer out from there I would probably say is the developer tooling so all of the things that help make development more efficient safe and fun for developers this in the past year is definitely growing but if you've begun to develop on etherium you know that there's so much to do we could use more domain-specific libraries that build on top of web 3 maybe some gaming libraries maybe some gam all sorts of stuff debuggers I think we're in great need of debuggers of those both of our contracting languages and also debuggers of the EVM and clients themselves IDs testing framework there's so much to do in this layer and if you begin to develop in the application layer it's going to become immediately obvious the big thing this is kind of the path as an application developer notice the pain points don't just complain about it don't just say to your buddy like oh this sucks man like notice them take note of them and fix them like if there is something missing from the developer experience create it enable it give it to the community share it with the world and beyond there are tons of layers and layers become a little bit more blurry and they begin to interact with the user layer but testing layer 2 infrastructure layer 2 frameworks take notes on public calls there are things that you can do even if you're not a developer to help enable this community from that open source ethos local meetups political advocacy testing documentation testing documentation if I didn't mention it before testing and documentation are seriously lacking in this ecosystem and it is a great way to begin to contribute to begin to meet the developer community and to begin to get involved to make a make an impact man I'm just blowing through this so this is the empty slide next phase of this talk is I have some concrete calls to action for three different groups the project maintainer x' we can all do better we can all enable our contributors more we can all take that extra time to enable people to come in and contribute and by doing that we can go from that guy being alone to this you know bunch with shovels building the whole thing lead by example make even if it's even if it's silly stuff that like your buddy is someone you work really close with is going to be reviewing and you have a common workflow like lead by example make well specified issues have well-structured pull requests do have somebody do code review on your stuff this next point good first issue I think is one of its so incredibly obvious and so incredibly simple but it enables it is like the best I cannot say it enough it is the best route you can give to people to begin to dip their toes into your project and to build up from there and become serious contributors and don't just tag things with good first issue make it even if it's simple you you hold the project in your head do a brain dump make it as easy as possible for a developer to come in say you can you could probably do it in 30 minutes or an hour like clean up the whole issue or instead you can take five minutes and say you should probably check out this file maybe you should check out this function this should probably be tested in a similar manner is this like I cannot iterate enough if you want to enable people in your ecosystem give them a clear path in another thing that we all need to work on is documentation if you're don't just yes you can write more documentation but maybe you should be writing more code make it clear in issues in some forum that where the documentation is lacking and and allow people as an avenue to come in and contribute and enrich it so project maintainer y'all are badass like absolutely badass we can't do this without you but take like help other people help you individual developers you need to contribute you need to contribute you need to contribute for many reasons one yes you need to do it because if you don't do it nobody's going to do it and this ecosystem needs to be built by somebody but I'll flip it a little bit this can actually be a pretty selfish action in our ecosystem I firmly believe that the best way that you can further your career in the etherium ecosystem is to contribute to public infrastructure and public resources from there like that is how you make a name for yourself that's how you begin to work with the people that are building serious stuff if you don't get the reference Google Steve Ballmer developers okay my last call to action organizations at least 20% of your developers time should be spent on building public infrastructure and public resources and I know a lot of you are doing this but I think this should be a bare minimum industry standard for the etherium ecosystem and I I ask you developers put the pressure on the people running the organization's make this our hiring requirement asked are we going to be doing 20% time are we going to be focusing on building out the core infrastructure and again this is similar to the selfishness that a developer can have in building out open-source to build out their network and build out their their career similarly this is how as an organization you make a name for yourself and how as an organization you enrich your company and you bring on better developers etc etc if you are in an organization today and you're not building public resources and public good put a pressure put pressure on your on your managers on your project managers CEOs whatever whatever you need to be contributing you need to build this stuff because it's not going to build itself that's all I got today I kind of flew through it I'm very eager to take questions if you have any questions for me [Applause] what was that yeah if you want to ask me about if serenity that's fine too I actually if it's okay I would like 70 okay yeah so basically Canyon give me like more details how will actually a registration of validating service work and how we can actually protect against stealing of private keys of validator and protect our deposits sure there are multiple avenues so I think the first component is how do you register you register with a public key but importantly you register withdrawal address that is distinct from your signing key this means that even if somebody over took and controlled your public key the worst they're gonna be able to do is either log you out or have you sign some slash herbal offense fortunately because we're using variable slashing we're the amount you're slash is proportional to the faults that could have been made in the network so as more people are creating slash munitions in a given stretch of time the amount with which your slash is gross so if you're a relatively small validator and this happens to you you're likely you're going to be ejected you're gonna lose some amount of capital and your funds are gonna be locked for four months those are kind of the the main things other things that we're looking for looking into in terms of protection is just enabling the core networking protocol to be generic enough such that we can better obfuscate who the validators are this is gonna happen more in the the user about like who's building the user validation software but at least designing the protocol in a clean way such that you have the option ality to obfuscate who you are and try to protect yourself on the that where someone can slash my deposit right what was that if someone can steal my private key it can do something and slash my deposit right it's like worst case scenario yes but what I'm saying is if you're if you having your private key stolen is not highly correlated with a bunch of other people having their private key stole and then the amount with which your slash is gonna be minimal which is a big argument for having diverse client setups okay hi and this is a contra contribution question from a perspective of a project we've got about ten people knowing on like developer evangelism what where's a good place to start whether that's documentation versus creating more first issues and then second what are like the operational processes to help ensure that this isn't just like a quarter focus and that drops so the question is twofold it's how we can what are the best avenues as an organization to beacon where would you start as a ten person um start well two things one start with you're gonna hit in the developer experience and etherium it's gonna become abundantly obvious what needs like what is missing there's gonna be something in your workflow where you're gonna be reinventing the wheel if you reinvent the wheel or if you start creating internal tooling for some part of the developer experience tak open-source that give it to the community and that's that's definitely a great way for an organization to begin contributing and if you have the in terms of the individual developers these guys these people are often just super fascinated by the technology so give them a little bit of free rein if they want to begin working on clients like give them time to work on the clients if they want to begin working on a debugger give them the time to work on a debugger this is a contribution question what is the role of a product manager in open source communities interesting I meant to mention kind of who I model when I work on open source projects and I manage and maintain open source projects I try to emulate Piper as much as possible Piper is this incredible force that has these beautifully maintained repos with excellent standards kind of all around and he's taught me a lot and taught pretty much anyone that works on his stack a ton so step one go look at Piper's projects step two the the project manager on an open source project is often simultaneously the developer and the best thing they can do is really like create a strong ethos of standards around what they're doing project management project management management is a tough one because it's often kind of emergent and it's often something that in open source repositories we have some difficulties with so I would say if there's a if your company is working on some sort of open repo and want to add in some version of project management to it it's there's probably opportunity there just to follow on what about product management that's always a big question sometimes we put the cart before the horse in this ecosystem and we just start building things engaging with the users and if for a lot of the stuff we're talking about engaging with the developers is really the best that you can do in seeking explicit feedback about what you're building rather than just assuming hi you think it makes sense to catalyze open-source with the bounty challenge yeah that's like that I I'm a huge fan of get coin I think that they're making a really really great impact kind of coupling these bounty programs with they've they've received a number of grants to kind of dig into certain components of the stack this is kind of like good first issue in that you really you really have to enable the bounty hunters you really have to like take the time to spec it out to be clear about the problem that's being solved and what results you expect otherwise your results will seriously seriously vary and so if you do begin to use some sort of bounty program be very know that you need to be very proactive you don't need to manage these people you need to be very clear about what your standards are and what you're actually expecting from the issues cool thank you very much contributor open source [Applause] you