81–90 of 191 posts
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?
[0] https://discuss.python.org/t/python-governance-vote-december...
Earlier quoted context omitted.
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…
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 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).
Earlier quoted context omitted.
> unfortunately 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…
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…
Councils, committees, multiple obtuse voting systems, governance documents, 'courts' of appeal... Why are they so keen to construct such a grim bureaucracy for themselves?
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.
Earlier quoted context omitted.
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
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).
Earlier quoted context omitted.
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."…
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.
Earlier quoted context omitted.
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…
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…
Earlier quoted context omitted.
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:).
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.
Earlier quoted context omitted.
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 pa…
> unfortunately 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…
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.
Earlier quoted context omitted.
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
> 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).