9 ms·

VIM seemed to have fared well under the new leadership, despite not being able to control the timing of this power transfer. Maybe other BDFL projects would be

VIM seemed to have fared well under the new leadership, despite not being able to control the timing of this power transfer. Maybe other BDFL projects would be inspired by VIM's experience and setup successors early. https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

eviks 2y ago
that'd be the wrong lesson to extend a period of using a bad governance model for longer
- flohofwoe 2y ago
  You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course. (also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)
  - eviks 2y ago
    Saying "no" is the easiest job in the world, and committees are pretty good at it. That's why we have decades-old design failures everywhere, because saying "no" to an improvement is so much easier that doing the actual governing and resource allocation to see it through, especially with volunteers And given the article describes big fails at basically every aspect of project management (from github account to money and website), not sure where you see the benefits of the supposed "focus"
    - bawolff 2y ago
      There are two types of comittees: Those that are paralyzed by fear of change and say no to everything, and those that are afraid of offending people and say yes to everything. Both are counterproductive.
      - eviks 2y ago
        Reality is not binary, so this extreme simplification is counterproductive when describing one
    - riffraff 2y ago
      > committees are pretty good at it. I don't know it seems to me that committees are famously bad at it, so that we use "design by committee" for something that refuses to take a single direction and either makes bad compromises or says "yes" to all options.
    - camgunz 2y ago
      > Saying "no" is the easiest job in the world It depends on your motivation. Probably a lot (many, most?) committees can just sit pretty and try to do as little as possible. But a lot of software projects exist by getting attention, and they tend to do that by adding features. A lot of FOSS maintainers find it super hard to say no. For some anecdata: I have a small/medium project and I've found that just the energy requirements of really thinking about everything everybody proposes are pretty high. I could just say "yes", but then I'm on the hook. I could also just say "no", but then I'm discouraging people and not really giving them any information about how to contribute productively--this would be something like, "sure we could add a flag to turn video upside down, but I'm concerned that putting this kind of functionality in flags means we'll have a UX of 1000 flags that no one can remember or use; should we start considering building another place to put this kind of functionality?
      - eviks 2y ago
        Your anecdata supports the no part: > just the energy requirements of really thinking about everything everybody proposes are pretty high Indeed, that's why it most often results in a no (your ending quote is just a polite way of saying no), and you're right about the discouragement part, and that's one of the reasons forks like neovim appear. (and unfortunately often you can't "motivate" your way into creating enough time for all that extra work either, so with the best intentions... no it is )
    - cjfd 2y ago
      In your first comment you seem to think that the BFDL for life is not so good. Now you are saying negative things about committees. So what do you think would actually be a good way to run an open source project?
    - flohofwoe 2y ago
      > Saying "no" is the easiest job in the world On the contrary, saying No to an otherwise great contribution that doesn't fit into the longterm vision of a project for one or another reason is the hardest thing in the world.
    - heisenbit 2y ago
      I agree, committees are good at saying no. They tend to say no to two not perfect ideas and then force a consensus containing most often the worst aspects of both original approaches. The good news is that the result is so bloated that can‘t be changed and so provides a stable foundation for years of misery. There are counter examples of course but the power dynamic of committees is not conductive to results that have properties desirable in software.
      - skriticos2 2y ago
        When I think about the two models, I have Linux as the dictator type and XML as committee designed. Both are functional enough, but the while so few data points are hardly conclusive, I think it's generally indicative. I'm not a particular fan of XML, even if it's functional enough to get the job done. Of course you have to find a dictator that is ready to invest all the time and energy to care for a project over a prolonged time and is actually capable of doing so while avoiding to alienate the user base. That's a pretty tall order.
        bawolff 2y ago
        > I'm not a particular fan of XML, even if it's functional enough to get the job done. XML by itself is okay-ish. The true design by comittee disasters are the specs surrounding it. XMLSignature, SOAP, etc
  - psychoslave 2y ago
    Unless your software deals with tracking people within an organization that will of course comply with the political parties that rule the regions where there software operate.
    - fsloth 2y ago
      If Vim tracks you then that’s a willfull act that breaches trust. IMO no governance model can defend against supply chain attacks. IMO you shouldn’t try to fix things with governance model which it doesn’t fix. Use a governance model that leads to good governance. In technical and creative work single highest point of authority is best. Not because they have perfect knowledge or are the best but because dictator led models lead to best alignment - which is something you simply need to execute when performing a complex task with many stakeholders. Dictator led models aren’t best for everything. But for complex tasks with specific fixed scope with multiple concurrent contributors it seems to be the only model that works (if there are case studies as counter example I would love read on them! I.e. complex task, more than 10 contributors, non-dictator governance).
      - Propelloni 2y ago
        Hmh, I don't have a case study at hand, but there are many reports (and management self-help literature) where teams are shown to be the superior approach to complex situations, especially in software development. Furthermore, considering that there are only about 50 identified open source projects out there with a BDFL [1] and only a few of them are clearly best-of-breed, while there are many best-of-breed projects that do not use a BDFL I'd wager that the perceived superiority of BDFL can at least in part be attributed to the perennial hero worshiping we like to do. [1] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
        flohofwoe 2y ago
        Any tiny project on Github, Gitlab, ... which is maintained by one person but accepts PRs and feedback from outside contributors is essentially a BDFL project. The single project owner decides what goes and doesn't go into the project by merging or rejecting PRs. People are still free to maintain their own forks with contributions that are not accepted into the main version. In a way, the entire Github workflow is built around the idea of BDFL managed projects.
  - StefanBatory 2y ago
    Or HN too. I think most of us would agree that dang is a very good moderator.
  - johnnyanmac 2y ago
    It's the best, when you find one. But the approach is also the riskiest. You may not even pick a BDFL to begin with (I'm sure many of us can name certain repos overly held back by a bad or muddy vision, or being overly conservative with feature/pull requests) . or that B fades away for any number of factors. Committees sacrifice that cohesive vision and agility for being able to have some checks to potential rouge actors.
    - normie3000 2y ago
      > potential rouge actors Communist assets?
      - wakawaka28 2y ago
        Not necessarily. Sometimes people infiltrate projects with the intent of sabotaging them. This may be done by causing a controversy, or else making bad technical decisions on purpose.
        ahartmetz 2y ago
        I think you missed the joke. "Rouge" is French for red. Most likely it was meant to say "rogue" but it was misspelled.
    - vlovich123 2y ago
      This is what another commenter wrote: > Braam really took Neovim personally and got better at getting stuff into vim that he wouldn't merge before once neovim was arround as a competitor. I really lost track of vim in the last years because neovim is just a solid platform with an active community. I think that's the answer - the specific makeup of any given team isn't as relevant as competition which spurs competitors to either keep up or the more successful upstarts to take over.
    - w0m 2y ago
      > But the approach is also the riskiest Honestly in open source I'd argue it's not. If an OSS project has significant usage, if BDFL struggles/etc - community forks can put the project back on pace. NeoVim is the classic (successful) example that gave us a great alternative while also nudging the BDFL into the modern age.
  - pif 2y ago
    > software projects don't need to be democracies Especially opens source ones, where anyone can spawn their own kingdom via a simple "git clone".
  - tomrod 2y ago
    One of the most powerful ideas I've come across is Arrow's impossibility theorem, which basically states that you don't get a lot of nice group choice outcomes without a dictator in the mix. It's a math formulation, so its not commenting on the realities of a despot, but rather, someone's choices will always dominate if you want a certain set of properties in the decision making. https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theore...
  - giancarlostoro 2y ago
    > unless the BDFL is a complete ass of course. I think in the case of Linus, you REALLY have to be strict. I mean, its arguably one of if not the most used pieces of software deployed in enterprise and globally for all manner of use cases.
  - bee_rider 2y ago
    Yeah, “dictator” was probably the wrong word. The characteristic of an actual dictator (even a benevolent one) is that they can enforce their will through violence if needed (benevolent ones usually don’t, but they could). As quote goes, “I thought we were an autonomous collective.” Humans have some sort of tribal or pack instinct; if we want to do a project, we’ll often naturally form up around the person who’s doing it, willingly and without compulsion. The leader is the leader because everyone agrees they are doing good enough. Open source project is sort of an ideal form of this. Unlike physical projects, the ability to fork for free means that the leader doesn’t even have the implicit moat that a potential alternative leader needs to take the current work-in-progress away from them. BDFL is just a joke title.

