4 ms·

How much of Python's success is down to the BDFL(-delegate) approach of governance? It seems a lot of projects have adopted it and Python's PEP system for manag

by ssl232 5y ago

How much of Python's success is down to the BDFL(-delegate) approach of governance? It seems a lot of projects have adopted it and Python's PEP system for managing new features. I wonder if Debian could use a similar sort of elected presidential system.

sph 5y ago
I am of the opinion that BDFL style governance is best in software. In the real world the problem is a bit more hairy, but if you have an issue with a tyrant in open source, you can just fork the project. A BDFL solves the bureaucracy problem (they mandate, everybody implements) and the big ego problem (the biggest ego is at the top by definition). Also BDFL can have vision, something a committee will never have. In my humble opinion, people like Torvalds and Jobs are the secret to wildly successful software.
- hoseja 5y ago
  What does Jobs have to do with software.
  - Angostura 5y ago
    A lot of the software at Apple was shaped specifically by his likes, dislikes and needs. The dictator doesn't need to be a developer.
  - 0des 5y ago
- hanselot 5y ago
- petre 5y ago
  I find the role based FreeBSD core team approach more adapted to projects such as Debian. They also started with BDLF and then moved on to the core team approach. That's several BDFLs, every one of them with different responsibilities. It's 9 people in the case of FreeBSD. They've tried it with 20 people and then scaled back to 9: "Deadwood and apathy in the 20-member core team lead to creating bylaws that set up a 9-member elected core team First elected core team in 2000 with few carryovers from old core team" [1] It should also be an odd number if they vote, so that there won't be a tie in votes. The same approach is used in kendo and other Japanese martial arts examinations, the number of examinators is always an odd number. This also solves the "what if the BDFL is hit by a bus" problem: another member is appointed. 1. https://papers.freebsd.org/2018/bsdcan/mckusick-The_Evolution_of_FreeBSD_Governance.files/mckusick-The_Evolution_of_FreeBSD_Governance.pdf https://papers.freebsd.org/2018/bsdcan/mckusick-The_Evolutio...
- Karellen 5y ago
  The trick with BDFL is, of course, lucking into a suitably B BD, and hanging onto them for as much L as possible. And benevolence is not an attribute that can be passed to one's successor. Torvalds and Jobs have done well, but are examples of survivorship bias. What about all the software projects helmed by autocratic douchebag dictators which never went anywhere because they were unable to attract enough contributors to feed the dictator's ego to the point where the community became self-sustaining? Debian's been going longer than a lot of other software projects, and kept going after the initial founder(s) left the project. The process is messy, sure, but it sure seems sustainable so far.
  - kibwen 5y ago
    Precisely. Everyone adores a caring and benevolent dictator. The problem is that the sort of personality traits that inspire someone to pursue a position of power make it overwhelmingly likely that your dictator will be malevolent rather than benevolent. There's a reason that examples of effective BDFLs arise from cases where the dictator was in place before the project became popular. The other problem is the continuity of leadership. Despite its flaws, one of the strengths of democracy is that the code paths for the transition of power are explicit and regularly exercised. The only reason that anybody has any faith in any potential replacement for Torvalds is that, presumably, Torvalds will hand-pick his inevitable successor. But the successor's inevitable successor will have none of the same legitimacy, and by that time (be it decades from now) I expect the project to transition away from a BDFL model out of necessity.
dataflow 5y ago
I mean, C++ is designed by committee, and it's hard to deny that it's been pretty successful too, regardless of what people's opinions on the language are. Both styles have flaws, but both can be adequate if you put in the right incentives and the right people.
- hoseja 5y ago
  C++ committee is an interface for several powerful interest groups. Where you don't have those, a committee is probably impractical.
- dralley 5y ago
  I'm not sure the success of C++ has as much to do with the C++ committee as the fact that there were few alternatives competing in the same space until the past decade.
  - dataflow 5y ago
    I didn't say it's due to the committee, I just said it succeeded and had a committee. Python succeeded and had a BDFL, but I wouldn't say it's due to that either - lots of projects pull off the latter but not the former.
