What's Holding Monorepos Back?

Monorepos have a U-shaped utility function – great for small and large projects, difficult for mid-sized ones. But there aren't many good monorepo frameworks out in the world. Lerna is deprecated, and even new upstarts like Turborepo are getting absorbed (i.e., acquired) into other companies (Vercel). Likewise, centralized version control tools like Perforce and large-scale build tooling (buck, bazel, pants) have struggled with adoption.

As someone who continues to manage projects in a monorepo format, I often ask: why isn't better tooling available? Some hypotheses.

• Current monorepo tooling built at Google, Twitter, Microsoft, Facebook, etc., is too specific to each company's infrastructure and organizational structure. On the flip side, this suggests a high level of vendor lock-in for potential builders.

• The bottoms-up go-to-market motion does not work for monorepos. The enterprise product isn't simply a managed service; the freemium isn't just a less-featureful enterprise product.

• The network effects of git/GitHub are too significant at this point. Version control may be path-dependent and needs considerable activation energy to change. What comes after git?

• Monorepos (as conceived today) need too much additional tooling – build tools, language support, and CI/CD pipeline design. Building a complete DevOps platform from the ground up is difficult.

• The opportunity has passed for monorepos as a product. Airbnb, Uber, and Lyft each built out a machine learning platform. However, as developers left those companies to start companies around them, they have found it hard to sell to other companies – large ones already have a platform, and small ones don't have that pain point. Monorepo tooling may be the same.

• Monorepos are closely tied to package manager design. Package managers have significant network effects and terrible economics.