Good point.
Any new product should have $X bugs/month added by the current developers so that future developers can indicate 'signs of life' by fixing $Y bugs/month![1]
TBH, once a product reaches whatever goal the founders set out to achieve, adding features can only make it worse, not better. Bugfixes, refinements? Sure. Extra features? Can only heighten the learning curve for newcomers in the future, even if the incremental learning curve added is small.
[1] With suitable values for $X and $Y so that a project can show slow and steady improvement in reliability, until the inevitable rewrite 12 months later.
There are exceptions, but software is usually part of a system, a social system. Successful software changes its environment, and in turn, the environment demands change from the software, which diligent maintainers attend to.
It follows that, in the general case, "no change in a long time" is a pretty good indicator that the software is either unsuccessful or abandoned. As I said, there are exceptions (gists might be one of them).
Or just exceptionally well adapted to a stable social environment. Which might even be so stable precisely because the software is working so well that no changes to either software or social system -- business processes -- are required.
For my part, I’m reacting to Gists’ place in the overall GitHub UX. Maybe it’s just me, but it feels heavily implied that Gists aren’t part of the golden path.