Why why why do people continually seem to entertain the idea that writing a new application from scratch to replace one which is a little bit old and not super-actively maintained is anywhere near as easy as polishing the old one? It never is, you either have to compromise on time or features/polish in the new app. Or the usual result: you get halfway through writing the new app, realise the hard parts of the problem space, and then lose interest. Now we have one old app and one brownfield site.
@pwithnall I tried both ways and it's not that clear to me.
Often the reason why starting out new is that people have *tried* to fix the old app and patches bitrotted unreviewed.
In that case it's either maintaining and modernizing a fork of the old app (with unclear outcome) or doing s.th. in your favorite lang and libs along your lines of thinking.
That can be a *big* motivation for volunteer work. (Making it more tolerable to live with less polish).
@agx @pwithnall I attribute it to reluctance to grok codebases. Reading code requires you to get into the mindset of the authors and understand the repo's organization. Modern editors's "Go to definition..." makes tracing through code far easier than it used to be, but it's still not easy... at least not until one groks the developers' intents. Starting from scratch means focusing solely on understanding the problem space, and that's a much lower activation energy.
@agx @pwithnall ... or to be more precise... tracing through a repository requires understanding the solution to a problem without fully understanding the design choices that led there. Even if the code is designed perfectly (and it usually isn't), there will be compromises in readability for performance, or to work around external factors. Documentation on the design choices, and/or a 'walk through' doc can help with this.
@agx @pwithnall I occasionally bring on undergraduates at my institution for my OSS projects. I've found that it *really* helps to have 'newcomer' projects handy, to let them dip their toes into a bounded part of the codebase. Otoh, this requires a concerted effort on my part *not* to tackle small feature requests. These are things that I'd knock out in an hour or so, and are really fun to implement... but if I do them all myself, there's nothing left for newcomers.
@pwithnall …and there's one more thing: people might just not feel up to the task and don't want to step into the spotlight. Learning on the project is extremely hard if the project is undermaintained and a bit dated already.
Hence "starting your own project for educational purposes" where you can make your own mistakes in a corner of the internet might feel like the safer choice.
A welcoming community can mitigate that a lot.