In my opinion, Debian has the best open-source governance model out of all the projects without a BFDL. Because it basically emulates it by appointing a single person to be responsible for the entire vision, yet making him still accountable to others[1]. Thus the horror of the "design by committee"[2] is avoided.
I think there's nothing wrong with re-using good solutions that others have worked out instead of building your own just for the sake of being different. That's the open-source idea even, no? Freely reuse and build upon the work of others, so that we don't have to reinvent things again and again.
And yet open source is constantly reinventing the same things over and over again anyway.
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
I don't think there's a good way to measure Debian's contributions outside strictly packaging its distribution.
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.
> it does speak to potential limitations of the model
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).
RedHat wasn’t always as big as it is now. In fact, it was likely smaller than Debian, in terms of manpower, for some time. I suspect the total number of package maintainers is still higher on the Debian side.
Probably at least partly by necessity. Not everyone participating is doing it as their FT job. I'm sure that RedHat is paying a lot of devs to work on these things as a full time job. Even just integrating software from others as packages, etc.
The way I understood the parent is that the Debian model didn't actually solve the problem it was suggested as a solution for. It merely offloaded the problem to someone else. In other words, it has a dependency and therefore is not a complete solution. That's how I understood it.
> It merely offloaded the problem to someone else. In other words, it has a dependency and therefore is not a complete solution.
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.
In terms of out of the box stability and support? Yes, absolutely.
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.
I agree that preinstalled OSX and Windows offer a better end-user experience. I disagree with some of your other statements though.
> 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.
[0] 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.
> In terms of out of the box stability and support? Yes, absolutely.
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)
Except my understanding is that the amount of manpower involved in the Linux kernel is greater than that involved in the Windows kernel. (Does Apple do kernel development at all?)
In other words, you think if Debian had a larger, more vibrant community it would take in fewer "good solutions" from other projects and instead decide to create its own alternative good solutions in house?
I think this is the first time I've heard someone critique a model for encouraging anti-NIH syndrome.
And yet open source is constantly reinventing the same things over and over again anyway.
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.
> I think parent's complaint is that Debian's model has failed to produce good solutions of its own
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.
> I think there's nothing wrong with re-using good solutions that others have worked out instead of building your own just for the sake of being different.
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 claimed reinvention from scratch of a text editor, and the nice command, are in fact nothing of the sort. One is a means for invoking a text editor (of one's choice) against particular configuration files, no more a "reinvention from scratch" of a text editor than the vipw command is; and the other is one of the several settings specifying eventual service process state, and is no more a reinvention from scratch than the Service Access Facility's "ulimit" built-in was in 1988.
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.
> 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.
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.
Last time I was a debconf, one such decision was basically 20-30 interested people sitting in the room and the speaker says "We need more people if we want to maintain and develop X, or could switch over and use Y. What is the progress on packing Y?". It was a rather simplistic process by the developer who is doing the work and anyone interested that wanted to show up. Debian leadership rarely get involved in such decisions.
And RedHat takes projecys ftom upstreams they don’t contribute to and bundle them in their systems. Sorry, but this is a particularly mean spirited attitude. The open source model has always been to share your work On one hand and selectively use others work yourself where it makes sense. That’s what opens source is for. It’s what it means. BSD is free to commit their resources to those areas where they feel they can offer value or meaningful differentiation, and they do so.
Every design either comes from one person, or it comes from a committee. A project like Python has long since scaled far beyond the capability of one person to feasibly design. The same is true of any other major (or minor) programming language. Vague anxiety about design-by-committee is always in vogue, but it doesn't do us any good.
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.
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 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.
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.
And the Python project now sees that it wants to transition away from that model. Guido represented Python, was the ideal dictator, but probably there was no good candidate to replace him, hence the complications.
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.
I find it fascinating that programmers like to discuss governance at such great lengths without any reference to the vast knowledge of Political Theory that lies at their fingertips.
At the end of the day, I suppose this is simply yet another form of NIH
It's a fundamentally different problem. There are extremely limited commonalities between an opt-in group based on a technical project, and a society. I think people actually illegitimately apply all sorts of concepts from mass politics to small working groups, without paying attention to the actual reason why these concepts are necessary in society, and what problems they exist to solve.
They settled on Condorcet, a method almost unheard of outside of electoral/political theory, and your criticism is that they didn't make use of political theory?!
That defines the voting system, but not governance and representation
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 it goes beyond NIH, although NIH certainly part of the problem.
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.
>all the negative aspects of it stem from some location other than people haggling over limited resources.
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[0]. Societies change people but people also change society[1].
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.
[0] "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)
[1] "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)
> 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.
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.
My point on ideology wasn't to say that ideology is extremist, rather it was to say that we are all ideological. Ideology in popular speech seems to mean something extremist, because we figure outselves to be free of ideology: rational, economical etc. - but these are ideologies in themselves. You and I are both steeped in ideology and that's not a bad thing. The bad thing is thinking we are free of it, or the world works as if it's free of it, or that societies don't perpetuate themselves through Establishment ideology.
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 always envy of Python. Look at those PEPs! Yes it may be a little too formal, but there are lots of PEPs, many discussions, and progress. Well the word progress might not be entirely correct, but lots of activities. Look at Guido! He was always on the front battling, arguing or trying to steer the ship. Look at Python and Data Science, it went from good programming language to learn to must have for Data Scientist and Machine Learning. PyPy!
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.
When you need to inherit something that big (a corporation, programming language, a missle, etc.), you need to make sure that it won't be cannibalized or just killed outright. So you delegate your powers to a group of optimal number of people.
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.
It's curious that there was so much discussion about how to vote, while there seemed to be no question who would vote. The article mentions there was a pool of 94 eligible individuals but doesn't explain further where they come from. Does anyone have more info about that?
Linux has never purged any of those. It is more like it got "conquered" by money and resources allocating developer time. For that matter, so will any truly important and developed FOSS.
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.
Theo Tso fought against the backdooring of /dev/random by the NSA. That this backdooring was attempted was confirmed by Snowden leaks.
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...
Not that I disagree with your point, but the Snowden leaks only confirmed that the NSA does backdooring in general, not that the Intel rdrand instruction in particular was backdoored.
It's only every 18 months. It'll probably be mosyly the same people all the time, Guido and Tim Peters could probably hold seats as long as they want them.
This was borrowed straight from Django's process; our technical board gets re-elected every release cycle.
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.
Do you know if council members can be re-elected? Does "new council" imply a brand new set of council members? If so wouldn't that hurt institutional knowledge?
Because in any discussion about "new councils" ever, it never means that the entire council would be different. Be it a parliament, city council, a church committee, or a software project — the point isn't who is in it or for how long but rather that an election (or any other sort of opportunity for rearrangement) has been held.
"New council", in this circumstance, is shorthand for "holding an election for the council".
Well, it creates a way for other members of the core team to replace someone they disagree with without having to call for a no-confidence vote all the time. I don't know what you mean by "revolutionary", but the point of these kinds of councils is to uphold the vision and principles of the language, and so long as the people in the council are making the correct calls in those regards, there would be no reason to replace them.
OP posted a subscriber link to LWN... if you like the content then subscribing to support LWN is well worth it! They are one of (if not THE) highest quality Linux news sites out there.
There are no term limits for steering council members, assuming they are doing the job adequately the core team can just let them continue in their seat.
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).
It's incredible how infectious the democracy meme is. It makes most sense when determining how violence will be used within a society (i.e. the fundamental function of government). It makes a lot less sense for running projects and organizations that people are free to come and go from. But the idea's intellectual stranglehold is just too strong to resist.
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.
[1] https://www.debian.org/devel/leader
[2] https://en.wikipedia.org/wiki/Design_by_committee