Few-Maintainer Projectsreality-driven expectations
I’ve only just got around to Nadia Eghbal’s “The rise of few-maintainer projects” for Stripe’s Increment journal. Great stuff. If you read this blog for open source, you should really read Nadia’s post, and a few of the things she cites, not to mention a ton of her other writing.
Nadia’s point, as I read it, is that we ought to recognize that most open software projects are small open software projects, bound together more by interoperability than direct working relationships, and adjust our project expectations and problem approaches accordingly. Adding some gloss, it’s not a case of a thousand tiny modules hoping they’ll grow up to be Linux. Small things are small, they’re proliferating, and they fill key niches for oodles of users.
It’s an angle I tend to like, because I’ve done most of my open work in small-modules systems. The contrary mentality, which arises more readily from monolithic-project experience, stands no less valid. But we all have our biases, and lots of small bits working together is mine.
When abundant components can be readily snapped together extemp, thanks to strong prevailing conventions, there’s less chance that someone else will do the work of packaging up a cohesive solution for you, just as you’d want it done. But if you invest in learning the conventions yourself, what could have been a free solution if you were lucky becomes a free toolkit instead. It’s on you to do your own integration work, but you can do that work in the way that best suits your needs. You can build things nobody else would bother to maintain for you, things nobody else would have thought of.
A severe downside of this kind of arrangement is the relatively narrow, estranged ways contributors tend to collaborate. When a library “has one contributor”, that doesn’t capture the enormous value of underlying work, like the language, or potentially overlaying work, like applications that inspired the creation of the library in the first place. Massive collaboration of a thoroughly novel, rarefied sort may well be occurring. But while the work of many developers may have gone into a small artifact with one name on all its commits, none of those folks may have so much as traded a text message.
Rather than a free-flowing exchange of writing, conference convos, and dial-in meetings, the meaningful “collaboration” behind even significant projects can boil down entirely to take-it-or-leave-it search, discovery, and adoption of other people’s work. Ongoing coordination may be more a matter of version conventions and changelogs than anything approaching human relationships with all their glorious and terrible “statefulness” and “side effects”.
In brief: The more conventions do for us, the less we do for ourselves, and the less we do and experience together. It’s fundamentally depersonalizing, as industrial productivity often is.
Without conscious effort to repersonalize the work, and the means to do so, the same conventions that empower us practically can blinker us dangerously. In my experience, small-modules hackers—myself sadly included—tend to be ready, willing, and able to talk about how tools, infrastructure, platforms, and other things made of software affect how software developers get along. But we’re often simply unwilling to recognize those issues as policy issues, and therefore potentially political issues, with overarching people purposes and underlying people causes.
The big-project, governance-and-process devs that I know also tend to stick to the software comfort zone by preference. But in my experience, they’re more willing, and better equipped, to recognize and address people problems as such. They have to. They’re constantly stepping all over each other to get stuff done in big, bureaucratized projects. Many of them work for big, bureaucratized companies.
Maybe we need more big-project people with small-modules experience. Maybe we need more small-modules people willing to be the life of the code party. But I tend to think what we really need, to see our way around the problems we’re facing now, is more folks of neither easy description. People who’ve surpassed their initial experiences, or had broad enough exposure, that the either-or proposition of big or small holds no sway. A more enlightened breed of participant who sees the choice as false.
Your thoughts and feedback are always welcome by e-mail.