pabs3 5y ago
The Debian Project Leader election voting is going on right now, but the powers they have under the constitution mean the position is mostly a figurehead/administrator. Governance is more distributed in Debian; there is the technical committee to resolve technical disputes, the release team, the archive admin team and other teams. https://www.debian.org/devel/leader https://www.debian.org/devel/leader https://www.debian.org/vote/2022/vote_002 https://www.debian.org/vote/2022/vote_002 https://www.debian.org/devel/constitution#item-5 https://www.debian.org/devel/constitution#item-5 https://wiki.debian.org/Teams/DPL https://wiki.debian.org/Teams/DPL
madeofpalk 5y ago
Much of product development is about having a Product Owner, much like a BDFL, who makes the calls when a call needs to be made.
jeffparsons 5y ago
I can't deny Python's success, but I wouldn't hold it up paragon of change management, either. 13+ years after the release of Python 3 and 2+ years after 2.7's EOL, I'm still dealing with Python dependencies that don't work on Python 3 because maintainers preferred to pretend that Python 3 wasn't happening and that Python 2.7 would be around forever. It's confusing as heck trying to figure out what I should even expect to work, because some authors treat it as obvious that their code will work on both Python 2 and Python 3, while other authors treat it as obvious that they still only support Python 2. I've had a lot less trouble with merged /usr. I guess it's not a fair comparison, but it does suggest to me that there are more important factors at play.
- XorNot 5y ago
  What sorts of packages are these though? I've not had a single problem with anything practical in years.
- ssl232 5y ago
  Guido van Rossum openly admits the move from 2 to 3 was a bit of a disaster. I think some of the decisions made since then have been more conservative in a bid to avoid such damage again. And talk of a Python 4 is for the most part academic. It sounds like the package authors sticking with Python 2 that you're dealing with are just stubborn beyond belief. The rest of the world has moved on whether they agreed with the changes in Python 3 or not. Hopefully if the packages are useful enough to others and the licence allows it, people will fork them and make them work with 3.
- drexlspivey 5y ago
  Can you link to a few maintained packages that only support Python 2?
  - nyuszika7h 5y ago
    This one is relatively maintained, for example: https://github.com/pyroscope/pyrocore https://github.com/pyroscope/pyrocore

by ssl232 5y ago

sph 5y ago

I am of the opinion that BDFL style governance is best in software. In the real world the problem is a bit more hairy, but if you have an issue with a tyrant in open source, you can just fork the project. A BDFL solves the bureaucracy problem (they mandate, everybody implements) and the big ego problem (the biggest ego is at the top by definition). Also BDFL can have vision, something a committee will never have. In my humble opinion, people like Torvalds and Jobs are the secret to wildly successful software.

hoseja 5y ago
What does Jobs have to do with software.
- Angostura 5y ago
  A lot of the software at Apple was shaped specifically by his likes, dislikes and needs. The dictator doesn't need to be a developer.
- 0des 5y ago
hanselot 5y ago
petre 5y ago
I find the role based FreeBSD core team approach more adapted to projects such as Debian. They also started with BDLF and then moved on to the core team approach. That's several BDFLs, every one of them with different responsibilities. It's 9 people in the case of FreeBSD. They've tried it with 20 people and then scaled back to 9: "Deadwood and apathy in the 20-member core team lead to creating bylaws that set up a 9-member elected core team First elected core team in 2000 with few carryovers from old core team" [1] It should also be an odd number if they vote, so that there won't be a tie in votes. The same approach is used in kendo and other Japanese martial arts examinations, the number of examinators is always an odd number. This also solves the "what if the BDFL is hit by a bus" problem: another member is appointed. 1. https://papers.freebsd.org/2018/bsdcan/mckusick-The_Evolution_of_FreeBSD_Governance.files/mckusick-The_Evolution_of_FreeBSD_Governance.pdf https://papers.freebsd.org/2018/bsdcan/mckusick-The_Evolutio...
Karellen 5y ago
The trick with BDFL is, of course, lucking into a suitably B BD, and hanging onto them for as much L as possible. And benevolence is not an attribute that can be passed to one's successor. Torvalds and Jobs have done well, but are examples of survivorship bias. What about all the software projects helmed by autocratic douchebag dictators which never went anywhere because they were unable to attract enough contributors to feed the dictator's ego to the point where the community became self-sustaining? Debian's been going longer than a lot of other software projects, and kept going after the initial founder(s) left the project. The process is messy, sure, but it sure seems sustainable so far.
- kibwen 5y ago
  Precisely. Everyone adores a caring and benevolent dictator. The problem is that the sort of personality traits that inspire someone to pursue a position of power make it overwhelmingly likely that your dictator will be malevolent rather than benevolent. There's a reason that examples of effective BDFLs arise from cases where the dictator was in place before the project became popular. The other problem is the continuity of leadership. Despite its flaws, one of the strengths of democracy is that the code paths for the transition of power are explicit and regularly exercised. The only reason that anybody has any faith in any potential replacement for Torvalds is that, presumably, Torvalds will hand-pick his inevitable successor. But the successor's inevitable successor will have none of the same legitimacy, and by that time (be it decades from now) I expect the project to transition away from a BDFL model out of necessity.

