4 ms·

“One of the fears from management was that a big company like Google could take our code and build a competing service.” Google, or any other respectable compa

“One of the fears from management was that a big company like Google could take our code and build a competing service.” Google, or any other respectable company, would not touch source code without a permissive license with a ten foot pole, least of all if it was retrieved as a result of improper access.

cloogshicer 6y ago
Agreed, I think that argument back then was just bad.
jjeaff 6y ago
What determines if a company is respected or not? Is Uber a respected company?
- username90 6y ago
  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.
deepsun 6y ago
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.
- tester34 6y ago
  >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?
  - deepsun 6y ago
    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.
  - notacoward 6y ago
    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.
pavel_lishin 6y ago
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.
- mynegation 6y ago
  True, but the premise of the article and my comment revolves around taking or seeing the code.

cloogshicer 6y ago

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

jjeaff 6y ago

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

username90 6y ago
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.

deepsun 6y ago

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.

tester34 6y ago
>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?
- deepsun 6y ago
  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.
- notacoward 6y ago
  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.

pavel_lishin 6y ago

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.

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