eviks 2y ago

that'd be the wrong lesson to extend a period of using a bad governance model for longer

flohofwoe 2y ago
You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course. (also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)
- eviks 2y ago
  Saying "no" is the easiest job in the world, and committees are pretty good at it. That's why we have decades-old design failures everywhere, because saying "no" to an improvement is so much easier that doing the actual governing and resource allocation to see it through, especially with volunteers And given the article describes big fails at basically every aspect of project management (from github account to money and website), not sure where you see the benefits of the supposed "focus"
  - bawolff 2y ago
    There are two types of comittees: Those that are paralyzed by fear of change and say no to everything, and those that are afraid of offending people and say yes to everything. Both are counterproductive.
    - eviks 2y ago
      Reality is not binary, so this extreme simplification is counterproductive when describing one
  - riffraff 2y ago
    > committees are pretty good at it. I don't know it seems to me that committees are famously bad at it, so that we use "design by committee" for something that refuses to take a single direction and either makes bad compromises or says "yes" to all options.
  - camgunz 2y ago
    > Saying "no" is the easiest job in the world It depends on your motivation. Probably a lot (many, most?) committees can just sit pretty and try to do as little as possible. But a lot of software projects exist by getting attention, and they tend to do that by adding features. A lot of FOSS maintainers find it super hard to say no. For some anecdata: I have a small/medium project and I've found that just the energy requirements of really thinking about everything everybody proposes are pretty high. I could just say "yes", but then I'm on the hook. I could also just say "no", but then I'm discouraging people and not really giving them any information about how to contribute productively--this would be something like, "sure we could add a flag to turn video upside down, but I'm concerned that putting this kind of functionality in flags means we'll have a UX of 1000 flags that no one can remember or use; should we start considering building another place to put this kind of functionality?
    - eviks 2y ago
      Your anecdata supports the no part: > just the energy requirements of really thinking about everything everybody proposes are pretty high Indeed, that's why it most often results in a no (your ending quote is just a polite way of saying no), and you're right about the discouragement part, and that's one of the reasons forks like neovim appear. (and unfortunately often you can't "motivate" your way into creating enough time for all that extra work either, so with the best intentions... no it is )
  - cjfd 2y ago
    In your first comment you seem to think that the BFDL for life is not so good. Now you are saying negative things about committees. So what do you think would actually be a good way to run an open source project?
  - flohofwoe 2y ago
    > Saying "no" is the easiest job in the world On the contrary, saying No to an otherwise great contribution that doesn't fit into the longterm vision of a project for one or another reason is the hardest thing in the world.
  - heisenbit 2y ago
    I agree, committees are good at saying no. They tend to say no to two not perfect ideas and then force a consensus containing most often the worst aspects of both original approaches. The good news is that the result is so bloated that can‘t be changed and so provides a stable foundation for years of misery. There are counter examples of course but the power dynamic of committees is not conductive to results that have properties desirable in software.
    - skriticos2 2y ago
      When I think about the two models, I have Linux as the dictator type and XML as committee designed. Both are functional enough, but the while so few data points are hardly conclusive, I think it's generally indicative. I'm not a particular fan of XML, even if it's functional enough to get the job done. Of course you have to find a dictator that is ready to invest all the time and energy to care for a project over a prolonged time and is actually capable of doing so while avoiding to alienate the user base. That's a pretty tall order.
      - bawolff 2y ago
        > I'm not a particular fan of XML, even if it's functional enough to get the job done. XML by itself is okay-ish. The true design by comittee disasters are the specs surrounding it. XMLSignature, SOAP, etc
