Lately I’ve been thinking about “emergency maintenance intended”. There are lots of projects that are complete_ — there isn’t much to add, there are no known major issues, and they don’t depend on anything frequently-breaking, so the only concern of potential users is “what if there’s something like heartbleed/shellshock/log4shell lurking there?”.
For many of my projects, I’m certainly happy to make a promise that if anything comparable to log4shell is found, I will put all reasonable effort into fixing it. Otherwise the project suits my needs and the needs of people who use it and the fact that is may see no new versions in years says nothing about my willingness to keep it secure and free of major bugs.
I like this a lot. I really would not mind if a family of these *maintained.tech sites popped up to help people communicate their maintenance style… wink wink ;)
As @klardotsh alluded to I think there are a lot of maintenance styles that feel off the beaten path in open source culture, but shouldn’t be. I’m reminded of this talk that in a lot of ways is about the harm that the hype-driven side of open source culture incurs.
Do we really need a whole bunch of those websites? Maybe have just one with multiple badges? Maybe even composable badges similar to Creative Commons licenses in spirit.
Heh, probably not now that you mention it. I didn’t think about it too hard - I just really like the domain hack thing going on so a bunch of them sounded like a lot of fun.
Personally, I find it mildly unfortunate that these websites use fancy TLDs like “tech”, because it needlessly increases their operating costs and thus makes them more likely to disappear (and, worse, to be replaced with something malicious).
I suppose a solution could be for them to encourage adopters to link to a capture in https://web.archive.org instead.
I’d been meaning to make a “casual” version of unmaintained.tech for years, and when I read the recent discussions around stale bots (which often turned into folks talking about what obligations contributors and maintainers have to each other/implicit social contracts in open source) I got inspired to finally do it.
I hope this helps - if only a little bit - maintainers set expectations better for contributors. Clear communication improves everything IMO.
I love this, thanks for sharing it! I think the “look, I tossed this code over the wall because I have no reason to leave it private and it scratched my itch” space is woefully underrated in the modern hype- and clout-based development culture in some circles (I tried to poke at this in my own Fork Off Public License, findable on Sourcehut and GitHub)
What do you mean by embed? Embedding the image data of the badge into your README.md file as a data: URL rather than having use an image URL of https://casuallymaintained.tech/badge.svg? Copying the SVG file into your repo and using a local relative image URL in your README.md? Some other kind of embedding?
Lately I’ve been thinking about “emergency maintenance intended”. There are lots of projects that are complete_ — there isn’t much to add, there are no known major issues, and they don’t depend on anything frequently-breaking, so the only concern of potential users is “what if there’s something like heartbleed/shellshock/log4shell lurking there?”.
For many of my projects, I’m certainly happy to make a promise that if anything comparable to log4shell is found, I will put all reasonable effort into fixing it. Otherwise the project suits my needs and the needs of people who use it and the fact that is may see no new versions in years says nothing about my willingness to keep it secure and free of major bugs.
I like this a lot. I really would not mind if a family of these
*maintained.techsites popped up to help people communicate their maintenance style… wink wink ;)As @klardotsh alluded to I think there are a lot of maintenance styles that feel off the beaten path in open source culture, but shouldn’t be. I’m reminded of this talk that in a lot of ways is about the harm that the hype-driven side of open source culture incurs.
Do we really need a whole bunch of those websites? Maybe have just one with multiple badges? Maybe even composable badges similar to Creative Commons licenses in spirit.
Heh, probably not now that you mention it. I didn’t think about it too hard - I just really like the domain hack thing going on so a bunch of them sounded like a lot of fun.
Personally, I find it mildly unfortunate that these websites use fancy TLDs like “tech”, because it needlessly increases their operating costs and thus makes them more likely to disappear (and, worse, to be replaced with something malicious).
I suppose a solution could be for them to encourage adopters to link to a capture in https://web.archive.org instead.
I’d been meaning to make a “casual” version of unmaintained.tech for years, and when I read the recent discussions around stale bots (which often turned into folks talking about what obligations contributors and maintainers have to each other/implicit social contracts in open source) I got inspired to finally do it.
I hope this helps - if only a little bit - maintainers set expectations better for contributors. Clear communication improves everything IMO.
I love this, thanks for sharing it! I think the “look, I tossed this code over the wall because I have no reason to leave it private and it scratched my itch” space is woefully underrated in the modern hype- and clout-based development culture in some circles (I tried to poke at this in my own Fork Off Public License, findable on Sourcehut and GitHub)
Is there a reason we shouldnt just embed these kinds of badges?
What do you mean by embed? Embedding the image data of the badge into your README.md file as a
data:URL rather than having use an image URL of https://casuallymaintained.tech/badge.svg? Copying the SVG file into your repo and using a local relative image URL in your README.md? Some other kind of embedding?