let's talk about pkgconf explicitly as an example here.

what, fundamentally, is the goal of pkgconf? to improve the usability and resilience of the pkg-config ecosystem.

or, in other words, to attain sufficient mindshare that pkgconf can drive necessary changes in the pkg-config ecosystem.

given that, what is the true cost of saying *no*?

we said *no* to windows support for years, because i do not develop software on windows. eventually, we begrudingly merged one of the windows ports that were submitted over the years.

but, because of the lack of prioritization on windows, what was my reward?

a new competing implementation (u-config) which does not fully conform to the expected behavior of the pkg-config tool, maintained by somebody who *does not care about pkg-config* and actively spreads misinformation about pkg-config implementations, but the tool is good enough for people to be interested in it.

this detracts from pkgconf's primary goal of being able to drive effective change in the pkg-config ecosystem, because people will desire to author pkg-config files that are compatible with u-config.

had we prioritized windows support when folks asked for it, u-config simply would not exist.

so when people say maintainers have the right to say "no", that's true, but it may come at a cost.