There's a Windows monorepo, and a monorepo for chunks of Office, but even now that many teams are on Git they're still very much different repos with different build tools, different code search (maybe they fixed some of that in the last few years but none of my friends there have mentioned it if so), different coding standards, and more.

However, it's not surprising when you consider the massive breadth of software that Microsoft builds, as one of the oldest and largest software development orgs.

I suspect one factor for Microsoft is that many patches will be cross-cutting, and tooling with multiple repositories or even submodules remains poor.

The point you've made is a good one though, the idea of monorepos at small scale has come up a lot recently and I'm not sure the arguments for it are as compelling (I don't see many compelling arguments _against_ it either mind you). What I _have_ seen though is the pain large orgs go through going from multi-to-mono repos, I think Twitter did it recently and it was pretty painful.

My understanding of Google's monorepo is that search, mail, maps, etc. all live inside one repo.

On the surface, most people seem to think of a monorepo as a source control management system that exposes all source code as if it's a traditional filesystem accessed through a single point of entry. Multirepo, in contrast, seems to be about multiple points of entry.

But that's a superficial and uninteresting distinction. All the hard parts of managing code remain for both and, for a sufficiently large organization, you'll still need multiple dedicated teams to build tooling to make either work at scale. All the pros listed in the article need a team to make them work for either approach, and all the cons are a sign that you need a team to be make up for that deficiency for either approach.

Aesthetically a single point of entry appeals to me, in that it allows for a more consistent interface to code. But I'd go for good tooling above that in a heartbeat.

The thing I don't see discussed often enough, in all of the "monorepos are good/bad" debates, is that they require a certain discipline. When one commit can span multiple components, it's easy to add or ignore bad coupling between those components. That contributes to the rebuild treadmill for everyone, and is bad design in a bunch of other ways as well. IDEs make it worse, because they obscure the boundaries between components, but everyone ends up using an IDE because their predecessors made it very difficult to follow the flow of control across components otherwise. So you end up with one big ball of mud. With separate repos this is discouraged, because violating the rules of good design causes immediate pain. With a monorepo the pain must come in the form of stronger reviews, to discourage bad coupling even though it's easy. Unfortunately, the very same companies that have embraced monorepos have also abandoned separation of concerns as a design principle. :(

ETA: please read bunderbunder's comment (https://news.ycombinator.com/item?id=19796960) as well. It's an insightful take on some of the same issues.

The question is specifically about their usecase, since not everybody would hit the same bottlenecks as they did with git monorepos.

Iow, have they stopped and thought whether it's still worth it (eg how often do their engineers make use of the monorepo benefits like cross-project refactorings)?

However, this linked post makes a great point, those benefits are all 'scale' problems which 99.99% of orgs don't have. The corollary is I've seen how hard it is to go from from multi-repo -> monorepo when you reach the scale where you would see some benefit.

I also think that the tooling/UX doesn't publicly exist to solve the multi-repo problem with 100s-1000s of engineers working on 100s of repos. It becomes so hard to navigate, understand and grok and so much is buried in dark corners. My experience is that that tooling is less hard to build around monorepos (Google for example).

That very well may be, but I think we're at a point where the majority of developers started after git came out (since the industry experienced explosive growth just in the last few years). They kind of forget (or didn't know) that it's not that long ago we did monorepos because we HAD to. The tooling to do a system in multi-repos was just not there. It wasn't practical.

Companies like Microsoft, Google and Facebook predates the days where building your company on top of 3000 repos was practical, and they certainly were not going to convert everything if they could help it. Thus, they built an enormous amount of tooling to make it work. It certainly has benefits (and tradeoffs). With similarly advanced tooling to support you, multiple repos also has a lot of very nice properties and scale quite nicely.

To each their own.

This leaves companies like Google and Facebook that made a decision fairly early in their existence, set constraints, and then spent several hundreds engineer-years into developing their own infrastructure and tools to support that decision.

Does it work? Yes. Is it more efficient than what other companies of similar scale are doing? I don't believe anyone knows.

There are only a handful of companies the success of which compares to Meta or Alphabet, so statistics do not apply.

As a counter point, there is Apple which almost certainly doesn't use monorepo. Or Microsoft.

- Makes it easy to develop applications and libraries together in a single branch

- Similarly, makes it easy to make a breaking change to a library, then change all clients of said library, in a single branch

- And because of the above, makes it easy to keep all dependencies on internal libs at the latest version, which can greatly reduce all sorts of “dependency hell” issues

- Generally makes integration testing a bit easier

The downside is you have to invest a lot more time in tooling, keeping both local and CI builds fast. And even with that tooling, builds won’t be as fast as they trivially are with multi-repo. But if you do invest that time in tooling, you can generally get them fast enough, and then reap the other benefits for a very productive dev experience.

Have done both monorepo and multi-repo at different, decent sized companies. Both have their pros/cons.