Design by committee is avoided by using designs of someone else.
I think parent's complaint is that Debian's model has failed to produce good solutions of its own, and while that isn't necessarily a requirement, it does speak to potential limitations of the model
If a Debian developer, or a group of Debian developers, sets out to solve some problem that isn't Debian-specific, the result is (quite correctly) seen as a new independent free-software project rather than a Debian project.
For example, as I understand it the reproducible builds project (now reproducible-builds.org) started out inside Debian, then became a thing of its own.
Yet there's no obvious way for people to realize to what extent Debian influences other projects and companies.
The parent compared a group of volunteers with the largest open-source company in the world, which is a part S&P 500. No other Linux distribution has a comparable amount of resources. Even Canonical is following the RedHat's lead (systemd, Wayland, PulseAudio).
Debian isn't more dependent on RedHat than any other Linux distribution is. It has nothing to do with the governance model, but rather with the fact, that multiple open-source solutions created by RedHat employees and firstly released in Fedora have won as currently the best.
The power and flexibility of Linux comes with the cost of a much lower floor for stability than proprietary operating systems. You can make a rock solid system using Linux, but that requires nontrivial effort and knowledge. I have yet to see an issue on my personal Windows and macOS machines that approached e.g. package management hell on Linux, in terms of complexity and frustration.
For examples of what open source projects look like when they have the backing and resources of large companies, look at LLVM versus GCC, BoringSSL versus OpenSSL and CentOS versus Ubuntu. "Better" would be too broad a description, but if you qualify it to the narrow scope of stability, then yeah I think proprietary resources generally come out ahead. I also don't think that is a controversial observation.
> In terms of out of the box stability and support?
How many devices have you used that came with Linux "out of the box?"
> package management hell on Linux
This is actually amusing to me. Windows has had this problem for a long time, they call it DLL Hell. Their solution was to duplicate everything and also to have multiple libcs that are incompatible with each other. Developers seem to forget this exists until they actually try to ship something on Windows. Nowadays, companies will just ship all of their dependencies they need.
Reasonably, developers are reticent to do this on open-source platforms, but this is what results in package friction. Semantic versioning would also fix this, but it's unrealistic to think we could get the tens of thousands of packages in a distribution to follow this. I personally don't think Snap or Flatpack is the answer here either, but Nix is.
Sidenote, I'm curious how you got into "package hell." I generally think things from outside the distro-provided stuff should be installed into /opt. Would you install things into System32 on Windows? My guess is that you either added an additional repo, or you installed a packaged generated by some open source code outside of any repos.
I was merely poking holes on parent's theory that more paid engineers and a bigger market cap, somehow justify better technical decisions. That's a dubious thing to say and if extend the logic to the OS level it should be apparent.
 I use Windows, Mac OS, Linux (and Android, iOS) all the time, and honestly they all get the job done, but all suck in particular and annoyingly unique ways. So I don't really agree with you either.
