There are no true monorepo companies

I like the suggestions about a more descriptive name, like "multi-project", that I believe describe the thing more clearly. This would probably also remove some of the confusion betweeen the words monorepo and monolith.

Also, I don't see anything bad with an organization having more than one "monorepo" for grouping a number of related projects - an example would be different monorepos for different programming languages. This would probably mean that the organization is a "polyrepo" one (or maybe multi-project).

The Polylith Architecture support these kind of scenarios: one monorepo for all code, or a number of multi-project repos within an organization. There's also tooling support for this architecture, currently for Clojure and Python.

I'm the maintainer of the Python tooling, that is a combination of two Poetry plugins - one with the name "multi-project plugin". Here's the docs for the Python tool: https://davidvujic.github.io/python-polylith-docs/

What I really like about having multiple repos is that it encourages bounded context and forces us to put at least a little thought into the interfaces between different systems.

When I have worked in large repos, I have frequently seen poor abstractions where too much code is reaching into other code without clearly defined interfaces that leads to projects that are really difficult to maintain.

To me, Monorepos are about a separation of concerns (or lack thereof). Something is a monorepo if/only if there is greater than one concern in the repo. (For example mobile + web, backend + frontend, service + server).

When I was at FB, I remember someone used the term polylith to describe our multiple monorepo situation... I suspect that's probably a pretty common situation for people that "have a monorepo"

This sounds kind of pedantic, considering Google is the most popularly cited monorepo. Curious to know why the author has this perspective