Python gets a new governance model (opens in new tab)

Design by committee is avoided by using designs of someone else.

If it did, a virtual BDFL would have been able to stop the whole systemd vote from happening, declare that systemd would be the default going forward, and require that some number of developers come forward to take maintainership of alternate init system if init decoupling were to be a requirement in Debian. And Debian depends on a human WoT anyway. So a reasonable amount of developers saying, "Ok, we'll make sure everything can work on multiple init systems going forward," would be enough. And if that turned out to be untenable, they could make a different decision down the road.

But that couldn't have happened because it would have gone against the democratic spirit of Debian.

Compare to what Linus did with the pull request for kdbus. He said he trusted his maintainer who did the request, but also pointed out the amount of work and problems that could come from maintaining it. Maintainers argued, but ultimately it was the maintainers who retained agency and who ultimately maintained a sense of trust among each other.

Now imagine if instead there had been a vote of Linux users/foundation members/whatever to decide whether to include kdbus. Linux would have bled developers regardless of the outcome. Because that model of governance would have given them less agency to make decisions about the direction of the project.

I don't think many people relish the idea of imposing such bureaucracy upon themselves and their fellow developers. However, when you have a sizeable organisation, there needs to be transparency and accountability so that the developers as a whole can see that proposed directions are properly discussed and agreed upon, without ideas being unfairly dismissed or accepted without due criticism. Hierarchies are intrinsic to the ordering of our society and our functioning as a species. They will crop up inevitably, so a formalising of this is a better alternative to an unaccountable hidden hierarchy which would come into being in its absence.

As for voting, voting prevents obvious domination of the decision making process by individuals, allowing all participants to have an equal and democratic say in decisions. “Democracy is the worst form of government, except for all the others”, as Churchill said. It's not perfect, but until we can do better, it's the least bad way of doing things.

This is why BDFLs are rare in projects. Like Tito and Yugoslavia, or the Kims in North Korea, it only works while the strong minded influence of the leader is tolerated by those who are subject to their whims. For a technical project, the leader must be consistently technically adept, and maintain the goodwill of the contributors, or be replaced or burnt out with exhaustion. Can you see an obvious replacement dictator for Guido, or Linus? Me neither. Bureaucracy allows an organisation to outlast an individual by providing a structure for the replacement of leadership over time.

I've served on Django's technical board -- its equivalent of the new Python "steering council" -- for several years. The technical board has the following responsibilities:

* Act as a final tiebreaker for any decision that the dev mailing list can't manage to make through normal discussion

* Review major proposals for changing Django or Django's processes (DEPs, our equivalent of Python's PEPs), with the ability to veto

* Review proposals to add new Django committers, with the ability to veto

The first category has never, as far as I can tell, come up, and for the other two the technical board has never vetoed a committer or a DEP. There also aren't many of them -- 24 in a bit over four years.

I'm trying to push through a significant change to how Django works, but it wouldn't do away with the technical board; instead it acknowledges that the in-practice way Django runs -- discussion on the dev mailing list, open to everyone, with a couple people whose job is to merge PRs -- is working well enough that we no longer need to give special privileges to a large group of committers.

Honestly, I think it comes down to the fact that democracy is definitely sexy. The idea that any individual could gain the power they want through based on public recognition, where the public has a say on who is in power, is very attractive (and is one of the reasons many governments are democratically elected -- because there would be an uprising otherwise). And obviously it's great for societies where the decisions can very much be a matter of life or death -- but for projects that are trying to get a very specific thing done you can end up in a death-by-bureaucracy system.

Also, democracy is one of the easiest ways of getting out of having to solve an issue -- just let the people decide. There were several completely different PEPs that outlined new governance models, and due to lack of consensus this model was adopted since it can be used to get any other model (and in the Preamble they state that this new governance model could be used to pick a different one).

EDIT: "The people" could be any subset of people -- not just the general public or users of software. Several democratic systems (Westminster-like and the American primary election system) work in the same manner -- where only a subset of people make decisions about the country or party.

Informal organizatios are not transparent.

Otherwise, every time there's a decision to be made, you will have to have arguments^Wdiscussion^Warguments not just about the substantive content of the decision, but about the process of making the decision too.

This goes double for the stuff like "votes of no confidence". If it comes to that point, the group is already in deep enough trouble as it is. The last thing you need is to add a debate about the means to handle the trouble on top of the discussion of the actual trouble.

You spell these things out in advance so that when questions arise in the course of the group making choices, the fundamental question of "how are we going to go about finding the answer to this question" is already settled.

>Žižek now believes that efficient bureaucracy is the necessary corollary of any successful future state. While often alluding to the utopian impulse that imagines a political community beyond “what is”—including Derrida’s “democracy of the future”—such imagining should not exceed the strictures imposed on the world by technological complexity, sprawling populations and megalopolises. In fact one should be able to take utilities and health services for granted. Freedom of choice should not have to extend to one’s electricity vendor and Internet provider, or even what hospital one wants to convalesce in.[0]

and,

>I think he agrees with Laclau and Mouffe, that every radical solution is temporary, 'lives in borrowed time'. This means that an 'organizational structure' must not become sedimented, but remain open. This probably sounds a bit abstract, but it matters, as it assumes the position opposite of e.g. Stalinism.[1]

On some level I agree with him, as much as it's contrary to the self-organizing semi-anarchist hacker spirit.

[0] https://criticaltheoryresearchnetwork.com/2017/08/10/bureauc...

[1] https://www.reddit.com/r/zizek/comments/6mmtpg/what_kind_of_...

I think the moment political theory is mentioned, the response is basically that politics are gross and we should do better than that. This appears to stem from the idea that politics and all the negative aspects of it stem from some location other than people haggling over limited resources. This thought process is both ridiculously naive and a highly ineffective way to go about running a community.

This thought process is not unique to engineering. You see it all the time in various utopian projects on both the left and the right. The idea that you can escape the grossness of political processes to a land of total freedom from capital/tyranny (left & right respectively) is extremely popular, and extremely silly. Time and time again we see these movements immediately recreate the problems they decry because the problem was people all along.

Yes it's boring, yes it's slow, yes it's bureaucratic, but it's realistic and pragmatic. Python will continue to grow if they can run this governance model well. They can become debian of the programming languages.

[0] https://discuss.python.org/t/python-governance-vote-december...

Not sure what do you expect, Mozilla model with an NGO, who can still be pushed by competition and wealth into irrelevancy?

Ask about RedHat and their push for dominance in both init system, package management, GUI and audio server, conquering even Debian and Arch in the end, making Gentoo less relevant, making BSD compatibility hard. Countered only somewhat by Android and its practices, Google's money and software market.

One advantage of doing things this way is that it makes it easy for people to step down when they've had enough.

It's a pretty low-traffic and low-turnover group in Django. I've done it four releases in a row, for example. When there's only one feature release in most years, it's not an issue at all to do a quick call for volunteers. In Django's case, often there's not a real need for an "election" since you only get as many volunteers as there are spots on the technical board.

Giving a moderately frequent way to change up less-than-stellar-but-not-malicious council members without a no-confidence vote is a Good Thing (TM).

Hey, there's people working hard on that, it's not just some accidental freebie ...

The system, however, does have positive feedback - the more you advertise, the more resources you have for advertising.

It applies equally well to any non-unanimous change, therefore it means nothing.