8 ms·

Long live reasonable BDFLs. They may annoy the community here and there, but the cohesion and gatekeeping provided by a quality BDFL is hard to match with a com

Long live reasonable BDFLs. They may annoy the community here and there, but the cohesion and gatekeeping provided by a quality BDFL is hard to match with a community. It's very hard for a community to have collective foresight, but even when they do, often a gatekeeper emerges anyways during review. Of course, it requires thicker skin on both sides of the coin, but in hindsight the tech benefits often outweigh the politics. Sure, some communities (e.g. the Rust one) show that a sole person need not reside at the top. But that often comes with slow implementation/decision costs.

lifthrasiir 8y ago
> Of course, it requires thicker skin on both sides of the coin, but in hindsight the tech benefits often outweigh the politics. And this is exactly why the BDFL model is not sustainable in a longer term. I do agree that a consistent tie-breaker (a role of GvR, a stereotypical BDFL, was indeed much like this) is good to have, but a BDFL eventually becomes a venerable monarch whose everything become controversial enough to make one a political entity regardless of one's intention. As GvR shows this also puts a lot of burden to a single person.
crtc 8y ago
> But that often comes with slow implementation/decision costs. It also comes with feature bloat.
- pcwalton 8y ago
  No, it doesn't. "Feature bloat" comes from wanting to appease everyone by taking the union of all proposals. That is ineffective community governance: it comes from allowing people to say yes but not no to features. Believe me, people love to say no to features in Rust.
geodel 8y ago
And even in Rust earlier module system written by someone else and was dumped wholesale without enough justification to author who finally left frustrated. Same with green threads which at one point they were hell bent on adding and then one fine day decided to dump. Also leading to ban someone in Rust community who was against green thread. I think what people do not want to talk about or do not get is unlike Oracle, Google, MS or Apple Mozilla can't just add few dozen highly paid people for language development. So this big community led approach is more of practical matter than some enlightened way to develop software.
- steveklabnik 8y ago
  I think you have some of your story slightly wrong. There were two previous build systems before Cargo; both of the authors did leave Rust, for different reasons. I'm guessing you are talking about the second. I don't remember the exact details, and I thought that they left a year before cargo was announced...maybe I have rose-colored glasses. But with green threads, Rust had them for quite a while, on the order of years. I think the person you're talking about was in favor of the removal of green threads, which we were initially against, but it did end up happening. That person also left Rust but wasn't banned; we've only ever banned one person, and that was fairly recently, and it was for an extended harassment campaign, not over some sort of technical disagreement. > So this big community led approach is more of practical matter than some enlightened way to develop software. We believe that it produces better technical outcomes. Rust has more paid developers than many, many languages. Regardless, when making decisions, it's important to be informed, and there's no better way to be informed than to get a broad description of the problem space and other approaches to solving them. One person is never going to be able to be an expert in everything that a language needs. There's also sustainability concerns with BDFLs, but that's a larger topic.
- pcwalton 8y ago
  None of this is true. > And even in Rust earlier module system written by someone else and was dumped wholesale without enough justification to author who finally left frustrated. I don't know what module system you're talking about. The first Cargo was unmaintained for a long time before being removed; the original author was long gone. The second rustpkg was largely Graydon's work, not "someone else". > Same with green threads which at one point they were hell bent on adding and then one fine day decided to dump. Also leading to ban someone in Rust community who was against green thread. We dumped them in no small part because the community didn't want them! And nobody was banned. > I think what people do not want to talk about or do not get is unlike Oracle, Google, MS or Apple Mozilla can't just add few dozen highly paid people for language development. So this big community led approach is more of practical matter than some enlightened way to develop software. In other words, you're saying we treat the community as just free labor. That's an incredibly cynical accusation, and one that bears no resemblance to reality. I'm pretty confident in predicting that if Rust had adopted a BDFL style of governance, it would have been dead long ago. Community input was critical in decisions like removal of green threads and I/O reform that have helped Rust find its niche.
