de facto vs de jure maintenance
Some thoughts on cowboys vs conservatorships after reading De-facto closed source: the case for understandable software. I can’t say I disagree with anything there. Software is too complicated and should be simpler. There is, however, an angle which wasn’t examined. Or at least an alternative that wasn’t fully explored, which is to trust authors in a way which works.
The original problem (or one of them) is the result of a fiercely independent code slinging cowboy distribution model. You write some code, toss it on the tubes, people use it, and then... you move on and hand your star over to somebody else. The de jure maintainer has changed. There’s no continuity.
Another model is to place the code in a conservatorship. Like a curated list of awesome, except actually curated. When the original author steps away, nothing changes. The de jure maintainer is the same. Continuity.
There are many examples of such conservatorships, although we rarely use the term. We might consider the OpenBSD project. Some time ago, Sylvestre wrote and contributed a fuse implementation. Then life moves on, as it does, and so did he, leaving the code without a direct maintainer. But OpenBSD didn’t just hand the code over to somebody else. It’s still ours, even if we could be doing a better job improving it. To be completely honest, although it gets the occasional commit, it may be close to de facto unmaintained. The important fact, however, is that it’s de jure maintained. Users of the fuse code can trust that it won’t get randocoined.
This isn’t an all or nothing proposition. Handing over maintenance doesn’t require assigning copyright. The code is still open, it can be forked out of the conservatorship at any time. And in exchange, there are other people to help fix bugs and answer questions when you go on vacation. You’re not trapped working on a project you’ve lost interest in out of a sense of duty because there’s a succession plan.