Controversial open source opinion:
-
Controversial open source opinion:
Just because something is "just for fun" or "just for me to use" etc. doesn't mean you get to not maintain it. If you're a single point of failure, and you've put something up publicly where it can be relied upon, you should appoint multiple maintainers if you can find them, and take the time to maintain it if not.
Also, the common rebuttable "the person relying on the code can just fork it and maintain it themselves" makes the problem worse, not better.
-
I suppose this could have been simplified to "if you want to maintain absolute dictatorial control over your project: don't."
-
@sam people get in heated arguments over this but yeah I (at this stage) don't publish anything unless I commit to maintaining it. Otherwise I would be valuing my own time over the multiplicative time of all the people in my community who try to use something I publish that doesn't work.
-
@ahelwer exactly; at a bare minimum put a big "this will not be maintained going forward" at the top of the readme or something! The number of hours I've wasted because I committed to this UI toolkit years ago and the author is rarely available but also won't give anyone else merge access is… I dunno, a lot.
-
@sam @ahelwer See, I would prefer to Do Programming in an ecosystem full of "scrappy fiddles" shared online with open (or copyleft) licenses and absolutely no implication of maintenance.
However, I understand why other thoughtful folks come to another conclusion ("people should only share projects that they can maintain") because the status quo ("people can't maintain things but still insist that they own them") can't be sustained.
-
@eamon @ahelwer I generally agree with everything you've said, I'd just characterize it as "people should only share projects that they can maintain OR that they are willing to tell people up front they won't maintain".
All you have to do is invite a few more contributors or put a big "this is not maintained, I might update it or I might not" at the top of the readme and it will save everyone else *hours* of time.
-
-
@sam I agree with the sentiment, but I don't think publishing is a commitment to maintenance, because what ends up happening in that train of thought is that software goes unpublished.
I tend to publish essentially everything I make, and I think usually it's pretty clear that I don't intend for it to become A Thing people should rely on.
-
@sky yah, I think it would be better if it went unpublished for the most part.
That being said, it's as easy as putting a big warning on the top of the readme saying it's unmaintained or, if it does become widely used enough that you can find people, appointing a few more people with commit access. But if you can't or won't do either of those, I definitely think unpublished is better.
-
@sam That's fair. I've had a couple situations where someone e-mailed me asking about the status of a project and was pretty direct in saying I don't intend to maintain it.
That said, a warning on a README for setting expectations clearly is a pretty low bar to clear. I can get behind it
