Two more reasons Google doesn't touch others code:

1. They have monorepo with custom build infra, which makes integrating any third_party code pretty hard.

2. In google career culture, one gets promoted for development of something new, not integrating existing proved solutions.

>They have monorepo with custom build infra, which makes integrating any third_party code pretty hard.

Why would it be significantly harder than creating new project?

Different company, maybe different problem, but importing code at Facebook was similarly difficult. The build issues were the least of it. More significant by far were the all-but mandatory requirements to integrate with the in-house deployment infrastructure, service discovery, background-task scheduling, metrics, logs, alerts, data structure libraries, RPC framework, etc. Your project already implemented some of those internally, or used open-source alternatives? Too bad. You could keep the core logic, but practically everything about how it connected to the rest of the world would have to be rewritten. Often, it just wasn't worth it, and a new "FB native" service reimplementing the same functionality was easier. If you didn't do it yourself, some other group would constantly be threatening to do it for you. It's hard to focus on code when you continually have to justify your project's very existence.

One problem I know -- different versions. They actually do have a small amount of third_party libs, but due to "diamond dependency" problem, they are accepting only only one single version of that dependency. And updating that dependency is a huge undertaking (even for small security bugfixes), so those libs are usually outdated.

Kinda similar to OS kernel organization: monolith vs. microkernel.

Is Google also out of engineers or something? I would imagine that the important thing about building a competing service isn't understanding the specific implementation, but seeing the value in what the service provides.

True, but the premise of the article and my comment revolves around taking or seeing the code.

Agreed, I think that argument back then was just bad.

What determines if a company is respected or not? Is Uber a respected company?

You can ask engineers that worked there about their processes. Google have extensive processes both for using external code and for engineers accessing user data. I worked for a while on a system that had some user data, and every single access was logged and reviewed to ensure that each data access was in response to a user filing an issue and only accessed the data needed to fix the users issue. That is a standard process implemented in all of Google.

Companies who doesn't have engineers talking about processes are therefore not trustworthy. Doesn't matter if it is due to them being too small to not have ex engineers, or them threatening their engineers into silence, or their engineers simply not caring about processes and therefore not talking. Never trust companies where only upper management makes statements about their processes.