Becoming an OSS project maintainer is about trust

To gain commit rights on CPython, a pre-existing core developer nominates your for commit rights to python-committers. That nominator lays out roughly why you should be given commit rights, and then promises to watch your commits for a little while to help you with any sharp edges you might run into while doing your initial commits. Other core developers lay in with either support or opposition. Typically there is a few voices of support and no opposition (although opposition has occurred). In general, though, as long as no one objects and at least a couple of other people support the nomination then you get commit rights.

So why don't we give out commit rights more often? The Python development team is chronically understaffed so I get this question on occasion. And the answer is it's about trust. When you gain commit privileges you have the ability to change the code of a programming language that millions of people use to write software (let alone the billions of people who use some software or service that relies on CPython). At some point, core developers will commit code that someone doesn't double-check and it can lead to bugs, bad design, etc., and so there's a certain level of trust involved to allow someone to commit code to CPython without supervision. In other words you're being given the keys to the proverbial castle and so we need to trust that you won't trust the place when no one is looking.

This dependency on trust has two interesting side-effects. One is that you could argue CPython is not a pure meritocracy as we don't care if you have the technical skills to work on all parts of CPython, just that you can constructively contribute on some part and that we can trust you to know when (not) to do something you don't have the skill set to work on. In other words we're perfectly happy giving people commit rights to people who don't know how to write C code as long as the person also realizes that fact and thus doesn't try to touch the C code (until they are ready to). This is why our work to try and diversity the Python development team doesn't focus on teaching people C and how the interpreter works, but instead how to contribute effectively to CPython with the understanding that people will just leave alone anything they don't feel comfortable working with.

The other side-effect of focusing on trust is that we accept individual contributors but not companies as their own contributing entity. While we have never actually had a company come forward and say, "we want to contribute as a company", I have seen it in other projects. The issue with this (gracious) offer is it isn't the company making the commit but the individual contributor. If we were to trust a nebulous company then we wouldn't be able to to control that the person making commits on behalf of the corporation know what they are actually doing. This is why when companies ask me how they can best contribute to a project I say they need to let individual employees make contributions from their work accounts. That lets the project develop trust with the individual while giving the company credit for letting their people give back.