That is a feature not a bug! Discoverability of code helps improve code quality and makes things less fragile.

Discoverability decreases as LOC increase, so that's not true.

Yes, and an intern would be subject to a code review before pushing to master - no way would they have write access to the "master" repo.

Indeed the process of facebook code deployment is pretty complex:

https://www.facebook.com/publications/514128035341603/

And I assume they have extra requirements for interns to push code.

that is a fascinating article, thank you. i like the idea of 'push karma'.

You're welcome! I really liked the 'push karma' too.

I liked this idea too : "all engineers who contributed code must be available online during the push. The release system verifies this by contacting them automatically using a system of IRC bots; if an engineer is unavailable (at least for daily pushes), his or her commit will be reverted."

That way, they are be able to react very quickly in case of a problem.

But this isn't a magic bullet...a commit can't always be reverted without conflicts, and even if reverted there's no guarantee that it leaves the codebase in a correct state. (Guess I should read the article you're talking about.)

Yes, but the new intern would be able to read all the source and "secret sauces".

I doubt that an intern on Google would've access to the search codebase. I'd wager that only a handful of trusted employees have access to that codebase.

All Google code is stored in one master repository, for all products. An intern can look at the search code.

Not so. Search is specifically sequestered.

If you don't trust your employees why did you hire them? Besides, the source code isn't where FB's money is at, that would be their users.

> If you don't trust your employees why did you hire them?

On a small company, I agree. But on FB they're around 5k people. Let's say they have 3k engineers, that's a awful lot of people they're trusting with their source code

Google is also one source tree I think.

You are correct for the search codebase - it is separate from the main tree, as is a lot of the core ad placement code. If you aren't working on those projects, you don't have access.

So it is like the Coca Cola recipe? Only two people allowed to know it and not allowed to get the same flight? Yet everyone else able to mix and serve the syrup?

It should be possible to restrict each employee's access to specific parts of the repository. However, I can't really see Facebook doing that.

Everyone having access to everything must be worth the security trade-off. On the other hand, I suppose it's debatable whether it would be a trade-off at all.

I wonder, if this is the way a majority of big businesses do things, how come we don't see more leaks of entire codebases? It'd be trivial to put something up on TPB and just share all the code, but I don't see things like that happening. I also doubt that every single employee with access to the code has the moral standards not to do this. There must be something else keeping them from doing it.

I'd wager they are more likely to get leaked to the black market for money where someone will keep it a secret in the hopes of finding some 0 days.

I'd say the combination of some moral standards, the fear of getting caught and - first of all - little incentive to leak should be sufficient, no?

> It should be possible to restrict each employee's access to specific parts of the repository.

Not with git. The Hash chain mechanism requires the entire repo to generate valid chains, so it's all or nothing.

>Everyone having access to everything must be worth the security trade-off.

I would find this extremely hard to believe, especially at Facebook. At any software company, your code base is what defines you as a company; there is no way they'd let the good stuff sneak out like that.

Lets say you managed to sneak out the code from facebook. You take the logo, draw a red cross over it and scribble "ProAmbook" below. You push it live.

Now what? How do you get users? "We are just like facebook - only your friends aren't here" probably wouldn't get users excited.

And if you somehow DID manage to get users, don't you think there are "watermarks" in the code, that they could detect and sue you to death with?

They have anti-spam heuristics, graph heuristics, models on how to serve the best ad for each user, tons on bugs that can be only discovered by reading the source, etc.

Having only the code wouldn't be enough. You need to also replicate comparable maintenance staff & data center capability. Even then you'll just have a clone of the tech, but nobody will actually use your service. There's so much more that makes facebook what it is. I think they may even be able to open source their tech with a net positive effect.

I think a lot of their value comes in the data the collect about users and how they use it to sell ads to vendors. That source code would be worth a lot. I'm not speaking about replicating a Facebook on your own servers, I agree there it would be futile. But how they run their business can probably be derived from their source code.

Facebook has never been defined by its code. They have had source leak before and no one has cared--it's PHP (heavily customized at that) and not of much worth outside of casual curiosity. The trick is to get a billion plus people to give you the details of your life every day.

> The trick is to get a billion plus people to give you the details of your life every day.

How they capture this data and use it would also be in their source code, no? This is absolutely where Facebook gets its worth. I would assume this is what they would want to keep in a limited exposure set? I might be wrong, but this is why they hire the best engineers out there.