- psychoslave 2y ago
  Unless your software deals with tracking people within an organization that will of course comply with the political parties that rule the regions where there software operate.
  - fsloth 2y ago
    If Vim tracks you then that’s a willfull act that breaches trust. IMO no governance model can defend against supply chain attacks. IMO you shouldn’t try to fix things with governance model which it doesn’t fix. Use a governance model that leads to good governance. In technical and creative work single highest point of authority is best. Not because they have perfect knowledge or are the best but because dictator led models lead to best alignment - which is something you simply need to execute when performing a complex task with many stakeholders. Dictator led models aren’t best for everything. But for complex tasks with specific fixed scope with multiple concurrent contributors it seems to be the only model that works (if there are case studies as counter example I would love read on them! I.e. complex task, more than 10 contributors, non-dictator governance).
    - Propelloni 2y ago
      Hmh, I don't have a case study at hand, but there are many reports (and management self-help literature) where teams are shown to be the superior approach to complex situations, especially in software development. Furthermore, considering that there are only about 50 identified open source projects out there with a BDFL [1] and only a few of them are clearly best-of-breed, while there are many best-of-breed projects that do not use a BDFL I'd wager that the perceived superiority of BDFL can at least in part be attributed to the perennial hero worshiping we like to do. [1] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
      - flohofwoe 2y ago
        Any tiny project on Github, Gitlab, ... which is maintained by one person but accepts PRs and feedback from outside contributors is essentially a BDFL project. The single project owner decides what goes and doesn't go into the project by merging or rejecting PRs. People are still free to maintain their own forks with contributions that are not accepted into the main version. In a way, the entire Github workflow is built around the idea of BDFL managed projects.
