1. 24
  1.  

  2. 8

    Technical disagreements in other projects lead to people being excluded. On the other hand, the Linux kernel manages to embrace incredibly diverse goals and viewpoints - from tiny devices to amazing supercomputers. The cost seems to be painful interactions. It’s great that these discussions are happening as this cost might not be necessary and certainly should be reduced.

    Let’s not forget that the Linux kernel is one of the most successful and largest collaborative works ever created by humans. The humility of the kernel maintainers, who admit defects in - and seek to improve - their process, is an example of the excellence of the culture.

    1. 5

      I think there are a few different things at play:

      • Some people consider working on open source some kind of social happening, others work on technical stuff precisely because they are uninterested in it.
      • In many places, what you leave out matters much more than what you put in. Some people tend to take it personal if their feature gets rejected.
      • The amount of people who are capable and interested in ensuring that contributions live up to the requirements are far and few between, and it’s generally a thankless job.
      • It takes a lot of effort to get things right, but no effort to get things wrong.
      • More often than not the person who wants to add a feature is nowhere to be found when it comes to maintaining it.
      • Many maintainers who make contributors redo their patches over and over are not interested in wielding power, but believe that avoiding to inflict pain on actual users (if a feature is shipped in a broken state) is more important than the hurt feelings of a contributor (who felt that the proposed feature was good enough for his purposes).
      • While there are topics–like performance–where changes can easily measured and accepted/rejected based on that, there are equally important topics–like user experience–where it is hard to quantify the impact of a change. “This change makes the lives of every user worse”–even if perfectly accurate–tends to make the person who cares about user experience look bad, not the person proposing the change.

      That’s my experience from working more than half a decade on Scala. It might provide some insight why the project is hemorrhaging contributors who cared about quality and user experience (apart from the harassment issues).

      1. 2

        It is unclear which project you refer to, when speaking about hemorrhaging contributors, is it Linux or Scala?

        1. 1

          Scala.

      2. 3

        It’s good to see a lot of communities actively thinking about the social nature of open source, on all sides of the interactions.

        A lot of older projects can end up being hard to contribute to for a lot of reasons, and it’s easy to work on something and then realize “oh only like 20 people even get how any of this works now”. Having an environment for drive-by contributions is excellent for getting new blood (though there’s other stuff involved there too)

        1. 1

          Are there other kernels that have a better culture, and are easier to approach if one would like a chance to work at this level? One of the BSDs? Something springing from L4 somewhere I don’t know about? Haiku? ReactOS? Something more esoteric? That Rust one whose name escapes me right now?

          1. 5

            Linux is so unique in its development style and pace that I think most of those comparisons are misleading. There are probably less than 5 or 10 projects you can compare Linux too, and even then it’s hard to.

            Something like L4 is done by a small group of people, who probably have physical contact with each other. It’s more like Google’s Fuschia than Linux. Likewise with Minix – it’s a relatively small group of people and thus cohensive, at least compared to Linux.

            As far as I understand, FreeBSD is the “biggest” of the BSDs. Not sure if that means it has the most developers. But I would guess that Linux has 10x the developers of the next biggest one. And the developers come from 10x more diverse institutions (corporations, etc.)

            This is my informal sense of things; I’m sure there are numbers, and if anyone has them I’d appreciate it. But I’d be surprised if the pace / #developers isn’t at least 10x, even 100x.

            Redox OS is the Rust one. I only know a little bit about it, but it also has the property of being nascent, which will make for a very different culture than Linux. There is a lot “at stake” in Linux, hence the disagreements.

            Also, for better or worse, almost all the projects you mention are kernel + user space, not just a kernel.

            1. 1

              I don’t mean “I want to make value judgements about which communities are better because they deal with more stuff”, I mean “I would love to hack on kernels but want no part in this kind of environment, where should I go?”

              1. 2

                I haven’t hung out here myself, but I’ve heard good things about: https://wiki.osdev.org/Expanded_Main_Page

            2. 3

              This is a good time to shill my favourite project (It’s NetBSD, and has great culture), but to be honest - I don’t know many projects with governance as insane as Linux. Even in the article, Daniel Vetter refers to group maintainership and handing out commit access as “more like a standard project”.

              I’ve seen people who had potential to be toxic maintainers that drive away contributions but their impact was limited by them not having absolute power.

              Also, by having a very weak hierarchy, nobody is immune from being kicked from the project. Toxicity will get you pulled aside and have someone ask you to stop/apologize, continuing will result in being kicked from the project, and I’ve seen it happen in practice.