 Hello, I'm Danny Ryan. I work with the Ethereum 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 Ethereum and open source and getting involved maybe deeper with the community. If you feel anyway like I do at the end of DevCon, you're super inspired, you're super enriched and excited about the future that Ethereum holds and you know sometimes we need some help to figure out how to channel that that energy. So before I talk about that, there's 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 in the reality that we seek. And this is something that I'm somewhat ashamed of 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 in. I never felt the drive to finally make that poor quest and really get involved with a project. 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 mean, I'm working on like high value, deep infrastructure for this community. And it's not because of anything I did except that I stepped up and tried to do it. It's more about the ecosystem. And it says how, one, how early the ecosystem is and how there is so much to do. But also about the project maintainers 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 help you get to where you're going. So back to the talk, not about me. By the end of DevCon, you should have this feeling of that I do at least. Ethereum 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 and the future that I want to build. But at the end of DevCon, you may be asking, so when are we going to get to this future and how are we going to get there? And maybe most importantly, you might be asking, what can I do? The answer is simple. Contribute to open source. And this is an interesting concept in the Ethereum community because and in the Ethereum 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 source dApps 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, et cetera. And before you begin to get involved with any project, I want you to think about etiquette. Before you show up on somebody's doorstep to begin contributing, take a look at their repository, take a look at how they do things. How do they communicate? How are they structuring issues? How are they formatting pull requests? What sort of syntax and structure do they generally write code? 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. It takes a little bit of etiquette and a little bit of thought. It goes a long way. I want to give you the lay of the land with the Ethereum ecosystem and maybe some good ways to get involved with the various layers. One way to think about it is maybe an onion. In the center we have research and specifications and clients and Web 3. It is like that, but it's also like this. It's a little messy. Sometimes it's hard to see where the lines are drawn. People work on different portions of the stack. It's one big delicious mess. I hope to help parse it apart a little bit and give you some avenues to get involved. The innermost layer I would call research and specifications. 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 figure out how to most easily get involved and easily contribute. 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 in this layer without too much work. With papers, read drafts. When you're reading the drafts, be an active reader. Fix typos. Find bugs. Often there's weird references that are just incorrect. A great way to enhance your understanding and also enhance the contribution of the community is create figures, enhance figures. For all of these, super, super important, create translations. Most of us in this conference are 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. Same with specifications, a similar path. E3search, check it out. Follow it. Follow it. Read it. Follow it. Contribute when you can. All of this kind of stuff you can iterate. You read more. You learn more. As you get deeper in, you can contribute more and more. Blog posts similarly. Read them, but write them. As you're beginning to take on new concepts, sometimes the stuff's pretty dense. As you understand it and as you create the analogies and frameworks that help you understand it, if those weren't out there, get them out there. And again, create those translations. The core here is you need to read. You need to read. And then 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 researcher's door and say, hey, look what I built. Or hey, do you think it would make sense if we do proof of concept? Or hey, I see you have a proof of concept. Can I make a graphic interface? They're going to be so receptive to you helping out. Like, this is super, super easy. 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 is that they're 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 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 database 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, before you know it, you're a client of. This is actually how you do it. Go in, start contributing. Like there's nothing, the difference between you and a client developer is that a client developer is doing it. The next layer from there, we'll call 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 APIs 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 three library in language X, that's a great opportunity to get involved and begin to contribute because these serve as 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, 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 three 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 why 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 Ethereum, you know that there's so much to do. We could use more domain specific libraries that build on top of web three, maybe some gaming libraries, maybe some all sorts of stuff. Debuggers. I think we're in great need of debuggers of both of our contracting languages, and also debuggers of the EVM and clients themselves. IDEs, 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. 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. The layers become a little bit more blurry, and they begin to interact with the user layer. But testing, layer two infrastructure, layer two 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 and 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 maintainers, 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 bunch with shovels building the whole thing. Lead by example, make, even if it's silly stuff that your buddy, someone you work really close with is going to be reviewing, you have a common workflow, lead by example, make well-specified issues, have well-structured pull requests. Have somebody do code review on your stuff. This next point, good first issue, I think is one of, it's 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 hold the project in your head. Do a brain dump. Make it as easy as possible for a developer to come in. Say you could probably do it in 30 minutes or an hour, 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 as this. 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 allow people as an avenue to come in and contribute and enrich it. Project maintainers, y'all are badass, absolutely badass, we can't do this without you, but help other people help you. Individual developers, 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 is 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 Ethereum ecosystem is to contribute to public infrastructure and public resources. From there, 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 developer's 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 Ethereum ecosystem. And I ask you developers, put the pressure on the people running the organizations. Make this a hiring requirement. Ask, 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 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, et cetera, et cetera. If you are in an organization today and you're not building public resources and public good, put a pressure, put pressure 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. What was that? Yeah, if you want to ask me about serenity, that's fine too. Actually, if it's okay, I would like to ask about serenity, okay? Yeah. So basically, can you give me more details on how we'll actually, registration of validating service work and how we can actually protect against the 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 a withdrawal address that is distinct from your signing key. This means that even if somebody overtook and controlled your public key, the worst they're going to be able to do is either log you out or have you sign some slashable offense. Fortunately, because we're using variable slashing where the amount you were slashed is proportional to the faults that could have been made in the network. So as more people are creating slashing conditions 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 going to be ejected, you're going to lose some amount of capital, and your funds are going to be locked for four months. Those are kind of the main things. Other things that we're 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 going to happen more in 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 optionality to obfuscate who you are and try to protect yourself on that layer. So the worst case scenario is that 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 stolen, then the amount with which you're slash is going to be minimal, which is a big argument for having diverse client setups. Okay, thanks. Hi, this is a contribution question. From a perspective of a project, we've got about ten people knowing on developer evangelism, 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 quarter focus and that drops? So the question is two-fold. It's how we can, what are the best avenues as an organization to be contributing? Yeah, where would you start as a ten person? Start? Well, two things. One, start with you're going to hit, in the developer experience in Ethereum, it's going to become abundantly obvious what needs, like what is missing. There's going to be something in your workflow where you're going to be reinventing the wheel. If you reinvent the wheel or if you start creating internal tooling for some part of the developer experience stack, open source it. Give it to the community. And that's definitely a great way for an organization to be contributing. And if you have, in terms of the individual developers, these people are often just super fascinated by the technology, so give them a little bit of free reign. If they want to begin working on clients, 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 project manager on an open source project is often simultaneously the developer. And the best thing that they can do is really like create a strong ethos of standards around what they're doing. Project 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 some version of project management to it, there's probably an 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 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 bounty challenge? Yes. I'm a huge fan of Gitcoin. I think that they're making a really really great impact kind of coupling these bounty programs that we'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 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 to use some sort of bounty program know that you need to be very proactive. You don't need to manage these people but 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. Contribute to open source.