I’ve been thinking a lot about Zcash governance and would like to share my big idea.
Let’s put all code related to Zcash into a polyglot monorepo with a single trunk
I’m a monorepo enthusiast. I love monorepos. I can’t stand switching context between repos and I hate wasting time managing | dependencies and releases across multiple repos.
For a basic primer about why a project would choose to keep all of their code in a single repository, I invite you to read Google’s wonderful article in the ACM from 2016 (my happy place):
There is also a nice talk that is worth watching Why Google Stores Billions of Lines of Code in a Single Repository - YouTube
Some advantages in short:
- Easy to discover code, find canonical versions
- Simplified dependency management!!
- Atomic changes, large-scale refactoring
- Easy to share code and collaborate
- Flexible ownership defined in the repo
- Developer ergonomics, standardized workflows and dev envs
- More eyes, more reviewers, more knowledge shared
- Value tangibly accumulated and distilled
- Code can be more modular because the overhead of repo boundaries is removed (just create a new directory/file!)
- Possibility to do integration tests across multiple projects - changes to dependencies can trigger integration tests in their dependents
We focus initially on Rust, TypeScript, Python and also documentation and official websites. We bring repos together into one repo (zecosystem - zecOS - Zecosys ), packages are separated by language/build system and/or by project/team/ownership. Merge rules are setup so PRs can only be merged with adequate acceptance by the owning team - eg, zebra requires approval from a ZF member and zcash requires approval from ECC. Whatever rules there currently are can be replicated by using directories instead of repos. Using CODEOWNERS and teams could be more transparent than the current fairly opaque ownership of the ECC and ZF repos (1). Rules can also be added so that downstream integration tests must pass before a merge is allowed.
Individual packages can be published out of the monorepo to the various package managers for people not fortunate to be working in the Zcash monorepo.
Reususable react components for zecpages, free2z, etc could be at
ts/react, python libraries could be published out of a top-level
py/ directory. All of the zips and books could be in the same repo and the boilerplate and build systems for docs wouldn’t have to pasted from repo to repo.
We could utilize a build system such as bazel to maintain explicit dependency graphs.
ZF has 47 repositories on GitHub:
zcash (ECC?) has 36:
ECC and ZF produce a lot of code in a lot of repos. There is even an additional repo that appears to be used to figure out the cross-repo dependencies.
Is the canonical version of this repo the one under the zcash org, zcash/developers or the one under ZcashFoundation org, ZcashFoundation/developers? Many if not most of the repos in
zcash are forked into the other github org. It’s sometimes hard to figure out which version is source of truth. Keeping track of all of the dependencies between different repos seems to be a chore in itself. Merging between individual forks and juggling all the versions is work that can be essentially removed in a single trunk.
I’m sure someone out there feels strongly that combining these repos is a bad idea or impossible. I’d like to hear those arguments. I can tell you that it is not impossible technically. Some (or even most) developers at ECC and ZF will have plenty of reasons why they like many repos and many folks will probably have a knee-jerk reaction that it’s impossible because of reasons like “ECC controls zcashd and ZF controls zebrad”. But, I ask if this is a real argument against a monorepo and if things need to be the way they are. Why is the separation considered necessary or desirable? Use your imagination and consider what could be possible.
We can talk about decentralization all we want. But, the truth is that the permissions to the canonical repos, the dependency graph and the trust placed in those who are allowed to merge and release is a huge (and probably underrated) part of what governance really is in practice. In a monorepo, these arrangements could be more transparent - encoded in the IAM and merge rules on the single
main branch. I feel like right now we have a lot of the downside of centralization but are missing out on the possible benefits of centralization, while some of the efforts at decentralization might be uncharitably characterized as “decentralization theatre”.
There are probably important people who will start with a flat HELL NO and stick to it. But, think about it anyways. I sincerely believe that utilizing a monorepo could boost productivity by an order of magnitude by dispensing with unnecessary coordination between repos and allowing that effort to go into fruitful integration and knowledge sharing across the entire ecosystem.
Maybe this can just be food for thought and stimulate ideas about how we could radically change the Zcash governance and software ecosystem for the better. But, I could help work on this idea for real, if people are interested. It could possibly start out as two-way subtrees between the existing repos and the prospective monorepo. But, the real advantages would only start to accrue if significant contributors really wanted to commit to it.