3 ms·

History doesn't repeat itself, but it often rhymes

7 points by JoshTriplett 5y ago

jka 5y ago
"Proof of work" is the straightforward answer to this; not in the sense that it's used within cryptocurrency, but purely in terms of: does an individual contribute value and take on some/most of the effort to investigate and understand the issues they're assigned to (or volunteer for) themselves? If not, that's not necessarily a sign of malice -- patience and education are worthwhile and usually the answer, especially in calm times -- but if your organization is under time pressure (and has sufficient staffing capacity available) then proof-of-work can be a signal to aid allocation of focus/time (or to navigate away from a problem).
dane-pgp 5y ago
> 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. If I were going to sabotage Debian, I'd get a small team of ideological allies and work with them on some very complicated and technical component which outsiders couldn't readily understand, and we'd dismiss all external contributions as "not fitting the project vision". Any disagreement with the vision would be labelled as sabotage. The real trick is then making this complicated component "sticky", maybe including in it some useful tools which help solve some pain points of package maintainers so that they are happy to become dependent on it, while they turn a blind eye to all the complexity that it introduces elsewhere, because that's neatly filed away as "someone else's problem". Before long, the sabotage project will become effectively essential, with the saboteurs in charge of its direction, using it as a yolk or rudder by which to force more and more destructive changes into Debian. Then, eventually, you wouldn't even be able to install a printer in Debian without falling victim to the saboteurs. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863974 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863974
- JoshTriplett 5y ago
  > I'd get a small team of ideological allies and work with them on some very complicated and technical component which outsiders couldn't readily understand > we'd dismiss all external contributions as "not fitting the project vision". Many cite the project in question as something they understand better, that helps them manage systems better, and it has contributions from more than a thousand people. If I were going to sabotage Debian, I'd arrange for them to make a collective decision where they can't just say "let's do both"; evidence suggests that's worth at least a decade of infighting, and requires a relatively small group of folks committed to demanding support for their niche. Or, alternatively, I'd arrange for Debian to make enough "do all the things" decisions that its maintainers collapse under the weight of what they're collectively demanded to support.

7 points by JoshTriplett 5y ago

jka 5y ago

"Proof of work" is the straightforward answer to this; not in the sense that it's used within cryptocurrency, but purely in terms of: does an individual contribute value and take on some/most of the effort to investigate and understand the issues they're assigned to (or volunteer for) themselves? If not, that's not necessarily a sign of malice -- patience and education are worthwhile and usually the answer, especially in calm times -- but if your organization is under time pressure (and has sufficient staffing capacity available) then proof-of-work can be a signal to aid allocation of focus/time (or to navigate away from a problem).

dane-pgp 5y ago

> 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. If I were going to sabotage Debian, I'd get a small team of ideological allies and work with them on some very complicated and technical component which outsiders couldn't readily understand, and we'd dismiss all external contributions as "not fitting the project vision". Any disagreement with the vision would be labelled as sabotage. The real trick is then making this complicated component "sticky", maybe including in it some useful tools which help solve some pain points of package maintainers so that they are happy to become dependent on it, while they turn a blind eye to all the complexity that it introduces elsewhere, because that's neatly filed away as "someone else's problem". Before long, the sabotage project will become effectively essential, with the saboteurs in charge of its direction, using it as a yolk or rudder by which to force more and more destructive changes into Debian. Then, eventually, you wouldn't even be able to install a printer in Debian without falling victim to the saboteurs. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863974 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863974

JoshTriplett 5y ago
> I'd get a small team of ideological allies and work with them on some very complicated and technical component which outsiders couldn't readily understand > we'd dismiss all external contributions as "not fitting the project vision". Many cite the project in question as something they understand better, that helps them manage systems better, and it has contributions from more than a thousand people. If I were going to sabotage Debian, I'd arrange for them to make a collective decision where they can't just say "let's do both"; evidence suggests that's worth at least a decade of infighting, and requires a relatively small group of folks committed to demanding support for their niche. Or, alternatively, I'd arrange for Debian to make enough "do all the things" decisions that its maintainers collapse under the weight of what they're collectively demanded to support.