"- Do you have zero external dependencies on 3rd party library not own by Google? These must still be managed anyway? How do you deal with project X is not read

"- Do you have zero external dependencies on 3rd party library not own by Google? These must still be managed anyway? How do you deal with project X is not ready to move to external library version N but project Y needs version N? " I own third party policy, so i can answer this. I'll stick to public info. There are thousands of 3rd party libraries. The rules of the shared codebase is "third party libraries are not free headcount". You choose whether you use them or not (implicitly or explicitly). If you add a third party library, you get to maintain it, and stay within the support horizon of upstream. If you choose to use one, you get to stay up to date with the upgrades others make. If you need features not in the current version, you get to upgrade the library (and work with teams, who are not allowed to block you). This is pretty much the only way to make it all work in practice (i'm aware of how it sounds. In practice, even upgrading stuff literally every google target depensd on takes a week. It's only stuff where folks let it go for 6 years [we now have better detection of out-of-date code] that become a problem to upgrade). If you don't like it, don't use third party code. Note that these rules make it just like any other code, because your problem is not specific to third party code. Note that binary versioning, etc, is pretty much always a complete disaster in practice on a large scale "the magic mono-repo now means merging a fix is harder as it may depend on other unrelated changes all over teh repo?" This is rarely true in practice, because usually fixes are targeted.