• History doesn't repeat itself, but it often rhymes

    From Paul Tagliamonte@21:1/5 to All on Tue Feb 22 18:40:01 2022
    XPost: linux.debian.project

    Hello, Debianites,

    Allow me, if you will, to talk a bit about something that's been on my mind
    a bit over the last handful of years in Debian. It's something that's pretty widely circulated in particular circles, but I don't think I've seen it on
    a Debian list before, so here's some words that I've decided to put together.


    I've intentionally not drawn lines to the 'discussions' going on (or the 'discussions' in the past I could point to) to avoid getting dragged into more thrash, so if you reply, please do try to keep this clear of any specific argument that you feel this may or may not apply to. This is a more general note that I think could use some thought from anyone who's interested.


    During World War II, the OSS (Office of Strategic Services)[1] distributed a manual[2] (the Simple Sabotage Field Manual), which was used to train "citizen-saboteur" resistance fighters, some of whom were told, not to pick up arms, but to confound the bureaucracy by tying it up with an unmanageable tangle of "innocent" behavior.

    While no one is working within the Debian community member attempting to subvert us sent from the shady conglomerate of nonfree operating systems by following this playbook, this playbook is an outstanding illustration of how some innocent behavior can destroy the effectiveness of an organization. It's effective, precisely *because* it's not overly malicious, and these behaviors -- while harmful -- are explainable or innocent. Section (3) covers this in detail.

    Most of the OSS Simple Sabotage Field Manual covers things like breaking equipment or destroying tanks, but section (11) is "General Interference with Organizations and Production". I'm just going to focus here.

    Let's take a look at section (11):

    (1) Insist on doing everything through "channels." Never permit short-cuts
    to be taken in order to expedite decisions.

    (2) Make "speeches." Talk as frequently as possible and at great length.
    Illustrate your "points" by long anecdotes and accounts of personal
    experiences. Never hesitate to make a few appropriate "patriotic" comments.

    (3) When possible, refer all matters to committees for "further study and
    consideration." Attempt to make committees as large as possible -- never
    less than five.

    (4) Bring up irrelevant issues as frequently as possible.

    (5) Haggle over precise wordings of communications, minutes, resolutions.

    (6) Refer back to matters decided upon at the last meeting and attempt to
    re-open the advisability of that decision.

    (7) Advocate "caution." Be "reasonable" and urge your fellow co-conferees to
    be "reasonable" and avoid haste which might result in embarrassments or
    difficulties later on.

    (8) Be worried about the propriety of any decision - raise the question of
    whether such action as is contemplated lies within the jurisdiction of
    the group or whether it might conflict with the policy of some higher
    echelon.

    I won't go through each of these point-by-point since everyone reading this is likely sharp enough to see how this relates to Debian (although I will point out I find it particularly interesting to replace "patrotic" here with the Debian-specific-patriotism -- Debianism? -- and re-read some of the more
    heated threads)



    I have a theory of large organizations I've been thinking a lot about that came from conversations with a colleague, which is to think about an organization's "metabolic overhead" -- i.e., the amount of energy that an organization
    devotes to intra-organization communication. If you think about a car manufacturing plant, the "metabolic overhead" is all the time spent on things like paperwork, communication, planning. It's not possible (or desirable!) for an organization to have 0% overhead, nor is it desirable (although this one *is*
    possible) to spend 100% time on overhead. I think it *may* be possible to get to above 100% overhead, if workplace contention spills out into drinks after work.

    All of the points in the OSS Simple Sabotage Manual are things designed to increase the metabolic overhead of an organization, and to force organization members to spend time *not* doing their core function (like making cars, running trash pickup or ensuring the city has electricity), but rather, spend their time litigating amongst themselves as the core function begins to
    become harder and harder to maintain. This has the effect of degrading the output/core function of an organization, without any specific cause
    (like a power loss, etc).

    I'd ask those who are reading this to consider how this relates to their time spent in Debian. Is what you find something you're happy about with a hobby project you're choosing to spend your free time on? Are you taking actions to be a good participant?



    To do a bit of grandstanding myself, do remember that it's not just your time here -- when we spend significant resources litigating and playing bureaucracy games, we spend others' time as well. People on the committees you refer matters
    to, all project members in the case of a GR, all the Mailing List readers -- and that's all time that is taken from building and maintaining an operating system. The output becomes degraded. There's no specific acute cause like
    a buildd failure.

    When I think about how Simple Sabotage works, I find myself unable to shake the feeling that the best way to combat the organizational dysfunction outlined in the OSS's Simple Sabotage Manual is to avoid "taking the bait", and to ensure small, highly empowered teams of do-ers are able to execute. We need to avoid being dragged into development by consensus -- while understanding that communication and collaboration are good. We need to ensure that individuals that continue to exhibit the behaviors contained within the Simple Sabotage Manual understand the harm that can come from a system of individuals taking actions like them -- even if their intent is sincere and come from a constructive, helpful place. In some cases, ignoring the "sabotage"[3] outright will work, in other cases, perhaps a gentile and respectful private note letting them know that their suggestion is actively harmful and to consider not doing it again. Engaging publicly makes things worse, since it will continue to suck people's time into litigating the "sabotage" (which is, itself, becomes "sabotage").

    Taking an expensive action (like referring to a committee, re-opening an
    old decision, arguing about the precising wording and associated pedantry,
    and questioning the authority of those doing work) should only be done
    if the cost outweighs the benefit.

    We don't need to be hostile or expel people for doing things outlined in the OSS Simple Sabotage Manual, since a lot of that behavior is -- at times -- desirable, but I think we do need a *LOT* of self-reflection (from *everyone* who actively engages with Debian politics) to consider our actions, and determine how (if at all) we feel that we (as individuals) should change.

    Please don't beat eachother up with this calling each other saboteurs and claiming that everyone's emails are "sabotage", but please do consider
    using this mental framework when looking at our discussions from time to
    time.

    With love!
    paultag


    [1]: Of its many notable members, Julia Child was the first one I think
    of -- yes, that Julia Child!
    [2]: https://www.gutenberg.org/files/26184/page-images/26184-images.pdf
    [3]: //maybe// not the best word, but I'm using it here for internal consistency

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Carter@21:1/5 to Paul Tagliamonte on Tue Feb 22 19:20:01 2022
    Hi Paul

    On 2022/02/22 19:29, Paul Tagliamonte wrote:
    We don't need to be hostile or expel people for doing things outlined in the OSS Simple Sabotage Manual, since a lot of that behavior is -- at times -- desirable, but I think we do need a*LOT* of self-reflection (from*everyone* who actively engages with Debian politics) to consider our actions, and determine how (if at all) we feel that we (as individuals) should change.

    Thanks for that mail, it was an interesting read and I think I'll try to
    get a copy of that manual!

    As for the paragraph quoted above, I do think we need to deal with
    people who are indistinguishable from a saboteur. I value my time a lot,
    and also of those who spend all their love and energy and years of their
    lives into this project, so I find it incredibly offensive when someone
    comes and things that it's their god given right to piss all over it and
    keep wasting everyone's time.

    As a courtesy, I think it's fine to tell them that we find that behavior problematic, and that they should stop it if they wish to remain part of
    the project. But failing that, whether I'm DPL or not, I will strongly
    campaign with DAM or whoever makes those kind of decisions to kick them
    out. If we have leadership that can't take those kind of decisions then
    I'd rather not be part of Debian at all.

    -Jonathan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)