dataflow 5y ago

I mean, C++ is designed by committee, and it's hard to deny that it's been pretty successful too, regardless of what people's opinions on the language are. Both styles have flaws, but both can be adequate if you put in the right incentives and the right people.

hoseja 5y ago
C++ committee is an interface for several powerful interest groups. Where you don't have those, a committee is probably impractical.
dralley 5y ago
I'm not sure the success of C++ has as much to do with the C++ committee as the fact that there were few alternatives competing in the same space until the past decade.
- dataflow 5y ago
  I didn't say it's due to the committee, I just said it succeeded and had a committee. Python succeeded and had a BDFL, but I wouldn't say it's due to that either - lots of projects pull off the latter but not the former.

pabs3 5y ago

The Debian Project Leader election voting is going on right now, but the powers they have under the constitution mean the position is mostly a figurehead/administrator. Governance is more distributed in Debian; there is the technical committee to resolve technical disputes, the release team, the archive admin team and other teams. https://www.debian.org/devel/leader https://www.debian.org/devel/leader https://www.debian.org/vote/2022/vote_002 https://www.debian.org/vote/2022/vote_002 https://www.debian.org/devel/constitution#item-5 https://www.debian.org/devel/constitution#item-5 https://wiki.debian.org/Teams/DPL https://wiki.debian.org/Teams/DPL

madeofpalk 5y ago

Much of product development is about having a Product Owner, much like a BDFL, who makes the calls when a call needs to be made.

jeffparsons 5y ago

I can't deny Python's success, but I wouldn't hold it up paragon of change management, either. 13+ years after the release of Python 3 and 2+ years after 2.7's EOL, I'm still dealing with Python dependencies that don't work on Python 3 because maintainers preferred to pretend that Python 3 wasn't happening and that Python 2.7 would be around forever. It's confusing as heck trying to figure out what I should even expect to work, because some authors treat it as obvious that their code will work on both Python 2 and Python 3, while other authors treat it as obvious that they still only support Python 2. I've had a lot less trouble with merged /usr. I guess it's not a fair comparison, but it does suggest to me that there are more important factors at play.

XorNot 5y ago
What sorts of packages are these though? I've not had a single problem with anything practical in years.
ssl232 5y ago
Guido van Rossum openly admits the move from 2 to 3 was a bit of a disaster. I think some of the decisions made since then have been more conservative in a bid to avoid such damage again. And talk of a Python 4 is for the most part academic. It sounds like the package authors sticking with Python 2 that you're dealing with are just stubborn beyond belief. The rest of the world has moved on whether they agreed with the changes in Python 3 or not. Hopefully if the packages are useful enough to others and the licence allows it, people will fork them and make them work with 3.
drexlspivey 5y ago
Can you link to a few maintained packages that only support Python 2?
- nyuszika7h 5y ago
  This one is relatively maintained, for example: https://github.com/pyroscope/pyrocore https://github.com/pyroscope/pyrocore