Design by committee is avoided by using designs of someone else.
Citation needed - that's simply not true.
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.
My point was that a "virtual BDFL" works better than the "design by committee", not that it works better than a real BDFL. It doesn't. I completely agree with you.
It has been discussed on HN multiple times: https://hn.algolia.com/?query=THE%20TYRANNY%20of%20STRUCTURE...
The opposite of bureaucracy isn't efficiency. It's corruption.
I don't know python well, so this all might work very well for them. But if, for instance, there was a very core developer or two, then no amount of structure will take away from their sway. If a major point of contention arose between the "paper" structure and the core developers, there will be a problem.
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.
I don't think that's always a good thing. If the organization has some urgent goal, like winning a war or putting a man on the Moon, some dictatorship is needed to keep bureaucracy in check. But when there's no more urgent goal than well-being of the organization's members, that's when dictatorship fades and the subcommittees begin to sprout.
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_...
Who? This person? [1] I'm at a loss. Could you explain what this has to do with this topic?
From what I understand it seems to be in agreement with the principles of Hakim Bey's Temporary Autonomous Zone [2].
"The book describes the socio-political tactic of creating temporary spaces that elude formal structures of control.[1] The essay uses various examples from history and philosophy, all of which suggest that the best way to create a non-hierarchical system of social relationships is to concentrate on the present and on releasing one's own mind from the controlling mechanisms that have been imposed on it.
In the formation of a TAZ, Bey argues, information becomes a key tool that sneaks into the cracks of formal procedures. A new territory of the moment is created that is on the boundary line of established regions. Any attempt at permanence that goes beyond the moment deteriorates to a structured system that inevitably stifles individual creativity. It is this chance at creativity that is real empowerment."
There is a difference and fine line between freedom of choice and being overwhelmed by options, especially irrelevant ones, even more so if all competitors are essentially fake and owned by the same company. Looking at Unilever and Nestle here for example.
Chomsky on Zizek [1]: Posturing. There's no theory in any of this stuff. Try to find in all [Zizek's work] some principles from which you can deduce...empirically testable propositions...beyond the level of something you can explain in 5 minutes to a 12-year old.
I quite like the Swiss model of democracy. Taleb argues that the focus on small matters and diffused democracy avoids centralization of power and provides a lot of their famous stability.
At the end of the day, I suppose this is simply yet another form of NIH
The theory of clubs and voluntary associations is well-studied in economics, law, political science, sociology, organisational theory ...
It's also almost exclusively used by other software foundations like the Debian SF so if anything this just proves my point that programmers by and large are not equipped and do not invest time to become equipped for discussing governance.
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.
I have to confess, I was very envy of Python. I wish Ruby had something similar to PEPs, many more suggestions, Matz making more decisions, Ruby entering more Domains. Ruby could have grown itself 5x and its usage will still possibly be counted as a niche language. MJIT!
That was until past few months.
It wasn't until Guido Steps down from being BDFL for Python, before the simplest question pops, What happens to Ruby if Matz suddenly step down because of a similar "lively" discussions on features? And now looking at this "governance model", the bureaucratic nature of it. Makes me appreciate a lot more of how Ruby is being handled.
This isn't to say the Python model is wrong, far form it. Java have a similar model and it is brilliant.
During one of the recent talks Matz said he is already starting to work on Ruby 4.0, which is not about features or speed, but testing a model of future Ruby without Matz when he retire. He is enjoying life, and he is still having fun, but it will come a day when he retires, so he is preparing for it. Despite their syntax being somewhat similar, Ruby's values and culture that makes it a lot different to Python.
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.
New York times:
"By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors or by exploiting security flaws, according to the documents."
Later when the code of conduct was added to the Linux project, Theo Tso was attacked with bullshit accusations on the first day...
Won‘t that get old really soon?
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.
"New council", in this circumstance, is shorthand for "holding an election for the council".
Yes, they can, and likely will be in many cases.
- https://www.python.org/dev/peps/pep-8010/ - https://www.python.org/dev/peps/pep-8012/ - https://www.python.org/dev/peps/pep-8016/
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).
The merits of singular vision, unity of design, counter-majoritarian good judgment, predictability, and decisiveness should really get more credit in these contexts. As should the downsides of bureaucracy and democratic decision making: infighting, politics (the sacrifice of sincerity for popularity), gridlock, disunity of design, etc.
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.