Support, maybe, if you equate support to "You bought a corporate license so you're entitled to talk to a human being with something more than a script and a mandate to act as a meat-shield."
Stability? That's a term with two different definitions: Doesn't crash, and stays the same over time, with no "breaking changes" even to the UI. Windows... kinda got better at the first, over time, and actively isn't interested in the second, given how much change its UIs have gone through. Remember how Windows 95 worked and acted? Want to replicate that on Windows 10? Remember COMMAND.COM? Is PowerShell a drop-in replacement? I'm not saying COMMAND.COM is better, I'm just saying your old batch files won't run if you only have PowerShell, innit? Ditto COM versus .Net versus... whatever they'll have in five years.
Meanwhile, I've been running WindowMaker on Linux with zsh for over a decade now.
I meant that the logic fault should be apparent even for a free software advocate, that more resources and paid programmers do not necessary mean better solutions.
So the excuse that red hat has more resources therefore a better process than Debian should not really mean anything for someone I suspect is a free software advocate (the GP)
I think this is the first time I've heard someone critique a model for encouraging anti-NIH syndrome.
That's endemic to programming and the fields around it, even in closed source. I don't think it's a problem of open source, though open source might enable it in a few ways.
Debian must be producing very good results, and doing so consistently. Otherwise Debian wouldn't be either the most successful linux distro or the distro that is forked by the vast majority of leading distros.
But that's exactly what Red Hat has done in a lot of situations. The main example I can think of is systemd. It was built to solve problems that really only appear on enterprise production systems, sadly it got adopted across the board for systems outside of that niche. Essentially it's taken what was a working system (sysV init and friends are very, very simple to configure for 90% of the desktop configurations) and replaced it with something that somehow needs continual firefighting.
Back to the original point: Not only has systemd reinvented sysvinit, but at this point systemd has reinvented from scratch:
* The UEFI bootloader
* syslog daemon
* A Calendar / cron
* A text editor
* nice(1) 
* sudo(1) 
This is one of the standard parts of service management, and service management toolsets all have to do it, either employing nice or their own mechanisms. Gerrit Pape's toolset does it with the -n option to chpst, for example.
Ironically given the subject of Debian, one can look to the Debian package archive (or indeed the FreeBSD or NetBSD ports tree and some others) to see lots of actual reinventions of a text editor.
Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.
> Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.
My response to both of these are, can you point out any of them that are part of a monolithic system that replaces the traditional PID 0?
Or are you talking about people reinventing small parts of the general system? Yes. UNIX allows people to swap out software for other software. In the original use-cases though, the editor(1), cron(1), and nice(1) were at no point conjoined with the boot menu system, or PID 0.
Indeed, there is a fundamental choice between someone building a replacement for one small part of the general system, to make their life easier, and building a replacement for the entire init system.
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...
Even the feminism angle is relevant here, because more often than not women are made worse off in these laissez-faire arrangements.
One of the proposals was for a elected "technical lead" (or Gracious Umpire Influencing Decisions Officer (GUIDO)) with 4.5-year terms, and came sixth in the vote about options: https://www.python.org/dev/peps/pep-8010/#the-role-of-the-gu...
I believe an open-source project is best run as some form of an oligarchy, but with democratic processes for gaining ideas and feedback.
In my opinion, this kind of shift towards complicated government structures is the end of high efficiency in open-source. The thing that makes many open-source projects so great, other than being open, is that they don’t have a burdensome corporate structure breathing down their necks; so they’re able to turn and burn on projects; they don’t fall prey to sunk cost fallacy as often (thinking back to the efforts to integrate Django Channels that were sidelined, or back further to the efforts at GSOC by some developer, 2 years in a row, to add composite key support, which were also sidelined - futile like this turn into disastrous sunk cost slow train wrecks in corporations, but instead teach us what it is that we don’t want in open-source projects); and only the carrot is in play, for the most part, no stick.
Hitch-Hiker's Guide To The Galaxy, Fit The Twelfth
Did Guido rage quit because of this?
For such an important project unfortunately I think a certain amount of bureaucracy and paperwork is not only unavoidable but actually necessary and important.
I think it's curious that commenters (this is not aimed at you specifically) don't dare to even indirectly praise bureaucracy without couching it with words like "unfortunately", because there's nothing unfortunate about having a well-described and transparent decision-making process. Python has had bureaucracy for decades, e.g. the entire PEP process, so it's too late for us to be wringing our hands about tainting the Python project with the bogeyman of government.
I'm far from a libertarian so I completely understand and accept why these rules and regulations are necessary but it's still annoying and somewhat inefficient from time to time. For the same reason I consider it unfortunate and annoying when I get a speeding ticket even though I understand why such things exist.
Rules are good when they apply to other people but they tend to suck when they apply to me, mainly because obviously I'm much more clever than my peers and specs and code reviews are for losers.
The reality is that languages are born with a single creator, and spend their adolescence growing under that creator's care, but achieve maturity once they can demonstrate that they can function without such a single point of failure as a BDFL.
Yes, eventually all of those graduated to a design-by-committee approach, but that happened much later. But yes, in that sense, Python is just following the path set by others.
C++ wasn't designed by Stroustrup alone. It's based on C's design.
Sure sometimes you have cleared leaders (see also Perl/Larry Wall) but having a larger group has benefits to see more edge cases (with the risk of committee issues)
So, all around 20 to 30 years ago.
— You will be the land, and the land will be you. If you fail, the land will perish. As you thrive, the land will blossom.
— But why?
— Because you are king!
King Arthur and Merlin, Excalibur (1981)
This, concisely, is the problem with kings.
Samuel told all the words of the Lord to the people who were asking him for a king.
He said, “This is what the king who will reign over you will claim as his rights: He will take your sons and make them serve with his chariots and horses, and they will run in front of his chariots.
Some he will assign to be commanders of thousands and commanders of fifties, and others to plow his ground and reap his harvest, and still others to make weapons of war and equipment for his chariots. He will take your daughters to be perfumers and cooks and bakers. He will take the best of your fields and vineyards and olive groves and give them to his attendants.
He will take a tenth of your grain and of your vintage and give it to his officials and attendants. Your male and female servants and the best of your cattle and donkeys he will take for his own use.
He will take a tenth of your flocks, and you yourselves will become his slaves. When that day comes, you will cry out for relief from the king you have chosen, but the Lord will not answer you in that day.”
But the people refused to listen to Samuel. “No!” they said. “We want a king over us. Then we will be like all the other nations, with a king to lead us and to go out before us and fight our battles.”
(1 Samuel 8)
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.
In America, you can only vote in primaries (that is, choose presidential and other candidates) if you are a registered voter of that party -- which means that it's also restricted to a subset of the public.
So I'm not sure I agree it is a mismatch to most democracies. Obviously there is a difference, but it's still clearly democratic in spirit (and actually matches how some real democracies work in some aspects).
I'm not particularly interested in arguing about what democracy "is" (we'll be here all day, and then some), but I think it's clear that this model is what democracy "isn't". And I'm not saying that's a bad thing (certainly different styles of governance are suitable for different contexts).
Obviously users will be impacted, but in such a tangential way that I would argue that it'd be more like how other countries are impacted by the decisions of a democratic country's leadership (and you wouldn't argue that Canadians should have the right to vote in American presidential elections). Just like the Linux CoC, I don't understand why people who don't contribute to the project should be involved in how the project's development is run.
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.
> Correction - that's how organizations work when their goal is making members happy. If the organization has an external goal, like winning a war or putting a man on the Moon, it needs to be more authoritarian.
(EDIT: cousin_it's comment changed again while I was writing this, somewhat closer to the original. Anyway, probably just keep in mind that any now-nonsensical response may be to an earlier version.)
But there's a big gap between "Option A has worked better than Option B [Spolsky, anecdote]" and even "Option A is always better than Option B", much less "Option A maximises the desired outcome."
Maybe it can be as simple as a benevolent-dictator election. Or it can be as complex as direct democracy (voting on PEPs) - but then who can vote becomes the issue, etc.
Basically control > individual initiative but control + individual initiative >>> absolute control (see Stalinism).
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.
>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.
On some level I agree with him, as much as it's contrary to the self-organizing semi-anarchist hacker spirit.
Who? This person?  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 .
"The book describes the socio-political tactic of creating temporary spaces that elude formal structures of control. 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."
In particular his position is interesting in contrast to others in the anti-authoritarian Marxist tradition.
I hadn't heard of Hakim Bey or TAZ, so thanks for pointing that out to me.
You're free to fork your own python like language and get buy in as long as you do not infringe the trademarks. Or make experimental branches and proposals.
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.
Or does self organizing mean something different from what it says?
Chomsky on Zizek : 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.
You might say that he lacks rigor or prowess in his arguments, but those admit he's a philosopher. I can't see how you can deny he is a philosopher. Let's rephrase the essence of your argument: anyone who writes to entertain or repeatedly questions notions of common sense cannot possibly be a philosopher (despite large output and several research and teaching positions in and invitations to philosophy departments at universities around the world), if and only if a linguist says so and they have a lisp and some nervous tics.
I'd also suppose that none of the topics which Zizek addresses are philosophical ones: https://www.iep.utm.edu/zizek/
Take a saying of Zizek and route it through a robotic voice (to eliminate his accent and mannerisms). Do the same to the negation of same. Play the results to a random population. The genuine saying of Zizek will not statistically stand out as being any more valuable than its negation.
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.
On the other hand, several Communists (in fact, the ones Zizek is arguing against) very much argue for exactly what you propose: focus on small matters and diffused democracy to avoid centralisation of power. The fact of "real Communism" having been or not having been "tried" is irrelevant to the questions concerning how such a society, if it is possible, ought to be organised. Thought-terminating cliches don't make for critical analysis.
You need to see how things actually work out in practice. And in practice Swiss democracy works very well whereas most central bureaucracies are soul killers.
In case you do not know, Swiss have a central bureaucracy. Not everything, heck most things are not decided by direct vote.
Important things are though and the citizens can propose a referendum after the fact as well given enough buy in.
But that is also true of bureaucracies. Honesty, attention to details, voluntary respect for rules make bureaucratic systems semi-liveable and not a hellish kleptocracy.
Every idea suffers from implementation problems. Not every idea is worth implementing though.
The problem with this kind of direct democracy is the same as with all diplomacy - astroturfing, focus groups, demagoguery and unintended consequences.
Focus groups make diffuse votes matter less despite being more prevalent. (Overwhelming majority in some cases.) Astroturfing is a kind of diffuse bribery. Unintended consequences is most often when people are presented with a package deal and do not dig deeply enough to figure out results. Finally demagoguery is usually by presenting a palatable but highly inferior option or by going for short term bandaid solutions.
The latter two are less relevant to a programming language project.
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.
This only serves to express your view (or rather, ideology) that we're living in a post-ideological world in which battles are no longer fought over beliefs but only material access to resources. This is only valid as a pretty bad caricature of Marxism, in fact.
>to a land of total freedom from capital/tyranny (left & right respectively)
The left not only opposes capital but tyranny too. If you've read any leftist works after the year 1920 or so you'd know that most of them deal with various 'gross' ideas.
>because the problem was people all along.
No. The work in political philosophy isn't only to criticise our systems we currently have, it's to explain how these systems arise out of individuals and perpetuate themselves. Of course the problem was "people all along" - but people also have a habit of conjuring systems bigger than themselves. Societies change people but people also change society.
The very notion of utopia has been criticised on the left, in particularly of course in the light of the Soviet experiment. What you're saying seems to imply we must abandon (i) any and every plan towards a better society (ii) any superindividual critique of totality, because both are doomed in failure due to the human condition. This is known as the 'human nature' argument against social projects and it's not very convincing.
 "Modern bourgeois society with its relations of production, of exchange, and of property, a society that has conjured up such gigantic means of production and of exchange, is like the sorcerer, who is no longer able to control the powers of the nether world whom he has called up by his spells." (Karl Marx, The Communist Manifesto)
 "The materialist doctrine that men are products of circumstances and upbringing, and that, therefore, changed men are products of changed circumstances and changed upbringing, forgets that it is men who change circumstances and that the educator must himself be educated. Hence this doctrine is bound to divide society into two parts, one of which is superior to society. The coincidence of the changing of circumstances and of human activity or self-change [Selbstveränderung] can be conceived and rationally understood only as revolutionary practice." (Karl Marx, Theses on Feuerbach)
I said no such thing. I also note the use of ideology as a subtle dig, as if I’m some extremist.
> This is only valid as a pretty bad caricature of Marxism, in fact.
The idea that my post was anti-Marxist exists only in your own head.
> The left not only opposes capital but tyranny too.
I know this is probably shocking, but a one sentence summary wasn’t intended to be a complete explanation for an entire system of political thought.
> If you've read any leftist works after the year 1920
I’m not sure where accusing someone of being poorly read is an acceptable debate tactic, but it’s not one here. Stop.
> you'd know that most of them deal with various 'gross' ideas.
The hilarious thing is that I’m encouraging people to engage with these ideas, and you’re attacking me as if I’d said the exact opposite.
> What you're saying seems to imply we must abandon (i) any and every plan towards a better society (ii) any superindividual critique of totality, because both are doomed in failure due to the human condition. This is known as the 'human nature' argument against social projects and it's not very convincing.
What you imagined to be your grand coup de grâce is rather soiled by completely misunderstanding my original point.
At no point did I say that improvement is impossible, that’s an obvious and shoddy strawman of an argument. My point is that politics comes from humans, thus any attempt to completely eliminate politics is doomed to failure. This is an encouragement for people to engage with political systems and political theory in order to improve our existence.
I also didn't want to imply you're poorly read, or that you should be well read on something as arcane as 20th century leftist theory, I only wanted to bring your attention to the idea that the left doesn't shy away from grossness in any future society.
The question is never of eliminating politics in the most general sense, it's to eliminate current politics in a constantly revolutionary fashion. Communism is a political movement, for instance, and the very existence of the party shows that they don't want to get rid of politics - they only want to move away from bourgeois democracy which supports (and is supported by) capital. Not even the anarchists deny the role of politics. But the idea that politics is merely a disagreement about resource allocation is ideological (and this time I do mean it in a bad sense).
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.
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.
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.