Projects with bigger problems [LWN.net]

Projects with bigger problems

Posted Apr 24, 2026 17:05 UTC (Fri) by marcH (subscriber, #57642)
In reply to: Projects with bigger problems by farnz
Parent article: Dependency-cooldown discussions warm up

Agree one size does not fit all. Which is why cooldowns, timers, queue lengths and what else should be configurable. What matters at a macro level is the approach and high level architecture, not the low-level parameters.

> BigCorp is now hacked because you weren't paying attention to your notifications while dealing with dying relatives or whatever.

Every time Big pro relies on a poor, burn out and single maintainer, they have only themselves to blame. If you need better, pay up. It really is that simple. Business is all about trust relationships and managing risks and this just one of them - among many other "suppliers". Business as usual, moving on.

to post comments

Projects with bigger problems

Posted Apr 24, 2026 17:32 UTC (Fri) by farnz (subscriber, #17727) [Link] (4 responses)

Right, but the high level approach we're discussing is "put a delay between maintainer publishing a new release and it being generally used, rely on the maintainer to take action if a release is bad to protect the users".

For group maintained projects, this is fine - one or more of the maintainers will be around to handle the notification that the release is bad, and will take action, But for sole maintainers, this runs into the "what if the maintainer is absent at no notice" problem; given that the maintainer can log off forever, a solution based on "maintainer takes action" is not enough.

One answer is social change - we accept that BigCorps will effectively take over sole maintainer projects by adding more maintainers, and if the sole maintainer doesn't want that, BigCorp will fork it and group maintain their fork, trying to stay in sync. This requires us to all accept that BigCorp will fork a lot of interesting projects, and that we have to consider "hostile forks" by big companies as "normal" - it's just BigCorp taking on responsibility for things they depend upon.

Projects with bigger problems

Posted Apr 24, 2026 17:52 UTC (Fri) by marcH (subscriber, #57642) [Link] (3 responses)

> given that the maintainer can log off forever, a solution based on "maintainer takes action" is not enough.

If the sole maintainer "logs off forever" (or a very long time), then there is a much "bigger problem": the project is just orphaned which means any discussion in release delays or other lifecycle questions is pointless.

> This requires us to all accept that BigCorp will fork a lot of interesting projects, and that we have to consider "hostile forks" by big companies as "normal" - it's just BigCorp taking on responsibility for things they depend upon.

I miss what there is to "accept" or "not accept" here... The ability to fork is intrinsic to software freedom. As is the freedom to pick the fork you prefer. Forking is pretty much the essence of free software and it happens frequently, that's just the way things are. BTW "hostile" is a very binary: forking has many shades of grey.

BTW any decent BigCorp has internal mirrors of most of their dependencies (to avoid outages if nothing else) and how they update those is effectively implementing "private cooldowns" already. The richest ones implement all sorts of human and/or automated reviews and inspections on updates already (which other "cooldowns" can happily rely on, as already noted in the main article)

These internal mirrors often have extra commits too, which may or may not be submitted upstream. So I guess you could already call them "forks" depending on some artificial set and personal thresholds.

Maybe they should provide their reviews to the world

Posted Apr 25, 2026 2:41 UTC (Sat) by DemiMarie (subscriber, #164188) [Link]

cargo vet and cargo crev already exist

Projects with bigger problems

Posted Apr 27, 2026 9:18 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)

What's needed is people to stop complaining when companies work in their internal forks first - all these devices shipped with a fork of the Linux kernel, for example, are doing the right thing from a supply chain security perspective, and you should expect them to have private patches that never get upstreamed.

Projects with bigger problems

Posted Apr 27, 2026 13:04 UTC (Mon) by Wol (subscriber, #4433) [Link]

> What's needed is people to stop complaining when companies work in their internal forks first

Isn't this what MOST people do, including FLOSS devs, work on an internal fork first?

The minimum required (and also maximum necessary) aka "necessary and sufficient" for companies to be considered "good FLOSS citizens", should be that their production repository (or a copy thereof) is world-readable.

If they want to make the effort to upstream their fixes (they should, it's in their interest, but it's their decision), then that's down to them.

And if the FLOSS developer wants to plunder their repository for good ideas and/or code, that's down to them!

Once we get over the current "OMG AI is finding exploits" scare, I would hope that the EU CRA encourages this to become the norm. Much less effort than doing stuff in-house.

Cheers,
Wol