3 ms·
Technically you're correct that change frequency doesn't necessarily mean dead, but the number of projects that are receiving very few updates because they're '
by onion2k 7mo ago
Technically you're correct that change frequency doesn't necessarily mean dead, but the number of projects that are receiving very few updates because they're 'done' is a fraction of a fraction of a percent compared to the number that are just plain dead. I'm certain you can use change frequency as a proxy and never be wrong.
- Supermancho 7mo ago> I'm certain you can use change frequency as a proxy and never be wrong. I (largely) wrote a corporate application 8 years ago, with 2 others. There was one change 2 years ago from another dev. Lots of programs are functionally done in a relatively short amount of time. "Accelerating or Dying" sounds like private equity's lazy way to describe opportunity, not as a metric to describe software.
- onion2k 7mo agoThat sort of project exists in an ocean of abandoned and dead projects though. For every app that's finished and getting one update every few years there are thousands of projects that are utterly broken and undeployable, or abandoned on Github in an unfinished state, or sitting on someone's HDD never be to touched again. Assuming a low change frequency is a proxy for 'dead' is almost always correct, to the extent that it's a reasonable proxy for dead. I know people win the lottery every week, but I also believe that buying a lottery ticket is essentially the same as losing. It's the same principle.
- goosejuice 7mo agoWith respect, this is a myopic view. Not all software is an "app" or a monolith. If you use a terminal, you are directly using many utilities that by this metric are considered dying or dead.