9 ms·

So they're moving to a new "community based", "light governance" model. [1] There are plenty of problems with BDFL-style projects, but I think there are a lot

• aboringusername 6y ago
  It's an interesting proposition. Whether it's Python, Redis, Laravel or Linux itself, a lot of software projects have been driven primarily by singular people and their decisions which shape the project over a period of time. One example that was mentioned in this thread was the whole "master" thing going on. Is Torvalds really going to get involved in that? Most likely no, and that's a decision he's free to make. I worry in the future, after he's gone, depending on the model being used, we'll see more politics in software projects where Linux itself gets dragged into these things and doesn't have a single guy to say NO! Or maybe you see an old white guy in charge of Linux and that can be considered a problem in itself, I'm sure many would love to see some change there and finally overrule Torvalds' decisions. So in reality, we're seeing a slow shift away from BDFL type situations, and in the near term future, very few (what I consider influential) projects will remain with that setup.
  • pjmlp 6y ago
    You already see this happening, on the IoT world there are plenty of competing FOSS OS clones, some of them POSIX based, common to all of them is the use of non-copyleft licenses.
    • ptx 6y ago
      How does copyleft relate to BDFL-style governance? Python, for example, had a BDFL until recently but isn't copyleft licensed.
      • pjmlp 6y ago
        Taking projects into new directions , possibly closed source, due to political disputes. Without the legal obligation to upstream, the majority wins what happens afterwards.
  • brobdingnagians 6y ago
    >> "old white guy in charge of Linux" Erhmmm, why does his age or colour matter in this context? Debate can happen about people and their leadership style, (I'm not a fan of Torvalds) but when the first criteria someone sees for criticizing another person is their age, colour, or race, that seems a bit shallow and biased.
    • deleted 6y ago
      [deleted]
    • throwaway894345 6y ago
      I agree. Isn't this overt racism, sexism, ageism, etc? > Racism: prejudice, discrimination, or antagonism directed against a person or people on the basis of their membership of a particular racial or ethnic group
      • jp_sc 6y ago
        Of course it is, but it's the kind of bigotry nowadays some people evangelize as good (by redefining racism), and what the twitter mob encourages.
        • patcon 6y ago
          Chain of events: I was tempted to try a respectful reply with substance, but then realized I wouldn't be allowed to discuss this here, due to moderator preference for "not talking politics". I was then [regrettably] tempted to write something with a "mic drop" feel, just to express my disagreement in an acceptably pithy way. And then it occurred to me that this whole sub-thread is Twitter-length comments. And I was about to add one more. And I realized that maybe the moderation of HN actually prevents us from going as deeply on this topic as we do on everything else, and so that moderator preference has essentially reproduced a pithy and unproductive Twitter dynamic for topics like this. Pithy and shallow self-censored comments in reply to pithy self-censored comments. EDIT: But also, moderation is really hard <3 Just wanted to try to put words to a small dynamic that's perhaps playing out here.
  • asguy 6y ago
    > I'm sure many would love to see some change there and finally overrule Torvalds' decisions. Is forking no longer a solution to this problem? Or are you just wanting to wrestle control away from Linus?
  • core-questions 6y ago
    > Or maybe you see an old white guy in charge of Linux and that can be considered a problem in itself Why is that a problem?
• 1_player 6y ago
  > There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. BDFL governance is extremely underrated in the opensource world. People attribute the success of the Linux kernel to its open contribution style, but I will argue that Linux is successful because there's a dictator at the top that enforces a direction, a long term goal, and most importantly, says NO. Community based governance is a direct cause of that jwz's Cascade of Attention-Deficit problem one can find all over the open source world, especially Linux desktop related.
  • sitkack 6y ago
    Does FreeBSD have a BDFL? We don't have enough data points to determine if what you are saying is correct. I have also seen lots of BDFL projects smoke out. Is the lesson that actual dictatorships only survive long term if 1) the dictator is a nice person and 2) they eventually get managed by an open democratic process? I think you are actually describing the two clocks problem. Lots of BDFL projects have their own Cascade of Attention-Deficit issues, the project only goes in the direction the BDFL actually cares about.
    • 1_player 6y ago
      A (software) dictator is not necessarily good. But let me double down and say that a community cannot create a product as good as a single head at the top can do, for the single reason that people care only about their own garden, and integration needs someone to oversee and be responsible for all parts. There is no Steve Jobs in a democratic committee.
      • mook 6y ago
        Cannot seems rather strong. I haven't been paying very much attention, but I was under the impression that Postgres doesn't have a dictator?
        • tragic 6y ago
          Or Rust, which - whatever you might think of it - does not feel very designed-by-committee.
• calpaterson 6y ago
  > The most important thing Antirez did, in my opinion, was to say "No" to things. No to new features that didn't make sense. Redis has had tremendous mission creep over the years. It started of course mostly as a volatile cache but I've now seen it also used as a message bus (in three different ways: BLPOP, PUB/SUB and Streams), for service discovery and as a general purpose database - something that Redis Labs (in my opinion: wrongly) encourages. Memcache existed in 2009 when Redis was first released, also as a volatile cache...and still is just a volatile cache. Memcache is what "saying no" looks like. Redis is what "saying yes" looks like - and there are a lot of gotchas.
  • xani 6y ago
    Well, kinda. Feature list does look like basically random assortment of vaguely related things (or "toolbox" if you want to be nice). But... things that are also just useful often and for what you'd need to spin off a separate service for, or make suboptimally in whatever (No)SQL you use to store your data. So it is perfect if you just want to prototype whether given approach is viable, and "good enough" for many apps.
  • derefr 6y ago
    Memcache is what saying no to changing the use-case looks like. Redis is what saying no to changing the architecture in order to implement features looks like. Redis has stayed the same, architecturally, from the beginning: it’s a keyspace where the values are arbitrary in-memory objects owned by their keys, and where commands resolve to synchronous function-calls against the objects (or ref-cells) at those keys. Anything that can be done without changing that architecture, is in-scope for Redis. (Though if a data structure doesn’t have wide use outside of a domain, it’s best left to a module.) Anything that cannot be done without changing the architecture, won’t be done. Much of the “fun” I’ve personally had in watching Redis evolve, has been seeing how Antirez has managed to solve the puzzles of getting features that intuitively wouldn’t be a good fit for this architecture, to fit into it anyway: changing technologies that are implemented one way everywhere else, into something else for Redis, that still work, are still performant, and still solve isomorphic use-cases—if not with the same steps you’d use to solve them in other systems. (E.g. using Streams vs. using a regular MQ; using Redis Cluster vs. using regular RDBMS replication; etc.)
• derefr 6y ago
  I feel like Antirez has already done everything needed to ensure this doesn’t happen, by 1. building the module system into Redis, and then 2. working with companies like Redis Labs to establish that Redis is enhanced through these modules, and to ensure that modules offer everything required to enhance Redis in all the ways that matter. In essence, Antirez has protected the core of Redis from needing to bloat, by making it possible for anyone who wants to build on top of Redis to literally do so—build on top, rather than inside. As such, I expect future PRs to Redis Core to look much like current PRs to Redis Core: just fixing bugs, adding stability, and resolving infrastructure-level interoperability concerns.
• neogodless 6y ago
  BDFL: Benevolent dictator for life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life (This is also referenced and linked in the article.)
• cletus 6y ago
  I 100% agree with you and I think it explains why most OSS UI projects are, well, terrible. Questionable features, inconsistent UX, millions of "options"... these are the hallmarks of a community model lacking strong leadership and a coherent vision. As for the future of Redis I choose to be more optimistic. I think the Redis philosophy (thanks to Antirez) has become ingrained. The benefits of a minimal feature set are hopefully well-established. In the very least I suspect this will last much longer than many expect before the bureaucrats take over.
• umvi 6y ago
  > The most important thing Antirez did, in my opinion, was to say "No" to things. This is hard. It makes you feel bad inside to tell people "No", especially when they open PR and clearly did a lot of work adding some feature.
  • makapuf 6y ago
    Thats something a have regarding PR and code reviews: much frustration can be avoided by discussing what to do and how to do it before showing the work done (avoiding also infinite bikeshedding). Often code review talk about the strategy to do X and not the way to do X
  • louthy 6y ago
    And some people take the 'No' badly. It's frustrating having to explain that the code in a PR needs to be maintained forever, and it's the repo maintainer that will have to do it, not the contributor. A simple proposal upfront makes all the difference, and saves human effort and feelings.
• dvirsky 6y ago
  The one drawback of the BDFL model is that you need a person, and a very specific kind of person at that, which tends to be irreplaceable - to sustain it. Redis has succeeded because of antirez. I really wish it can continue doing so for the long run without him. More than anything it reminds me of Steve Jobs' death (although gladly this is in much happier circumstances and I wish antirez many more decades of hacking). It's true that a decade later Apple is still doing great, but you just know things would have been different if he was still around.
• jffhn 6y ago
  >Saying no is one of the most important jobs of a project maintainer. It's a thankless task that upsets a lot of people. But it's critical for a project to stay successful and achieve the leader's vision. Reminds me of Brian Goetz: "We have to say no to almost anything. If we didn't, things would pretty quickly degenerate to the point where the system collapses on its own weight (...) if we did this, which of these eighteen possible features might we foreclose on, and might we want to leave those possibilities open, at the cost of saying no to this thing here." (https://www.infoq.com/presentations/java-history-present-future https://www.infoq.com/presentations/java-history-present-fut..., 24m+)
• albertzeyer 6y ago
  Instead of a single BDFL, you could also have a board of e.g. 3 BDFLs. Those 3 people would have the final word, but they rank equal, and have to come to a common conclusion, e.g. by discussing internally. That only works if the board is not too big, and the people are somewhat compatible to each other. But in that case, I think it works much better, because there is less pressure on a single person, also less work (they can distribute it somewhat), and probably more reasonable and consistent conclusions. It seems that this model is not so common? At least the list on Wikipedia (https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life) only lists Django as an example with 2 BDFLs. I was active in a smaller open source project (http://www.openlierox.net http://www.openlierox.net) where it mostly was like that, i.e. we were 3 main developers, and all major design questions were discussed among us. But this example is probably not so representative, as there rarely were further contributions by other people. But anyway, I was very happy with this model, that there is not a single leader, but 3 people.
  • philwelch 6y ago
    I think the mixed historical record of consul republics might be relevant to why a single leader is often a better idea than 2-3.
    • KajMagnus 6y ago
      I'm thinking that a project that starts out with 3 BDFLs (like yours, @albertzeyer) and works fine & builds sth people "love" — it'll continue working fine with those 3 BDFLs. And a project that starts with just 1 BDFL, and works fine & builds sth people "love", it'll continue working fine with that 1 BDFL. If, however, replacing one of those 3, or adding another BDLF to a one person project — I'd think that by default, that won't work. ... Unless the new person has worked next to the earlier BDFLs for years, so the previous BDFLs can be ok certain s/he is "the right one"? Whatever works fine, works fine — the risky thing, is introducing a change (a new person)?
      • philwelch 6y ago
• zebraflask 6y ago
  Do you have any tips for explaining to stakeholders that things in a Redis cache expire on async schedules?