<!DOCTYPE html>
<html>
<head>
  <meta name="generator" content=
  "HTML Tidy for HTML5 for Apple macOS version 5.8.0">
  <title></title>
</head>
<body>
  <header>
    <a href="https://archiloque.net/blog/">Le blog d'Archiloque</a>
  </header>
  <main>
    <h1 id="articleTitle">Undesirable work & volunteer-driven Linux
    distributions</h1>
    <div id="content">
      <nav id="authors">
        <a href="https://twitter.com/archiloque">Julien Kirch</a>,
        December 5, 2022
      </nav>
      <div id="preamble">
        <div class="sectionbody">
          <div class="paragraph">
            <p>When I worked in a team or an organization where a
            level of self-organization was possible, the most
            complicated question was often “How to deal with the
            undesirable work?”.</p>
          </div>
          <div class="paragraph">
            <p>Unsurprisingly, since consent is an important topic
            for them, anarchists have written a lot on it. There
            have been practical answers like the best way to divide
            it between people, and <a href=
            "https://theanarchistlibrary.org/library/lee-shevek-who-has-to-do-it">
            more long-term theoretical ones</a>.</p>
          </div>
          <div class="paragraph">
            <p>I was thinking about how this question can be
            applied to open source, and specifically to
            volunteer-driven Linux distributions.</p>
          </div>
          <div class="paragraph">
            <p>By volunteer-driven Linux distributions I mean the
            Linux distributions where the bulk of the work is
            provided by volunteers that freely choose what to work
            on (like Debian and Arch Linux), as opposed to Linux
            distributions where the bulk of the work is done by
            people directly or indirectly paid by customers (like
            Red Hat Enterprise Linux or SUSE Linux Enterprise),
            which means they have less leeway when choosing what to
            work on.</p>
          </div>
          <div class="paragraph">
            <p>Some Linux distributions are harder to categorize
            than the one given as example, but my point here is not
            about being able to precisely group all of them but
            about the relations between users and contributors.</p>
          </div>
        </div>
      </div>
      <div class="sect1">
        <h2 id="_work_so_much_work_to_be_done">Work, so much work
        to be done</h2>
        <div class="sectionbody">
          <div class="paragraph">
            <p>Most volunteer-driven Linux distributions have many
            more users than people providing work. Efforts are made
            to transform users into contributors, but even if these
            efforts are successful, the imbalance will probably
            keep existing because of the specialized skills that
            are required for some of the tasks like development or
            user interface design.</p>
          </div>
          <div class="paragraph">
            <p>So you have lots of people using a software
            component, and a lower number of volunteers working on
            it.</p>
          </div>
        </div>
      </div>
      <div class="sect1">
        <h2 id="_all_work_and_no_play_makes_jack_a_dull_boy">All
        work and no play makes jack a dull boy</h2>
        <div class="sectionbody">
          <div class="paragraph">
            <p>Some of this work to be done is fun, or more
            precisely some of the work is seen as desirable by a
            significant proportion of the volunteers able to
            contribute to it. The precision is important, because
            not everybody enjoys the same things, and even a single
            person doesn’t always want to do the same kind of work
            all the time.</p>
          </div>
          <div class="paragraph">
            <p>But some parts tend to attract less people than
            other ones, which means there is undesirable work to be
            done, and it can even be a bottleneck for the project.
            Two common examples I have seen are bug triaging and
            investigating problems that happen on uncommon
            hardware.</p>
          </div>
          <div class="paragraph">
            <p>The part that fascinates me is how to deal with the
            demands of the users that are not contributors that
            require undesirable work, in a setup where people
            freely choose what to contribute to.</p>
          </div>
          <div class="paragraph">
            <p>A sad element of volunteering for open source is
            that even if users are not customers and know that the
            work of volunteers is done in their free time, they can
            act like paying clients with a for-profit company.</p>
          </div>
          <div class="paragraph">
            <p>It can be even worse because sometimes users can try
            to use guilt or other emotional tricks to manipulate
            the volunteers into doing what they ask, or to punish
            them when they can’t have what they want, for example
            lamenting angrily that they are forced to use a
            proprietary solution unless their demands are met.</p>
          </div>
        </div>
      </div>
      <div class="sect1">
        <h2 id="_from_reasonable_to_not_reasonable_at_all">From
        reasonable, to not reasonable at all</h2>
        <div class="sectionbody">
          <div class="paragraph">
            <p>And all demands are not equal.</p>
          </div>
          <div class="sect2">
            <h3 id="_visible_changes">Visible changes</h3>
            <div class="paragraph">
              <p>For example a crash that is preventing the default
              web browser to start would probably be seen as
              important so contributors would probably fix it as
              quick as they can, even if investigating bugs can be
              seen as undesirable.</p>
            </div>
            <div class="paragraph">
              <p>Asking for a new feature to be developed for a
              specific case would probably be seen as less
              important, especially if the feature is seen as a
              corner case and if lots of work is required.</p>
            </div>
            <div class="paragraph">
              <p>But in these two cases, the required change is
              making a visible difference for the users.</p>
            </div>
          </div>
          <div class="sect2">
            <h3 id="_and_the_other_ones">And the other ones</h3>
            <div class="paragraph">
              <p>And then there are the other situations, for
              example when the user wants a change is ideologically
              based. I don’t think that ideological criteria are
              irrelevant: ideology is one of the big reasons that
              people contribute or use open source. I’m using this
              term to be able to differentiate the two types of
              changes.</p>
            </div>
            <div class="paragraph">
              <p>The first example, which I already wrote about
              <a href="../systemd-linux-open-source/">here</a> in
              French, is Systemd, which is a family of components
              that you can use to manage lots of the grunt work
              required to run Linux on a machine, like dealing with
              starting and stopping other components.</p>
            </div>
            <div class="paragraph">
              <p>Systemd’s approach is disliked by many Linux
              developers. On the other hand, Systemd provides a
              standardized way to do things that before it tended
              to be different between Linux distributions.</p>
            </div>
            <div class="paragraph">
              <p>Without Systemd, the people in charge of
              integrating software components into a Linux
              distribution (which are called “packagers”) often
              needed to write or customize some scripts to make it
              work. These scripts were often very similar but not
              identical. And when a new version of the software was
              released, updating the scripts was sometimes needed.
              It means it is a good example of an undesirable
              task.</p>
            </div>
            <div class="paragraph">
              <p>With Systemd, the software developer can provide
              scripts that should work as is for all distributions
              that use Systemd. Which means all this part of the
              packager work would disappear.</p>
            </div>
            <div class="paragraph">
              <p>The discussions about Systemd were heated. Some of
              them were ideological and others involved real
              technical problems or limitations of Systemd. But I
              was really surprised how few of them mentioned the
              “it can reduce undesirable work done by packagers,
              which is a bottleneck for our project” argument.</p>
            </div>
            <div class="paragraph">
              <p>I don’t mean that maintainers workload should be
              the only and single criteria — because there are
              probably case where following it would be the wrong
              choice — but I think it should be heavily taken into
              account.</p>
            </div>
            <div class="paragraph">
              <p>And asking for someone for more free contributions
              should not be asked lightly: I can’t imagine how it
              felt for maintainers to be pressured like that.</p>
            </div>
            <div class="paragraph">
              <p>But at least in this case, there was an
              alternative available.</p>
            </div>
            <div class="paragraph">
              <p>The more extreme option is when it’s not the case,
              for example <a href=
              "https://lwn.net/Articles/912202/">when you want to
              use a specific tool, not because you love it, but
              because there is no adequate alternative
              available</a> (in this case, it’s about a tool
              written in Rust which is still an open and
              controversial subject). Again the discussions have
              technical aspects that must be addressed. But I’m
              surprised that people can say no to a proposition
              when there is no alternative.</p>
            </div>
            <div class="paragraph">
              <p>What should the contributors do in this case,
              write a new tool that matches the requirements
              decided by others? Again I can’t imagine how they
              feel in this situation.</p>
            </div>
            <div class="paragraph">
              <p><em>Technical note: I wonder if the “we need to
              replace an outdated C unmaintained implementation by
              an up to date and maintained Rust version” will
              happen more and more, because on one hand it would
              help to increase Rust adoption, but on the other hand
              it could also make some people feel cornered, which
              has often nasty consequences down the road.</em></p>
            </div>
          </div>
        </div>
      </div>
      <div class="sect1">
        <h2 id=
        "_what_is_to_be_done_dont_forget_that_maintainer_are_people">
        What is to be done? Don’t forget that maintainer are
        people</h2>
        <div class="sectionbody">
          <div class="paragraph">
            <p>The solution is obvious, but of course it’s not a
            single bullet: the effort provided by maintainers
            should be taken into account in a better way, in the
            way choices are made but also in the way choices are
            discussed.</p>
          </div>
          <div class="paragraph">
            <p>Again I don’t think that it should be the single
            criteria to use, but it should probably be used
            more.</p>
          </div>
          <div class="paragraph">
            <p>More precisely, it should be used more explicitly.
            Because from what I understand, even if it’s not
            explicitly mentioned, it’s often taken into account
            implicitly, because when a decision is taken that
            frustrate the contributors, contributors
            can — voluntarily or not — not do the work that is
            asked to them.</p>
          </div>
          <div class="paragraph">
            <p>So it should be used more because it may increase
            the odds that the decisions are applied.</p>
          </div>
          <div class="paragraph">
            <p>But also it should be used more because it would be
            the right thing to do: people volunteer to work without
            being paid. Their effort should be treated with
            respect.</p>
          </div>
          <div class="paragraph">
            <p>Because if open source software can be created
            without respecting the people who work on it, it
            wouldn’t have the high moral ground it’s supposed to
            have.</p>
          </div>
        </div>
      </div>
    </div>
  </main>
  <nav id="navBottom">
    <a id="previousArticle" href=
    "https://archiloque.net/blog/development-w40k/">← Why Warhammer
    40,000 is a good metaphor for software development</a>
  </nav>
  <footer>
    <ul>
      <li>
        <a href="https://archiloque.net">Homepage</a>
      </li>
      <li>
        <a href="https://archiloque.net/blog">Blog</a>
      </li>
      <li>
        <a href="https://archiloque.net/weekly">Chosen Links</a>
      </li>
      <li>
        <a href="https://tinyletter.com/archiloque">Newsletter</a>
      </li>
      <li>
        <a href="https://twitter.com/archiloque">Twitter</a>
      </li>
    </ul>
  </footer>
</body>
</html>
