@atpfm @siracusa For obscure projects embedded in enterprise software, sure, dedicate support. But what does an employee assigned to sudo, XZ, Eggert's time zone files, or PHP actually do all day? Submit PRs that never get accepted? Watch for security issues that rarely emerge? Engineers are scarce resources, regardless of company size. Isn't it reasonable to assume that if sudo/XZ/PHP break, the whole industry breaks, and we'll collectively deal with it?
@siracusa I'm with you in principle, but sad in practice. When I've tried to implement such things, even in large orgs of 500+ engineers, it's been SO HARD to convincingly show the value. And it's not just inept corporate leadership. We, the engineers, often fail to frame the value in business terms, instead building ineffective CoEs with little accountability. My question was meant to sharpen my own thinking and approach, and I appreciate your perspective.
@evansteiner Worst case, what for the next (inevitable) disaster and be ready to pounce in the brief moment of clarity to achieve consensus you’d never get outside of a crisis. Fortune favors the prepared!
@evansteiner Some top priorities:
- Make sure it still works on the new OS we’re required to use for compliance reasons.
- Discover and fix security flaws.
- Improve performance in areas that are meaningful to our business.
- Add features that will aid our business (if possible).
@evansteiner But beyond that stuff, having more people paid to work on these projects will help prevent catastrophic problems, which is vastly preferable to just waiting for them to happen (because something so important is being maintained by a lone volunteer) and then assuming the world will rally to quickly come up with a fix before the hackers get through.