Hey Cal, are you the maintainer of this tool we use in our build?

(ooh, maybe they're asking about adding a new feature!) Yeah, what's up?

The last commit was 3 years ago…

Seems right, yeah

Shouldn't it be updated?

If there's a problem to solve or an improvement, then of course. What do you need?

I can't think of anything, it just seems kind of old

When you write careful code, it doesn't rot as quickly…

Breathe, Cal. Breathe.

@calcifer are you sure all of the copyright notices are up to date? 😂

It burns me up when people conflate a dead project with a live one which has no further evolutionary pressures.

@calcifer Write a bot that randomly touches files every few weeks with non-breaking changes.

@mdhughes nah, this is solveable by educating the newer/younger folks that "time since commit" isn't as strong an indicator of utility as they assume, especially for internal projects

I want to fix the perception problem, not reinforce it. One of the perks of having seniority and authority in an org is you can actually improve culture

@calcifer @mdhughes

"I want to fix the perception problem, not reinforce it" is a really important stance for lots of things, and I wish more people would take it.

@calcifer An internal tool, you can do that. Maybe, inertia's hard. Any public repo, you're outnumbered billions to one.

@calcifer I love using something that hasn't been touched in 3 years. That's a pretty good assurance it's stable and does what it says.

@calcifer Is it bad to have a bias against unchanged code? (especially with complex projects)

Probably need to think through that kinda stuff more

@daniel in my experience, "hey it hasn't been changed in a while" doesn't really carry much signal

Bitrot is, of course, a real thing. But it's so variable that code age doesn't really tell you if it's a problem. Recent code is likely less tested, but not always. Older code could be abandoned or broken in subtle ways, but not always.

Code that's old but lots of people are actively using tends to be a really good thing (but, again, not always), because it means it's been tested 8 ways from Sunday and no one is having reportable problems. Problem is people think "old = abandoned and abandoned means bugs"; but that has so many exceptions that it's not nearly as useful as people think.

@calcifer time to start updating the readme with monthly topical humour

@calcifer There is now apparently generation 'I know apps on mobiles, and project that to all software', which has concluded everything without updates for 6 months is broken.

I guess these folks get a heart attack when being told about TeX.

@DHeadshot eh, less than you might think. If it's working, it works

Might be more of a consideration if you're looking for something to adopt, but if the thing is working for you then 🤷‍♂️

@calcifer TBH, for external tools I find the date of last commit interesting, because it gives a hint whether the maintainer still cares about it. A recent commit somewhat indicates that "someone might be available to help me if I _do_ find a bug".

It doesn't have to be a recent commit, though; activity on the bug tracker (by a maintainer) is just as well.

But yeah, for in-house software these heuristics don't work at all, IMO.

@calcifer And then it gets dropped from distros because it's "unmaintained."

Sign in to participate in the conversation

A bunch of technomancers in the fediverse. This arcology is for all who wash up upon it's digital shore.