> I wonder if this'll lead to software engineers in big companies having more restricted access to code?

I don't think that Twitch has closed source code because they want to keep code private. It's probably more a matter of don't want to show commit message in case there are some bad words inside it. And don't want to show the world in case their source code look bad.

Twitch without its code source can't work yeah, but imagine if all the commits of Twitch were public I doubt it would change anything for them.

That would be nice if their was a mental change about source code and that it is fine to show it even if it looks shit.

You don't think the largest streaming platform on the planet wants to keep their intellectual property a secret? This isn't about being embarrassed over some comments, it's about completely revealing the algorithms that move streams to the promoted views, limitations of their filtering systems, the time it takes for someone to count as a 'viewer'... there are many pieces that are no longer secret and can now be manipulated by people trying to promote content or game the recommendation system or bypass filtering.

There is also the issue of security. I'm sure people will be combing through the source code to find anything they can exploit, even if it's a simple XSS attack. It could either be sold/used for malicious actions or submitted to the bug bounty program for the reward money.

Doubt they care too much about bad words in commit messages, what they should worry about is if they've ever checked in passwords/secrets/private keys and not re-written the git history

More things to keep an eye out for;

Snippets of open source code.

Commit messages that imply anti-competitive behaviour ("Committing a change to the API to lockout competitor XYZ").

Commit messages that imply code theft ("Using a method that we used at my previous company").

etc.

Sometimes things that look sketchy might be innocent but will still cause nightmares for twitch since they'll now have to play defensively as people call into question anything that ever went into the repo.

Of course they want to keep their source code private, like most software companies do. They consider it their "secret sauce", their prized IP.

Dozens? The 4chan post said "almost 6,000 internal Git repositories". We don't use git at work (TFS, yay), and we definitely aren't on their scale, but that seems high to me. Do they have a repo for every class? Is this normal?

If they use the common github approach of one fork per contributor, 6,000 repos accumulate quickly.

I've never worked in this way (when I've been part of the org), is it that common? What are the benefits of making everyone fork repos vs branching off the original repo?

It's common in general open source projects where you might want to send a patch for something that you don't have commit priveleges too, but I've never seen that used in enterprises as they have central auth / groups with the users required to work on the code.

I don't think that's a common workflow within companies. In every org I have worked at, forking is explicitly disabled

I worked at a large gaming company and that was definitely the collaboration model.

Before per-branch controls, the only way to disable write access (while maintaining read access, pull-request privs, etc) to a repository's blessed branches was forks.

You don't have 500000 garbage leftover branches on the main repo.

TFS converting to Git/Azure DevOps here. Be the change you want to see in the world! There's a chance that some of the people in your org that don't use TFS could use the organizational tools built into GitHub/GitLab/BitBucket/DevOps. If you get enough teams on board with that platform that also happens to use Git, then you can make that push to IT!

My company has way more than 6,000 devs and each dev creates a git repo as part of our onboarding process and uploads it to our centralized git tool (you create and push a mostly empty test repo as part of the basic training). Just from that, I'd imagine my company has tens of thousands of git repos, although a lot of them probably only have a single file or some random throwaway code.

The number of git repos might look big but without knowing more, the content of most of those repos could be a complete nothingburger. Number of git repos is pretty meaningless metric, IMO.

Note it doesn't say unique git repositories. It could just mean each employee's fork is included in that count, which would inflate the number like that.

Could include dependencies and forks of other public repos.

It s already the case and actually a big fight we re having (company of 70k employees spread everywhere) because we cant reverse engineer our upstream and downstream systems and it leads to huge bottlenecks trying to understand them when issues arise, as we need other teams etc.

Many of those companies still have a few (not always skilled) IT people with access to everything! And they sometimes make it easy for themselves by putting themselves in 2FA exception groups etc.

Will depend on company back when I worked for British Telecom, some team leaders with wide access to code & data on some projects had to go through Developed Vetting (TS clearance).

Back in the mid 90's there was a issue in Scotland when a well known journalist got a job in a call center and looked up the private telephone numbers for the Queen.