A second thought now, newly surfacing in the wake of the Wordpress fiasco and the emerging Ruby gems crisis:

We should pay a lot more attention to the •human system• dependencies we’re introducing when we import a library, not just the code.

2/

The excellent @kissane (https://erinkissane.com) and @jenniferplusplus (https://jenniferplusplus.com/) have written a lot about the idea of “governance” in tech: the human networks and processes that surround the things that we build. Erin has proposed — and I agree, though I long failed to see it! — that governance is the gaping hole in the way we build OSS, shared infra, and the whole technology commons.

3/

Any developer worth their salt knows that the outputting code is the easiest part of software development, and that code as an artifact has little value without everything that surrounds it: the people, the shared knowledge, the practices (both formal and informal), the infrastructure, the networks of trust, etc etc.

And yet!! like fools, we’ve got ourselves hung up on OSS licenses and copyright — the legal structures surrounding the code itself — as if code were in fact the only thing that really matters. As if we didn’t know better.

4/

There are light years between (1) “I thought this code was useful, so I shared it online and slapped an OSS license on it” and (2) “We set up a foundation to fund ongoing maintenance of this critical OSS project while guaranteeing its independence.”

The “dependency, fork, or rewrite?” question looks very, very different for (1) vs (2).

Yet how many of us think about where any given library dependency sits on that continuum when we add a dependency? Even if we try, how can we ••tell••?

5/

I’d venture that the situation depicted in the classic and obligatory xkcd on the topic (https://xkcd.com/2347/) is rooted in the failure to distinguish (1) and (2).

So is a lot of OSS burnout: somebody shares something cool in the spirit of (1), maybe even tries to be a good individual steward of it, and next thing you know people are beating down their door with demands and complaints as if they are (2).

6/

Somebody (maybe it was Erin? can’t remember) proposed that we should have a menu of governance structures just as we currently have a menu of OSS licenses, crafted with the same care and granted the same importance, so that somebody looking to share code can:

- communicate very clearly where they are on that continuum from “Here’s some cool code, maybe it’s useful” to “There is solid, sustainable human infra behind this code,” and

- get guidance and support so that, as their project grows, it moves smoothly along that continuum of governance.

7/

That’s a really hard problem, and not one that will be solved in my ad hoc Saturday posts (or in my replies). I have no answers. I do however have one model to study, which is this org my dad helped found:

https://www.wildernessalliance.org

They help people set up local wilderness stewardship volunteer groups. (There’s a wilderness area near you! You want to help take care of it! How do you do that? What is actually helpful?? What are models and best practices??? Where do you even start????)

8/

How do they do this?

They don’t just slap some guides online and call it a day.

They run trainings. They hold conferences. They get people talking. They do an •unimaginable• amount of work building relationships, talking to people, learning about needs, learning about successes, sharing, trying to make what works reproducible.

It is significant ongoing human labor. That’s something we software folks (especially in OSS) have been tragically dismissive of, allergic to. We’ve got to get over it.

9/

The longtime appeal of the BDFL (“benevolent dictator for life”) model of OSS governance comes in part from the fact that most projects naturally start there — “here’s some cool code” — and partly in our impostor-phenom-driven culture of hero worship, but…

…it also comes from our dev culture allergy to taking human systems seriously.

10/

The idea that having a benevolent dictator forever is actually a good idea? That’s a nonsense thought rooted in the feeling that all this human stuff •isn’t even a real problem•: mushy nonsense, female-coded and thus low-status, can’t we just build good technology all day and not think about people.

(No, dumbass, you can’t, not if you actually want it to be good.)

11/

My dear fellow developers, is there any single phrase that makes you want to just punch someone faster than “Can’t you just…?”

NO, WE CAN’T JUST. THIS PROBLEM IS ACTUALLY HARD, AND YOU ONLY THINK IT’S EASY BECAUSE YOU DON’T EVEN •SEE• THE PROBLEM IN THE FIRST PLACE.

The BDFL model of OSS governance is •us• saying “Can’t you just…?”

Sorry. We’re doing it too. Sorry to break it to you.

12/

One of the obligatory classics on the general topic, ht @carto:

https://mastodon.online/@carto/115237953550201658

13/

Another classic, ht @cratermoon. At first pass, this appears to be a purely technical description of a surprising attack — and then his closing remarks focus more on the then-nascent cultural and legal context of cybersecurity concerns.

But lurking underneath his remarks is this crucial insight: you can’t ever just trust •code• when you’re writing software; at some level, you also have to trust •people•.

https://zirk.us/@cratermoon/115237945294118620

14/