pcwalton 8y ago
Rust would have died if it used the BDFL model. We had a huge disadvantage starting out, with a tiny team at a smaller company and little name recognition among the lead developers. The only reason Rust achieved any popularity at all was that we listened to the community when they were pushing us to compete 1:1 with C and C++ on performance. Cargo likewise would have been terrible without community input. The community was starting hostile forks before we course corrected. Additionally, Rust development frankly moves faster than any other language that I know of. You need only look at the release notes for that. The reason is that people can truly be invested in the project, able to make technical decisions as well as contribute code.
- kodablah 8y ago
  I completely believe that, but I also believe between Graydon originally and yourself, the role kinda exists :-) I meant to give Rust as an example of community-driven, not of the slow decision/implementation cost comment, but I can see how I wrote that wrong; that part was meant for the bikeshedding communities that fork in every direction. Maybe I should revise my statement to say strong leadership is ideal instead of a directionless community.
- sbjs 8y ago
  Community input is different though. Communities need a leader (or small set of leaders) who's responsible for judging whether something fits into the overall vision of the product. If a whole community agrees that something should be this way or that, then sure, that's darn good evidence that it's a good fit and probably inherent to the usefulness of the product, and it would be unwise for them to ignore it. But sometimes you have 50/50 splits and a leader is there to make the ultimate decision based on their expertise and understanding of the problem-domain and how the product fits into it.
  - pcwalton 8y ago
    That's why we have the small language teams who have to sign off on things. It's not democracy. I think the ideal situation is when the community develops a solution that works well for them and then leadership steps in to shepherd it through the integration process. Leadership isn't there to force their ideas onto the community. When done properly, everyone is empowered and nobody comes out of the process frustrated. This is something we have had to learn over time, but I truly think it is the right way to develop open projects like languages.
stcredzero 8y ago
the cohesion and gatekeeping provided by a quality BDFL is hard to match with a community There needs to be some thought leadership and gatekeeping, otherwise you get evaporative cooling, chaos, and devolution to the Least Common Denominator. All "leaderless movements" are subject to this. https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-cooling-of-group-beliefs https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporativ... The problem with BDFLs, is that when they're wrong, there is sometimes no pressure relief valve. Sure, some communities (e.g. the Rust one) show that a sole person need not reside at the top. But that often comes with slow implementation/decision costs. What you're describing is a republic. There is no dictator. There is no absolute ruler. However, there are democratically chosen leaders who need to make decisions that won't make everyone happy. Most importantly, there is no tyranny of the majority.

lifthrasiir 8y ago

> Of course, it requires thicker skin on both sides of the coin, but in hindsight the tech benefits often outweigh the politics. And this is exactly why the BDFL model is not sustainable in a longer term. I do agree that a consistent tie-breaker (a role of GvR, a stereotypical BDFL, was indeed much like this) is good to have, but a BDFL eventually becomes a venerable monarch whose everything become controversial enough to make one a political entity regardless of one's intention. As GvR shows this also puts a lot of burden to a single person.

crtc 8y ago

> But that often comes with slow implementation/decision costs. It also comes with feature bloat.

pcwalton 8y ago
No, it doesn't. "Feature bloat" comes from wanting to appease everyone by taking the union of all proposals. That is ineffective community governance: it comes from allowing people to say yes but not no to features. Believe me, people love to say no to features in Rust.

geodel 8y ago

And even in Rust earlier module system written by someone else and was dumped wholesale without enough justification to author who finally left frustrated. Same with green threads which at one point they were hell bent on adding and then one fine day decided to dump. Also leading to ban someone in Rust community who was against green thread. I think what people do not want to talk about or do not get is unlike Oracle, Google, MS or Apple Mozilla can't just add few dozen highly paid people for language development. So this big community led approach is more of practical matter than some enlightened way to develop software.

