Projects with bigger problems

Projects with bigger problems

Part of the reason that these "supply chain" discussions end up in a mess is that there's at least three groups of projects out there:

1. Sole maintainer projects, done in spare time, low volume of users who'll care about a supply chain attack.
2. Sole maintainer projects, done in spare time, taken as a dependency by a big user who'll care about a supply chain attack.
3. Group maintained projects.

There's a reasonable fear that everyone's focused on the group maintained projects, where vacation cover etc is a sensible requirement, and not thinking about what the rules do to someone who thought they were in the "low volume of user" category, but in fact is in the "sole maintainer, taken as a dependency by a big user" category. And we have had examples over the years (libxml is the most recent I recall) where there are projects that are being maintained by a sole, dedicated and hardworking, maintainer, who needs to take a break for a bit, but is worried about what will happen to their big users if everything blows up while the maintainer takes 72 hours away from connectivity.

If you're on a 72 hour break from civilization (e.g. at a family event and not checking notifications daily), you won't notice a "New X release!" of something you maintain - you're not reading e-mail, so you won't see it. If your big users are depending on you seeing that and taking action within 48 hours of a new release, then there's an expectations gap. And it's much worse if you didn't know you had big users with such expectations - everything blows up because you thought it was just a few people playing with it for fun, but BigCorp is now hacked because you weren't paying attention to your notifications while dealing with dying relatives or whatever.

Note: you can avoid this step in the future by logging into your LWN account.