I had noticed for years that it was too hard to make large changes in Debian
I guess this will always be a problem for such a big organization that has no BDFL and is known for being very stable, which implicates moving slowly and not changing everything all the time.
It’s also a problem with survivor bias. To give a concrete example of a fairly trivial problem in a community that I’m familiar with:
If you install a package via pkg install in FreeBSD, it will be installed in /usr/local. The first time you install any package in FreeBSD that includes a shared library, it will set up ld-config so that it searches in /usr/local/lib. If you have a binary that links to libfoo.so and /usr/local/lib/libfoo.so exists, it will be found. The compilers that FreeBSD installs; however, do not look for headers in /usr/local/include or for libraries in /usr/local/lib. When I try to introduce C/C++ programmers to FreeBSD, this is the first thing that they hit and complain about: They did pkg ins libfoo, it’s installed in the location that the system picked and if they explicitly add -L/usr/local/lib to their LDFLAGS then the run-time linker finds the library, so why doesn’t the toolchain look for headers and libraries in the system locations? They then extrapolate this to ‘FreeBSD has developer-hostile defaults’ and give up on the system.
I thought this would be an uncontroversial change: make the system toolchain look in places the system installs packages. Unfortunately, the only people left in the FreeBSD projects are the ones who have not only created local work-arounds for this but have also created things that depend on this behaviour, so there is huge push-back to changing the default.
When a community starts to diverge from the median in any way, it has a tendency to continue to drift in that direction because the people who don’t like a small change in that direction leave and so it’s then easier to make a larger shift in that direction, which causes the folks who didn’t like the larger shift to leave and attracts the folks who want to move even further that way.
It’s not (just) that the organization moves slowly, it’s the drama. And the contingent that won’t disagree and commit. At a certain point you have to go in direction A or B, and sometimes the larger group picks a direction you might not love. The productive thing in these scenarios is to say “OK, fine, that’s the decision and I can either run with it or leave.” Unfortunately, some people won’t run with it and would rather stay and make everybody else’s lives miserable.
yeah ok that’s the point where some people will have to enforce the COC and tell these guys to tune down or go away, which in itself will also require some amount of drama..
I guess this will always be a problem for such a big organization that has no BDFL and is known for being very stable, which implicates moving slowly and not changing everything all the time.
It’s also a problem with survivor bias. To give a concrete example of a fairly trivial problem in a community that I’m familiar with:
If you install a package via
pkg installin FreeBSD, it will be installed in/usr/local. The first time you install any package in FreeBSD that includes a shared library, it will set upld-configso that it searches in/usr/local/lib. If you have a binary that links tolibfoo.soand/usr/local/lib/libfoo.soexists, it will be found. The compilers that FreeBSD installs; however, do not look for headers in/usr/local/includeor for libraries in/usr/local/lib. When I try to introduce C/C++ programmers to FreeBSD, this is the first thing that they hit and complain about: They didpkg ins libfoo, it’s installed in the location that the system picked and if they explicitly add-L/usr/local/libto theirLDFLAGSthen the run-time linker finds the library, so why doesn’t the toolchain look for headers and libraries in the system locations? They then extrapolate this to ‘FreeBSD has developer-hostile defaults’ and give up on the system.I thought this would be an uncontroversial change: make the system toolchain look in places the system installs packages. Unfortunately, the only people left in the FreeBSD projects are the ones who have not only created local work-arounds for this but have also created things that depend on this behaviour, so there is huge push-back to changing the default.
When a community starts to diverge from the median in any way, it has a tendency to continue to drift in that direction because the people who don’t like a small change in that direction leave and so it’s then easier to make a larger shift in that direction, which causes the folks who didn’t like the larger shift to leave and attracts the folks who want to move even further that way.
It’s not (just) that the organization moves slowly, it’s the drama. And the contingent that won’t disagree and commit. At a certain point you have to go in direction A or B, and sometimes the larger group picks a direction you might not love. The productive thing in these scenarios is to say “OK, fine, that’s the decision and I can either run with it or leave.” Unfortunately, some people won’t run with it and would rather stay and make everybody else’s lives miserable.
yeah ok that’s the point where some people will have to enforce the COC and tell these guys to tune down or go away, which in itself will also require some amount of drama..