I listened to an episode of Open Source Security Podcast and they talked about making EOL of opensource dependencies a CVE type. I think it bears thought.
dvh · 10h ago
I think fork is not solution, you should start over. As software evolves, new features are added rather then removed, complexity grows. This is not a problem for the "old guard" because they entered it when it was simple and gradually became more complex. But new people have to learn the complex version from the start, there is no gentle slope. This i believe is major problem with old software and IMHO the only solution is start over, smaller. Focus on the issues you want the software to solve. Yes the cycle will continue and your software will became complex too but at least it will continue rather than stop or rot.
Also people's expectations are different (lower) when they switching the software than when the software switches the maintainer.
m4rtink · 11h ago
You fork it and take over as the new upstream maintainer ?
xhkkffbf · 10h ago
Too obvious. There must be a way to say it in a long text that will involve much handwringing.
fatbird · 10h ago
The article touches on the security aspect, but doesn't highlight the real tension: if you have a proper build cycle, part of that is automated security scanning with multiple tools. Once an EOLed part of your stack is raising issues, they'll keep getting raised and dismissed with an exception to the rule of "fix all security issues". The backlog of unfixable issues grows, and in places with strict policies about addressing issues, this becomes untenable.
JS microdependency packaging makes this exponentially worse.
Also people's expectations are different (lower) when they switching the software than when the software switches the maintainer.
JS microdependency packaging makes this exponentially worse.