steveklabnik 8y ago
I think you have some of your story slightly wrong. There were two previous build systems before Cargo; both of the authors did leave Rust, for different reasons. I'm guessing you are talking about the second. I don't remember the exact details, and I thought that they left a year before cargo was announced...maybe I have rose-colored glasses. But with green threads, Rust had them for quite a while, on the order of years. I think the person you're talking about was in favor of the removal of green threads, which we were initially against, but it did end up happening. That person also left Rust but wasn't banned; we've only ever banned one person, and that was fairly recently, and it was for an extended harassment campaign, not over some sort of technical disagreement. > So this big community led approach is more of practical matter than some enlightened way to develop software. We believe that it produces better technical outcomes. Rust has more paid developers than many, many languages. Regardless, when making decisions, it's important to be informed, and there's no better way to be informed than to get a broad description of the problem space and other approaches to solving them. One person is never going to be able to be an expert in everything that a language needs. There's also sustainability concerns with BDFLs, but that's a larger topic.
pcwalton 8y ago
None of this is true. > And even in Rust earlier module system written by someone else and was dumped wholesale without enough justification to author who finally left frustrated. I don't know what module system you're talking about. The first Cargo was unmaintained for a long time before being removed; the original author was long gone. The second rustpkg was largely Graydon's work, not "someone else". > Same with green threads which at one point they were hell bent on adding and then one fine day decided to dump. Also leading to ban someone in Rust community who was against green thread. We dumped them in no small part because the community didn't want them! And nobody was banned. > I think what people do not want to talk about or do not get is unlike Oracle, Google, MS or Apple Mozilla can't just add few dozen highly paid people for language development. So this big community led approach is more of practical matter than some enlightened way to develop software. In other words, you're saying we treat the community as just free labor. That's an incredibly cynical accusation, and one that bears no resemblance to reality. I'm pretty confident in predicting that if Rust had adopted a BDFL style of governance, it would have been dead long ago. Community input was critical in decisions like removal of green threads and I/O reform that have helped Rust find its niche.

pcwalton 8y ago

Rust would have died if it used the BDFL model. We had a huge disadvantage starting out, with a tiny team at a smaller company and little name recognition among the lead developers. The only reason Rust achieved any popularity at all was that we listened to the community when they were pushing us to compete 1:1 with C and C++ on performance. Cargo likewise would have been terrible without community input. The community was starting hostile forks before we course corrected. Additionally, Rust development frankly moves faster than any other language that I know of. You need only look at the release notes for that. The reason is that people can truly be invested in the project, able to make technical decisions as well as contribute code.

kodablah 8y ago
I completely believe that, but I also believe between Graydon originally and yourself, the role kinda exists :-) I meant to give Rust as an example of community-driven, not of the slow decision/implementation cost comment, but I can see how I wrote that wrong; that part was meant for the bikeshedding communities that fork in every direction. Maybe I should revise my statement to say strong leadership is ideal instead of a directionless community.
sbjs 8y ago
Community input is different though. Communities need a leader (or small set of leaders) who's responsible for judging whether something fits into the overall vision of the product. If a whole community agrees that something should be this way or that, then sure, that's darn good evidence that it's a good fit and probably inherent to the usefulness of the product, and it would be unwise for them to ignore it. But sometimes you have 50/50 splits and a leader is there to make the ultimate decision based on their expertise and understanding of the problem-domain and how the product fits into it.
- pcwalton 8y ago
  That's why we have the small language teams who have to sign off on things. It's not democracy. I think the ideal situation is when the community develops a solution that works well for them and then leadership steps in to shepherd it through the integration process. Leadership isn't there to force their ideas onto the community. When done properly, everyone is empowered and nobody comes out of the process frustrated. This is something we have had to learn over time, but I truly think it is the right way to develop open projects like languages.

stcredzero 8y ago

the cohesion and gatekeeping provided by a quality BDFL is hard to match with a community There needs to be some thought leadership and gatekeeping, otherwise you get evaporative cooling, chaos, and devolution to the Least Common Denominator. All "leaderless movements" are subject to this. https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-cooling-of-group-beliefs https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporativ... The problem with BDFLs, is that when they're wrong, there is sometimes no pressure relief valve. Sure, some communities (e.g. the Rust one) show that a sole person need not reside at the top. But that often comes with slow implementation/decision costs. What you're describing is a republic. There is no dictator. There is no absolute ruler. However, there are democratically chosen leaders who need to make decisions that won't make everyone happy. Most importantly, there is no tyranny of the majority.