Ariadne Conill 🐰:therian: @ariadne@social.treehouse.systems
Public

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.

Ariadne Conill 🐰:therian: @ariadne@social.treehouse.systems
Public

in practice, we got really lucky with u-config. it exists, but for the most part, nobody cares. it appears in some distributions, but it is not the default anywhere other than the u-config author's personal windows development toolchain distribution.

but at the same time, it is now an area of risk that now has to be mitigated to protect pkgconf's mindshare.

in the general sense, this also holds. let's talk about the recent Xlibre fork as an example.

freedesktop.org clearly does not care about X anymore for the most part, because they have used their position of mindshare dominance to drive a mostly-successful transition to Wayland.

but now Xlibre is a competitive threat to their transition plan.

it's the same with these software supply-chain security regulatory frameworks: if you *don't* do the work, then somebody else can come along and fork your project and do the work, taking mindshare away from your project.

maybe that matters, maybe it doesn't. it depends on what the end goal of the project is.

and so even though maintainers can *technically* say no to burdensome requests, the cost of doing so may negatively impact the project's ability to meet its end goal.

0
0
0

If you have a fediverse account, you can quote this note from your own instance. Search https://social.treehouse.systems/users/ariadne/statuses/114714591541583306 on your instance and quote it. (Note that quoting is not supported in Mastodon.)