I’ve watched the pendulum swing back and forth multiple times in my career between “code reuse ftw!!” and “no dependencies!!” The one thing I can say with confidence is that both those extremes as dogma are ridiculous and costly. It’s all tradeoffs; you can’t escape the part where you think carefully and contextually.
The excellent @kissane (https://erinkissane.com) has 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.
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.
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••?
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).
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.
That’s a really hard problem, and not one that will be solve 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:
They help people set up 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????)
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 too. We’ve got to get over it.
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.
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.)
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•.
Aha!!! This is one of the pieces I was trying and failing to think of upthread, from the always excellent @jenniferplusplus (and I’m embarrassed that I couldn’t bring it to mind earlier, sorry Jennifer):
@paul_ipv6 In the case of OSS, it’s very often more like “truly well-meaning person whose personal project grew large while they remained in charge of it.” Doesn’t matter; it’s always unsustainable.
@inthehands Sometimes it seems like a BDFL situation is someone getting a tiny little bit of power over their corner of the universe and not wanting to give that up, no matter the cost.
@inthehands I linked to an article from tidelift in that post, as part of a discussion that money is at best part of the solution, and would just exacerbate the problems in isolation.
That link now redirects to sonar source, because they bought tidelift. I think rereading that section with that context really accentuates the point
@matthewskelton I’m really glad to hear people introducing the idea of stewardship in more contexts. I’m sure the word will get flattened if / as soon as it’s more widely used, but we have to keep trying anyway!
@inthehands this is superb - thank you! I find the whole concept and practice of stewardship crucial to any sensible approach to software and (well) anything really.
Feels like something like 'continuous stewardship' is a key concept we need...
@inthehands Maybe one of the positive side effects of recent EU regulations on software liability will be to have these communications and make the context clear to everyone, between "this software is provided AS-IS with no warrany whatsoever" and "this software is part of a critical supply chain" so that the ecosystem of the latter is likely to set up the Foundation and related income stream for the primary maintainers, because the downstream who incorporates the software into their product is liable in the first case, but if they pay the Foundation they can shift liability to that, and in doing so provide the Foundation the resources it needs to be a steward of the software. Neat trick, if it works.
@thomasfuchs FWIW, I did a quick scan of Ruby and JS projects on my machine (mix of client work, personal projects, student projects, and OSS stuff I have locally cloned) and got a line count of the lock files (which is a rough proxy for # of dependencies).
Ruby was mean 72, median 37, max 671. (Rails apps tend to be in the low hundreds.)
@bradr I saw a lot of unhelpful gear-grinding in the late 90s and early 00s when companies •tried• to make this conversation cross-functional without knowing how: managers jittery about whatever random thing they heard about OSS in the Gartner-world chatter, engineers angry that they can’t just use the thing that fixed the problem •now•, nobody really asking the useful questions about what the ongoing maint work of adopting or not adopting some library actually looks like.
We should pay a lot more attention to the •human system• dependencies we’re introducing when we import a library, not just the code.
For big-co environments: This is also a great argument for making the conversation about dependencies broadly cross-functional, and up and down the organization, rather than a silo'd intra-engineering conversation about whether to "buy or build".
@pintoch@kissane@jenniferplusplus I think having some off-the-shelf recipes is a good idea as far as it goes, but it’s at best a tool and not a whole solution. See what I wrote in the thread about the National Wilderness Stewardship Alliance and what their real work consists of. Recipes could be a great part of some larger thing along those lines.
@inthehands@thomasfuchs In the interests of fairness: do ruby apps tend to include dev dependencies at the local level, or do they lean global for that? Because that could really pad things out. (A quick check of php on my system, via composer.lock, suggests that it is somewhere in between the two you've checked, but I also have concerns that the format of each lang's lock file impedes true comparison)