The previous barriers worked because they were organically perfectly in line with a contributor's internal incentives. A contributor gains very little benefit from submitting a patch; the likelihood is infinitesimally small they'll ever get any career advancement, financial recompense, or even much community recognition for it. At most, it shifts the burden of maintaining the code they're contributing from themselves to the community / long-term maintainers. The real incentive for a contributor was making the patch, because they get to see the feature or fix they want made for the software. The previous barriers were in making the patch, and contributors would overcome that friction to gain the benefit of having the patch they want. Moving the barrier to merely submitting the patch after it has already been made will simply result in people not bothering, because there is very little incentivizing them to deal with the friction.
1) more reliance on systems to track reputation across projects. I'm sure Microsoft, in the form of GitHub, will love to sell you a partial fix to the same problems it so enthusiastically helped to create. But there are the familiar problems of surveillance, identity theft, office politics, and system-gaming, and it doesn't on its own offer an onramp for new players.
2) in-person coding tests at the same Pearson test centres where people take most of their Cisco (and accounting, and ...) exams today. Not as expensive or inconvenient as you might think, but not the cheapest and easiest, and it certainly has the same concerns re. surveillance and identity theft