5 ms·

Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs sta

Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs standard, so there is a benefit to the strictness work that extends beyond even just the Nix community itself. Of course, sometimes those kinds of changes just never get merged, for a variety of well-understood open-sourcey reasons, eg: https://github.com/pocoproject/poco/pull/3105 https://github.com/pocoproject/poco/pull/3105

selestify 5y ago
What are the well-understood reasons? It seems weird to me, as someone who hasn’t worked on open source, that the PR would just sit there untouched and not even commented on
- mikepurvis 5y ago
  I'm not seeing an easy reference right now, but I feel like a number of articles bemoaning the state of open source maintainership have come up over the years, particularly in conjunction with high profile security issues like the ones in the OpenSSL and log4j projects. But in short, the maintainers are mostly uncompensated, and therefore have no sense of urgency or obligation to a faceless stranger making a drive-by contribution. Every accepted contribution is something that has to be understood, supported, and even justified by the project's maintainers going forward, so each one is an opportunity to take on more work and risk, and obviously by definition almost all them are things the maintainers didn't themselves "need" or they would have done it themselves. So each new branch or bugfix is relevant to a codepath that no one involved in the planning, testing, or release-preparation for that project has a first-class stake in. Each new capability added is an opportunity for there to be shrieks following a release because it was inadvertently broken in the course of some other bit of development.
3836293648 5y ago
And now that PR is merged...
- mikepurvis 5y ago
  Well yes. I wasn't intentionally shaming the poco project with the link, but having a bunch of attention drawn all at once does have a way of moving these things along.

selestify 5y ago

What are the well-understood reasons? It seems weird to me, as someone who hasn’t worked on open source, that the PR would just sit there untouched and not even commented on

mikepurvis 5y ago
I'm not seeing an easy reference right now, but I feel like a number of articles bemoaning the state of open source maintainership have come up over the years, particularly in conjunction with high profile security issues like the ones in the OpenSSL and log4j projects. But in short, the maintainers are mostly uncompensated, and therefore have no sense of urgency or obligation to a faceless stranger making a drive-by contribution. Every accepted contribution is something that has to be understood, supported, and even justified by the project's maintainers going forward, so each one is an opportunity to take on more work and risk, and obviously by definition almost all them are things the maintainers didn't themselves "need" or they would have done it themselves. So each new branch or bugfix is relevant to a codepath that no one involved in the planning, testing, or release-preparation for that project has a first-class stake in. Each new capability added is an opportunity for there to be shrieks following a release because it was inadvertently broken in the course of some other bit of development.

3836293648 5y ago

And now that PR is merged...

mikepurvis 5y ago
Well yes. I wasn't intentionally shaming the poco project with the link, but having a bunch of attention drawn all at once does have a way of moving these things along.