Councils, committees, multiple obtuse voting systems, governance documents, 'courts' of appeal... Why are they so keen to construct such a grim bureaucracy for themselves?
The alternative to explicit rules, hierarchies and power structures usually isn't harmonious self-organization; it is unspoken rules, implicit hierarchies and hidden power structures.
Also of course very relevant in the tech world. Superficially egalitarian and non-hierarchical, but in reality dominated by strong in-groups and out-groups, business decisions made on the basis of favouritism and personal connections, including bizarre stories about byzantine sex orgies involving corporate executives.
Even the feminism angle is relevant here, because more often than not women are made worse off in these laissez-faire arrangements.
I think a new BFDL would be a worse-is-better solution than all this play-government formality, to be honest. It seems to be an effective system for many languages, including Python in the past.
Finding a "full" BDFL that's not the original founder seems quite difficult: who's gonna have that level of respect and authority, can trust on having it even in the face of conflict and is willing to do the job after seeing it not work out for the project founder? Some communities might have such a candidate (e.g. in Linux maybe one of Linus' lieutenants?), but many won't. Questions of legitimation and ways of replacing them are gonna come up, and if you don't codify the answers are gonna come up again and again. If you codify them, you now have an election mechanism, a "vote of no confidence" mechanism, ... specified, and aren't that far from an elected leadership. Given the amount of work it is and conflicting interests in the community, does it then really make sense to have that leadership be one person?
Hi, former BDFL here. It's a crappy job. A crappy, unpaid job. I can't think of a single qualified person in the Python community who'd want the gig. (I can think of several unqualified people who would, and that's part of the problem too.)
TBH, I had kind of wished that one of you from the Django core would take the reigns next (preferably, you), as a BDFL, since Django was it an extremely well-run project, especially under your leadership.
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.
BDFLs only work when they're the founder of the language, or a well-respected community member who is explicitly appointed by the prior BDFL. Without a clear line of succession, you get all the same destructive infighting and power struggles that real-world dictatorships experience.
A good benevolent dictator is often more efficient than a more decentralized and democratic system but you have a single point of failure and you need to be able to find said dictator in the first place. A bad or incompetent not-so-benevolent dictator can be absolutely terrible for a project and cause a lot of long-term damage.
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 under the impression that well-described, transparent decision making process has the consequence of increasing cognitive load when it comes to participating in decision making. Given that decision-making in large projects like this is already a significant cognitive load, adding on "did I make the decision following pre-defined process goals" does increase difficulty. Whether or not the tradeoffs are worth it is another decision.
Correct that it involves tradeoffs, though having no process at all for making decisions leads to at worst a free-for-all (which can work for small or non-critical projects, but even so be prepared for inevitable drama), or at best an opaque and implicit process as others here have warned about. To use a HN-friendly analogy, it's like static typing vs dynamic typing: you can either accept pain up-front to avoid pain down the road, or vice-versa. The latter is better for massive, established projects and the former is better for young, rapidly-changing projects, so we must consider which of these two better resembles the Python project.
I consider it unfortunate because I think we've all been frustrated by "due process" and having to wait or do seemingly useless tasks when the way to go appears obvious. Being able to say "let's do this" and start hacking right away sounds a lot more fun than "let's submit an RFC and wait for one month for people to comment, then we'll vote and if people accept the proposal we'll implement the unit tests, do the code review, validate the tests, put it on the unstable branch for at least six months and if everything goes right we'll have the change released next year".
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.
Unlike other software projects, language design requires a single mind to think holistically, break things when needed, avoid feature creep while at the same time keep doors open for new ideas. It’svery intricate balance. Once language doesn’t have one leader, it will likely die in long term. I would call it death by committee:).
This is unfounded in practice. Having a BDFL did little to stop Python's feature set from growing, or to prevent design flaws like `lambda`, or to make Python 3 anything other than the poster child for how not to break things. Conversely, we can look to Javascript (yes, Javascript!) as an example of a language that was a total mess after being designed by a single person and that got immeasurably better once it began being designed by committee (yes yes, "ten days" and all that, but I daresay that even Eich would agree with me that the Javascript committee has done a relatively fantastic job).
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.
I'm curious, and I didn't see any other mention of it in the thread : why do you consider `lambda` to be flawed ? Is it because it has the same scoping rules as functions, and that you consider these scoping rules inappropriate for lambda expressions ?
I think as far as successful languages go, the truth is the opposite. Languages with large design by committee teams are most successful. C++, Java, C, JavaScript or even going back to Cobol and Fortran. The languages with the most use are not typically designed by one person.
But C++ is Stroustrup, Java is Gosling, C is K&R, JavaScript is Eich. Most successful languages kept their internal consistency by being designed by a single person. Historically, these single persons also had mustaches.
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.
I disagree that such languages will die, but they might become designless frankensteins that draw their life energy from sources best left unexplored (see: Java, HTML)
I believe a concern would be a single point of failure and burnout, the consequences of which would be massive losses of organizational, directional, and domain knowledge.
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.”
I guess it points to a difference between klennwell's and jetrink's comments above: "The BDFL has the final say" is process in the sense of jetrink's comment (it's an explicit power structure that can avoid some of the worst of the unorganized alternatives, with IMHO unique acceptance), but it's not bureaucracy as in klennwells. I had mentally nested your comment wrong.
The question is if the explicit ones replace the implicit ones or are in addition to them.
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.
There's little risk of that, since the governance structure has apparently been determined here by the core developers themselves. The goal of any such effort like this is not to outright eliminate all implicit power structures (effectively impossible), but to explicitly surface a semblance of the existing implicit structure for greater transparency in governance.
It's not like there is only one alternative. You can solve most of those problems by splitting large organization into smaller independent ones. Instead of wasting energy on elaborate bureaucracies and rules, people ought to spend some time on studying how to handle this "splitting" in the best way possible. Alas, most people like to play government.
Two common and tested-in-practice voting systems: one to select members of a group, one to decide between multiple options inside that group (which isn't the same problem, so it makes sense to vote differently). One committee to replace what before was a BDFL who resigned and thus needs to be replaced, ideally in a way that doesn't make discussions worse than they are (so transparency and clearly defined rules for edge cases are important. A BDFL can afford to be somewhat intransparent and inconsistent, an elected group can not)
Exactly. As someone who is on the board and used to be the chair of a non-profit, rules and procedures tend not to matter much. Until they do. You hit some edge case where people seriously disagree and things like voting rights, proxies, the process for bringing an issue to a vote, etc. suddenly matter if you don't want to just leave decisions in the hands of whoever has the loudest voice and/or feels most entitled to having the final say.
Politics in organisations is pretty grim. But, what would you have as an alternative? Decisions need to be made. Disagreements need to be resolved. Ad hoc resolutions to problems doesn't scale with increasing team size. Neither does anarchy.
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.
The new Python model is pretty similar to what Django has been using for years (and even admits that it copy/pasted significant chunks of text from our model). I didn't realize how grim things were!
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.
Play-democracy is a well-known problem in a lot of projects. OpenSolaris had the same issue, and it had some pretty disastrous consequences (though they modelled themselves after Apache which isn't really the best model).
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.
I suspect you're being downvoted because these models don't particularly resemble democracy, which would presumably involve having the users of the software vote, rather than the developers of the software.
In Westminster-style democracies, party members elect their party's leader (the general public don't get to decide who the leader of a particular party is).
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).
Nitpick, but like many things in America that varies from state to state. Many have "open primaries" where you just show up and request whichever party's ballot you want.
I'd say this looks to be conflating "voting" with democracy-in-spirit. The OP mentions that about 90 people participated in this vote, which is less than a slim fraction of Python's hundreds of thousands of users. This isn't analogous to a representative democracy, because that would imply some sort of election to appoint the "representatives", which wasn't the case.
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).
I would argue that the people most impacted by the steering committee's decisions would be the core team -- who are the people that voted, and thus the steering committee model represents the will of the core team.
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.
The grandparent comment wasn't about formal replacing informal, it was about bureaucracy replacing dictatorship.
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.
All dictatorships have bureaucracies; are they going to rule alone? The question is whether those power structures are visible and explicitly negotiable.
Is this really true? Does this work in every kind of war or Moon-race? Control is important, but so is individual initiative. The front line needs the latter the HQ needs the former. That's why "aligning goals" is the important thing, not just rules for power's sake. (That's authorianism of course.)
To be clear, pas's comment is replying to an earlier version of cousin_it's:
> 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.)
Individual initiative is maximized when people have sole responsibility for their tasks, not when every decision needs to be approved by ten committees.
> Individual initiative is maximized when people have sole responsibility for their tasks, not when every decision needs to be approved by ten committees.
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.
Every military in the world is hierarchical and the best armies gave people lower in the hierarchy a bit of freedom so that they could improvise. They also educated almost every rank to be able to handle the duties of their immediate superior in case they needed to take that position quickly.
Basically control > individual initiative but control + individual initiative >>> absolute control (see Stalinism).
I wonder if programming languages might be considered a type of a project where comfort of members is of less importance than other goals (mindshare?).
The reason you lay all this stuff -- especially the "if something goes wrong" plan -- out in excruciating detail in advance is extremely simple.
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.
At least I hope they will give the obscure old-fashioned communication model (mailing lists, Usenet newsgroups, yet another bug tracker for everybody to register at (which doesn't even work right now - it's Error #502)) up and embrace GitHub issues and pull requests system like Rust and C# teams do.
Yes, but the real strength of Python (as with most popular languages) comes from its community. The reason why I end up using it so much is because somebody already made a good library that does what I want, and because it's much easier (for me) to tell what the hell is going on in other peoples' code compared to JavaScript.
Zizek is famous for pursuing a line very much against the grain; people intellectually similar to him argue for a society organised informally and locally, like a commune - but he argues that he'd rather be living in a bureaucracy in which he doesn't have to worry about all the smallest decisions and direct democracy. To him, the trouble of the USSR wasn't all the bureaucracy, it was that it wasn't bureaucratic enough to the point where it was easy to game the system.
>Ž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.
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."
He's a continental philosopher who specialises in political philosophy, a topic which is very relevant to methods of governance in society (most generally) or smaller units (like programming projects). In particular, his concern in this scope is questioning the extent to which critiques of current methods of governance and the organisation of society (e.g as highlighted by the Frankfurt School's critical theory) are relevant to any future methods, and whether questioning government philosophically rules out a bureaucratic governance.
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.
This does not close nor stifle creativity at all, unless your point is that any majoritarian system does so. There is a balance involved, too much chaos and everything explodes.
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.
Uhmm, it is self organizing as well as transparent. This is why the rule for changing governance rules (including itself) is simple and transparent. To keep relative stability, it has a built in buy in threshold.
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.
Zizek isn't a philosopher, he's an entertainer disguised as a philosopher. His entire schtick is: take something common sense, declare the opposite is true, and do so in a profound-sounding way with lots of eccentric gesturing and lisping.
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.
There's also the fact that he's impressively blind to abuses of power committed by his friends. Doesn't inspire confidence in his ability to see things clearly.
I've come across a comment almost exactly like this before on HN; was it you who posted it? Zizek does entertain, but most popular writers also entertain, and entertainment is not mutually exclusive with philosophy. He is respected within philosophy (and Chomsky is not a philosopher, as much respect I have for him too) and widely cited. The inversion of common sense things is precisely the aim of critical theory. Granted, Zizek draws from "low culture" too in order to appeal with popular media, but you can't simply say he's not a philosopher. What he does is philosophy or critique of it and you can read as much in his books.
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.
He's a pop philosopher and a genius at cultivating followership, but he doesn't really have productive ideas (at least not ideas whose results you couldn't explain in 5 minutes to a 12 year old, to borrow Chomsky's language).
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.
It's important to analyze arguments not by what they seem to be but by what they actually are; the substance of what he's saying isn't that the USSR (for example) "wasn't real Communism" because it wasn't bureaucratic enough, his position is that regardless of whether it is "real Communism" or isn't, bureaucracy is still a question of central importance. The notion of discussing "utopia" in relation to its actual existing aspects is covered quite well by Marcuse[0].
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.
Theoretical arguments are incredibly overrated for complex systems. Usually, they're just ways for academics to signal their ability to make these arguments, to show off how smart they are, and of little utility otherwise.
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.
The trouble is, their system mostly works because of culture, not because it is truly any better.
A certain high level of egalitarianism, responsibility for decisions and push back against exploitative or manipulative practices is required for success.
This makes transplanting their practices hard.
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.
Obviously, the environment matters. It's not just culture but geography, history, genetics. It's much easier to run a free country when you're surrounded by oceans (like the US) or mountains (like Switzerland) than when you're surrounded by potential conquerors.
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.
On the other hand, critical thought about such systems as they exist can pave the way to what we should and shouldn't want in future systems. While it's true of course that history doesn't follow some Solvenian philosopher's blueprint, real action is informed by theoretical aims. The other extreme is extreme apathy to towards democratic decisions (as others have pointed out) and how soul-killing and time consuming it is to have to engage with a great variety of things where a choice already made for you would be better. Compare this with the many arguments on this site about hosting your own e-mail server rather than using gmail + PGP.
Indeed, but they do have policies, high level approaches and big decisions too.
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.
Python has been designed by committee for decades now. The PEP process was introduced in 2000, and even before that the language was being designed by the members of the python-dev mailing list.