- StefanBatory 2y ago
  Or HN too. I think most of us would agree that dang is a very good moderator.
- johnnyanmac 2y ago
  It's the best, when you find one. But the approach is also the riskiest. You may not even pick a BDFL to begin with (I'm sure many of us can name certain repos overly held back by a bad or muddy vision, or being overly conservative with feature/pull requests) . or that B fades away for any number of factors. Committees sacrifice that cohesive vision and agility for being able to have some checks to potential rouge actors.
  - normie3000 2y ago
    > potential rouge actors Communist assets?
    - wakawaka28 2y ago
      Not necessarily. Sometimes people infiltrate projects with the intent of sabotaging them. This may be done by causing a controversy, or else making bad technical decisions on purpose.
      - ahartmetz 2y ago
        I think you missed the joke. "Rouge" is French for red. Most likely it was meant to say "rogue" but it was misspelled.
  - vlovich123 2y ago
    This is what another commenter wrote: > Braam really took Neovim personally and got better at getting stuff into vim that he wouldn't merge before once neovim was arround as a competitor. I really lost track of vim in the last years because neovim is just a solid platform with an active community. I think that's the answer - the specific makeup of any given team isn't as relevant as competition which spurs competitors to either keep up or the more successful upstarts to take over.
  - w0m 2y ago
    > But the approach is also the riskiest Honestly in open source I'd argue it's not. If an OSS project has significant usage, if BDFL struggles/etc - community forks can put the project back on pace. NeoVim is the classic (successful) example that gave us a great alternative while also nudging the BDFL into the modern age.
- pif 2y ago
  > software projects don't need to be democracies Especially opens source ones, where anyone can spawn their own kingdom via a simple "git clone".
- tomrod 2y ago
  One of the most powerful ideas I've come across is Arrow's impossibility theorem, which basically states that you don't get a lot of nice group choice outcomes without a dictator in the mix. It's a math formulation, so its not commenting on the realities of a despot, but rather, someone's choices will always dominate if you want a certain set of properties in the decision making. https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theore...
- giancarlostoro 2y ago
  > unless the BDFL is a complete ass of course. I think in the case of Linus, you REALLY have to be strict. I mean, its arguably one of if not the most used pieces of software deployed in enterprise and globally for all manner of use cases.
- bee_rider 2y ago
  Yeah, “dictator” was probably the wrong word. The characteristic of an actual dictator (even a benevolent one) is that they can enforce their will through violence if needed (benevolent ones usually don’t, but they could). As quote goes, “I thought we were an autonomous collective.” Humans have some sort of tribal or pack instinct; if we want to do a project, we’ll often naturally form up around the person who’s doing it, willingly and without compulsion. The leader is the leader because everyone agrees they are doing good enough. Open source project is sort of an ideal form of this. Unlike physical projects, the ability to fork for free means that the leader doesn’t even have the implicit moat that a potential alternative leader needs to take the current work-in-progress away from them. BDFL is just a joke title.