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 agree with this, and I'm mostly under the impression that in the case of a benevolent dictator, the benevolent dictator already has a set of processes that are just opaque/implicit. However it is true that in the case of multiple minds (a council) there is latency cost (bureaucracy).
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.
Java's predecessor Oak was created by 13 guys (among them Patrick Naughton, Mike Sheridan, James Gosling and Bill Joy) over 18 months a different then relatively quickly grew to a larger team. (While that project didn't include the language spec itself only, but also runtime and library)
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)
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.
It has been discussed on HN multiple times: https://hn.algolia.com/?query=THE%20TYRANNY%20of%20STRUCTURE...