Thanks for kickstarting this! Here are a few comments I had on the blog post.
It [the EF] manages a number of pieces of community infrastructure and employs / contracts several teams working on major software for Ethereum, from testing frameworks to the Geth client.
I think it would be worth including research in this.
Ethereum is a set of protocols, from the Ethereum Virtual Machine (EVM) that underlies the smart contract system and many core features, to the devp2p peer communications protocol, to the JSON-RPC middleware for getting data in and out of nodes.
It may be worth highlighting that some of these are specified in the Yellow Paper, but that others aren’t. One of my biggest realizations when starting to work on a client was the amount of things that are not part of the YP.
Open Source Collaboration
although money of them are paid by the EF as employees or contractors
many of the core norms of open source are no longer being taught, even to developers. I think we can do more here, and would love to work on onboarding more new developers to become valuable developers to the core Ethereum stack, as well as the emerging ETH2 stack to build our next generation of experts.
Agreed. We spend a lot of time thinking of the pool of developers currently building on Ethereum or other blockchains, but the reality is that the set of developers who haven’t contributed to this space is orders of magnitude larger and we don’t do much, as a community, to pull them in.
I think the EIPs process works quite well, and is only improving. More education, especially for technically proficient developers who can add value to the network, would still be better.
Do you have any idea what this could look like?
There is a movement that is just beginning to have dedicated maintainers and repositories for different parts of the Ethereum stack – the EVM, devp2p, the JSON-RPC interface, and so on. This means that even more collaborators can work together, even beyond the boundaries of Ethereum main-net, to improve and be interoperable.
I think splitting up various parts of Ethereum into smaller groups, like mentioned here, is probably the way to go if we want to keep iterating rapidly, reaching rough consensus, and not have Core Devs be a bottleneck. Aside from purely technical issues, you can imagine dealing with mining/staking rewards, UX, etc.
Core Devs Coordination
Having spoken with individual client teams, the feedback is that code implementation really doesn’t take a lot of time: forward progress is being limited by non-technical decisions making and roadmap arguments today .
Dan Finlay’s process flow diagram
It seems like there is a connection missing between the “Users, dapps, any address […] or dependencies” and “Clients implement hard fork patch” which explains a lot of the issues that have currently surfaced. For example, Geth & Parity have already implemented ProgPow (although perhaps not the latest spec). This does not imply it will be bundled into a release and made available to the public, namely because of the signalling that is happening by users and dapps at the moment.
One point of view is that “stakeholders should self organize”.
One risk is that we keep fragmenting the conversation to a degree where it is impossible for people to have a global picture of what “the community” is. Perhaps this is inevitable past a certain size, but we should push people towards existing tools vs. novelty.
I don’t think placing network governance “before” protocol standards or Core Devs makes sense.
+1. I think what we are mostly missing is a step from Core Devs saying “this is technically sound” to them saying “so let’s implement it in the next hard fork”. There should be some other group(s) in between those steps that try and answer the “is this what the majority of the community wants?” question, especially in the case of less-technical issues. Perhaps the best way to do this is to create a new category or sub-category along with Core. You could imagine Core-networking, Core-economics, Core-mining, etc. with different stakeholders representing each sub-category.