A response to the proposal for an independent Foundation for managing a community release of EOSIO software.

I started this originally intending it to be simple feedback, but as it got wordier I decided to make it a separate post. I also want to say that I wholeheartedly support the concept of a decentralized foundation for managing the codebase. I am also honored to have been initially invited to participate and I hope that I will be able to do so in whatever form is ultimately settled on.

Introduction

First, a little bit of information about me. I have been a contributor to the EOSIO/eos github repository for nearly a year. I have been working with Dan Larimer directly more or less full time. However, I am not a Block.One employee, I am employed by Object Computing, Inc. (OCI), a software engineering firm. OCI has a very long history supporting open source software in commercial contexts. (cf https://github.com/objectcomputing and https://objectcomputing.com) For Block.One, we have contributed a substantial portion of the EOSIO core software, my team eventually growing to six engineers. As contractors, we do intend to make use of the particular expertise we have acquired by seeking out other projects, including those initiated by block producers, in order to continue developing EOSIO related software. Neither OCI nor I are block producer candidates, nor investors in any.

Foundation Official Duties And Requirements

The documents presented thus far go to some length to describe who Officials are and are not. But I haven’t seen any descriptions of what they are expected to do. In https://steemit.com/eos/@cypherglass/introducing-the-eos-network-foundation in addition to not being block producers, officials are also expected to volunteer their time. This raises the question of just what is it these officials are expected to do. As I describe below, these roles are potentially very time consuming, requiring a high level of expertise. Either foundation officials need to be compensated or they need to be able to engage folks who will be responsible for testing and validating new contributions. I envision at least three tiers of code to be managed.

First there is the EOSIO codebase itself. It will continue to be maintained by Block.One, at least as long as Block.One 1 is a going concern and interested in maintaining their intellectual property. As the code is intended to be released under the terms of the MIT Open Source license, anyone is permitted to clone it, adapt it, and anything else, short of disavowing the original copyright holder’s claim. I believe this is what you mean in terms of "All EOSIO code" but it really isn't all. One possible scenario is that Block.One voluntarily cedes responsibility for all EOSIO code to the foundation and follows the same model as everyone else, contributing all changes to the foundation, then pulling from the foundation into their own EOSIO/eos repository. While possible, I find the likelihood rather remote.

Second, non-Block.One contributions to key EOSIO-developed plugins and library code as well as new contributed plugins. These plugins shape the core functionality of nodeos instances. These may be new tools for monitoring and managing the network, or extensions or replacements for existing functionality. These may be tools that facilitate operating non-EOS token based blockchains. This is the area that I thing is most sensitive and will be most difficult to manage. For instance, will the foundation maintain a testnet or multiple testnets in order to vet such contributions? Will the foundation have a plan to provide these changes back to B1 via pull requests? What if the foundation rejects a particular patch, but then Block.One accepts it and merges it into their codebase. Does this become canon, or will this be a forking change? The way plugins work today, they must be built into the nodeos executable, which must then be adopted by some or all block producers, and then rolled into production in a coordinated fashion.

Third, new or modified contract software. Contracts represent a different beast altogether. They run at a different scope than the plugins they are no less important. Since much of EOS blockchain behavior is contract based, what I said about plugins and libraries applies to contracts as well.

Cutting across these layers of software is dimension of ownership and repository placement. The current EOS workspace is divided into a collection of role-based directories, programs, libraries, plugins, contracts, etc. I believe there should be a shadow directory called contrib (or something else), holding its own programs, libraries, etc. My assumption is that software in the "contrib" directory may be more of "caveat emptor" class, meaning that it is not expected to be part of the canonical EOSIO code. But it should probably be part of whatever test suites the foundation maintainers perform.