The team notion doesn't scale. Open source software doesn't require teams or managers. They just have developers. Lots of them typically. Since they are not part of a team, they need to figure out how to work together. And they have to do that without the typical things you would have in a corporate setting (like a boss that can dictate and re-assign people).

That sounds nice and utopian. But of course a lot of OSS software is actually being developed by companies. Most open source that matters has corporate backing. So, the two models are not mutually exclusive. Many large corporations have to figure out ways to scale development. And often they have to work with other companies or even rivals on some stuff. When you have hundreds of thousands of employees, hundreds/thousands of different software packages and components with hundreds/thousands of people involved each, things get very complicated.

A lot of successful organizations emulate a lot of what happens in large OSS projects. Not surprising, because many large OSS projects take contributions from those same organizations. So you have a large intersection of OSS developers that also are part of a large company.

Regardless, any sufficiently large software will just have lots of people working on it. Many more than fit in a traditional team. So, you need coordination mechanisms. The persons that release and integrate software have a lot of power. They get to gate keep what goes into the software. In the OSS world, git repositories are read only for most developers. You don't push changes into them, you ask for your changes to be pulled into them. Politely. And then you work with whomever is deciding about whether to do that to ensure the change happens. It's a good model. If you don't like it you are welcome to fork and create your own release.

It's how Linus Torvalds can impose deadlines on releasing a new kernel while working with thousands of people. It's brutally simple: provide your patches before the merge window closes. It's your problem if you don't make that deadline.

That's not the only way but a lot of large projects use the calendar to coordinate and release regularly as clockwork. And many companies seem to do the same. People simply self organize around that. You can't have stability if a lot of people are running around with their hair on fire around every deadline. So, a lot of the self organization relates to vetting and rejecting bad changes before they become a problem. You push the problems back to the source of creation and wait for things to be sorted out there. And then you simply bundle things up and ship them.

The rest is just Darwinism. Bad developers/teams won't get their changes in and will eventually lose their funding (and motivation). And better ones will get more of their changes in. It requires collaborating with other stakeholders, it requires effective communication, and it requires some skill.