- I think they're wrong about systemd, but if they're right, Debian can merge their fork back in, they can say "I told you so", and we can move on.
- It gives us a place to point the anti-systemd people. Rather than spending their energy trying to fight the system, they can spend their energy productively on this fork.
- This puts the burden of maintaining the SysV scripts on the fork, rather than the package maintainers, as it would be for Ian Jackson's proposal to maintain freedom of choice[1] Maintaining the scripts probably isn't hard for most; testing them probably would be. It would require maintainers to keep a SysV init system up and running on their machines.
Exactly; this reminds me of the quote "I do not agree with what you have to say, but I'll defend to the death your right to say it." A key axiom of free software is that if you don't like something, you can fork it. If your fork is better, it will win (in theory).
It isn't necessarily an efficient allocation of resources, but open-source does not seek to achieve that: it values choice instead.
- I think they're wrong about systemd, but if they're right, Debian can merge their fork back in, they can say "I told you so", and we can move on.
- It gives us a place to point the anti-systemd people. Rather than spending their energy trying to fight the system, they can spend their energy productively on this fork.
- This puts the burden of maintaining the SysV scripts on the fork, rather than the package maintainers, as it would be for Ian Jackson's proposal to maintain freedom of choice[1] Maintaining the scripts probably isn't hard for most; testing them probably would be. It would require maintainers to keep a SysV init system up and running on their machines.
1: https://lists.debian.org/debian-vote/2014/10/msg00001.html