Monorepos and the Fallacy of Scale
Whenever I hear smart and reasonable people argue well for both sides of an engineering issue, my experience is that it will turn out that we&#x27;re arguing the wrong question.  The perspective is wrong.  We can&#x27;t get past thinking in terms of our old terminology.<p>What we all <i>really</i> want is a VCS where repos can be combined and separated easily, or where one repo can gain the benefits of a monorepo without the drawbacks of one.<p>Another crazy tech prediction from me: just as DVCS killed off pre-DVCS practically overnight, the thing that will quickly kill off DVCS is a new type of VCS where you can trivially combine&#x2F;separate repos and sections of repos as needed.  You can assign, at the repo level, sub-repos to include in this one, get an atomic commit hash for the state of the whole thing, and where my VCS client doesn&#x27;t need to actually download every linked repo, but where tools are available to act like I have.<p>(This will also enable it to replace the 10 different syntaxes I&#x27;ve had to learn for one project to reference another, via some Dependencies list and its generated Dependencies.lock list.)<p>In a sense, we already have all of these features, in folders.  You can combine and separate them, you can make a local folder mimic a folder on a remote system, and access its content without needing to download it all ahead of time.  They just don&#x27;t have any VCS features baked in.  We&#x27;ve got {filesystems, network filesystems, and VCS}, and each of the three has some features the others would like!<p>I don&#x27;t have much money right now but I&#x27;d pay $1000 for a good solution to this.  I&#x27;d use it for my home directory, my backups, my media server, etc.