@mainec @f4grx @bert_hubert to be super clear, i am just using the CRA as an example here.

No, we don't. We need to talk about your trackers.

Brilliant assholes don’t exist because brilliance is a property of a collective group of people and nobody wants to work with assholes.

Brilliant asshole is just another phrase for “walking liability that damages everything they touch”

Ain’t nothing brilliant about that

@wouter the existence of u-config in debian (which honestly makes no sense to me but whatever) is an example of why telling people to get lost is not necessarily a correct strategy

@Sobex sometimes that works, sometimes that doesn't. sometimes the ask (windows support) requires engineering capabilities i don't have (such as knowledge about windows development).

my point here is: saying no to corporations carries its own risks.

maybe those risks are acceptable, and known up front, but equally those risks may be unknown

again, we got lucky with cps-config too, because they need and want the extensions pkgconf has brought to the pkg-config format, at least some of them.

but if pkgconf simply supported windows from the beginning? cps-config also would never have existed.

back to the original point for a moment: big tech's abuse of the commons.

as established, i can (and sometimes do) say no to these companies when they request improvements.

but the risk of saying no is that big tech decides to just write their own version and try to trample you.

which brings us back to pkgconf for a minute, because i have another example!

in the past year or so, the CMake people created a new thing called the "common package specification," which they refer to as CPS (this is a very bad name).

but pkgconf's maintainer (me) is entirely disinterested in windows, and i find windows-specific bugs uninteresting to work on.

another cost of my apathy toward windows? bloomberg contributed heavily to a tool called cps-config, which is a pkgconf clone which supports querying both pkg-config data and CPS data. this is after bloomberg also contributed patches to the original freedesktop pkg-config to improve its performance to be competitive to pkgconf.

why did bloomberg do these things? because they are a windows shop and historically my answer to the windows question was "i'm not interested in supporting windows."

so now i get questions like "why bother improving pkg-config, when we should standardize on CPS instead"?

and don't get me wrong -- CPS is a major improvement over what CMake used to do, and also a major improvement over the pkg-config format for a number of reasons.

however, since it is based on JSON, it takes away from one of the main advantages of pkg-config: the fact that pkg-config files are simple text documents.

our plan to deal with the CPS question is to support CPS, thus making the need for cps-config obsolete.

i could go on and on, but the point is that when presented with "fuck you, pay me" these companies are likely to take actions that are detrimental to your goals, because the reality is that they don't care about you or your project or your goals. they just want things for free.

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.

@f4grx @mainec @bert_hubert downthread, i give an example (pkgconf and windows support), where being stubborn about not caring about windows actively harmed the project by causing new fragmentation in the pkg-config ecosystem.

@f4grx @mainec @bert_hubert the CRA is just an example. this post really has nothing to do with the CRA, except that it serves as an example of the power imbalance that leads to maintainers having reduced psychological safety.

@mainec @f4grx @bert_hubert i'm not talking about legally imposed obligations, but how these frameworks harm the autonomy and psychological safety of maintainers.

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.

can i tell some corporate employee who makes a burdensome request to get lost? sure, and i have before.

can i tell some corporate employee who makes a burdensome request required for compliance with a regulatory framework like the CRA that i won't do it and they have to do it themselves? sure.

note i ask "can i" here, and the answer is yes.

that's not the point though. the reality is more complicated. do maintainers *actually* have the psychological safety to reject these requests?

what is the actual psychological cost of saying no?

so maintainers are starting to push back on these requests, and demands for free labor on a project that they give away for free, as if it were a commercial product.

in response, rather than the government scolding corporations for abusing the commons, these corporations have instead pushed for governments like the EU to adopt regulatory regimes such as the CRA which pressure maintainers to do even more free labor, in the name of security.

everyone likes security, right? as practitioners, we don't want to harm anyone's security posture. so there is pressure on maintainers to comply with these regulatory frameworks, in the name of security.

i've written a lot of software over my lifetime, and released the majority of it as free software, because i just wanted to be helpful.

there was no point in hoarding it, and releasing it as free software allowed for others to take it and do whatever they wanted with it. sometimes, they send their improvements back to me. great!

well, not so much with corporations. pkgconf, for example, is in basically *every* major corporation's toolchain.

to make pkgconf scale for these corporations, and their complex DAGs, we had to rewrite the solver. fine, i suppose. some of that work was even sponsored, which is nice.

but the reality is that there are a few utilities in this world that exist in the critical path of basically every corporation. tools like pkgconf, curl, etc. if these tools break because corporations use them in new ways, generally we don't get help with fixing them, but we are expected to.

this position is what leads to critical libraries like libxslt being abandoned, and the same maintainer adopting a laissez-faire security policy for libxml2.

i find the regulatory capture of the commons (so-called "supply chain security") to be frustrating

Even agnostic, I can confidently say the following:

If every person is made in God's image then trans kids are born perfect.

If there is a divine plan, bans on gender affirming care are rebellion against it.

Every trans child has a holy light and a birthright to brighten the world with it.

Trying to quench that light invites a just God's wrath.

For the first time, I actually read an AI summary from a web search I made. I've avoided them until now, but my eyes glanced and took in the gist before I could blink.

It was on a topic I am a certified consultant in; I was just refreshing my memory. And it answered that the product worked in the way the customer wanted it to rather than the way I thought it did, and cited documentation and support forum links as the sources for that answer.

I checked them. It was wrong.

God I fucking hate this bullshit.

"The thing about SpaceX is that they don't let moments like this define them"

I dunno it seems like these are pretty defining moments

...

"This has to be the low point of the Starship programme"

...definitely

Fantastic commentary. Thanks for the link @ariadne this pairs most excellently with my popcorn :blobcatpopcorn: