Software gets maintained (somewhat) by those who make a career out of it. Build something in your PhD, get a postdoc where you can add some more of your own thi

Software gets maintained (somewhat) by those who make a career out of it. Build something in your PhD, get a postdoc where you can add some more of your own things to it, and get funding for follow on work in which you get your own PhD's to work on it. That's the only model I've seen work, but it's usually very implicit, because when you get to the tenure track stage (or even beyond), you have an incentive to make it look like you're not yet again re-using that thing you were doing 10 years ago. So it's not called 'maintenance' or even 'upgrading' - you call it something else that sounds new, yet has enough links to the old thing to give you validation because people have heard of it, and in this way drag this mutant bastard code through 5 or 10 iterations over 25 years until your career is 'done' and you can finish off the last years in standby mode. This sounds negative but I don't mean it that way; it's just how it is, no judgement meant. But it's not something you really hear anyone teaching new PhD students as an option, and even if they would, it's highly uncertain and success depends on many factors out of your control. So I wouldn't call it a career path, or even viable career advice.