I think parent's complaint is that Debian's model has failed to produce good solutions of its own, and while that isn't necessarily a requirement, it does speak to potential limitations of the model
If a Debian developer, or a group of Debian developers, sets out to solve some problem that isn't Debian-specific, the result is (quite correctly) seen as a new independent free-software project rather than a Debian project.
For example, as I understand it the reproducible builds project (now reproducible-builds.org) started out inside Debian, then became a thing of its own.
Yet there's no obvious way for people to realize to what extent Debian influences other projects and companies.
The parent compared a group of volunteers with the largest open-source company in the world, which is a part S&P 500. No other Linux distribution has a comparable amount of resources. Even Canonical is following the RedHat's lead (systemd, Wayland, PulseAudio).
I think this is the first time I've heard someone critique a model for encouraging anti-NIH syndrome.
That's endemic to programming and the fields around it, even in closed source. I don't think it's a problem of open source, though open source might enable it in a few ways.
Debian must be producing very good results, and doing so consistently. Otherwise Debian wouldn't be either the most successful linux distro or the distro that is forked by the vast majority of leading distros.
But that's exactly what Red Hat has done in a lot of situations. The main example I can think of is systemd. It was built to solve problems that really only appear on enterprise production systems, sadly it got adopted across the board for systems outside of that niche. Essentially it's taken what was a working system (sysV init and friends are very, very simple to configure for 90% of the desktop configurations) and replaced it with something that somehow needs continual firefighting.
Back to the original point: Not only has systemd reinvented sysvinit, but at this point systemd has reinvented from scratch:
* The UEFI bootloader[0]
* syslog daemon[1]
* DNS[2]
* A Calendar / cron[3]
* A text editor[4]
* netcat/socat[5]
* nice(1) [6]
* sudo(1) [7]
[0]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...
[1]: http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1...
[2]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d...
[3]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d...
[4]: https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d...
[5]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...
[6]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...
[7]: https://github.com/systemd/systemd/blob/76153ad45f09b6ae4546...
* https://docs.oracle.com/cd/E19683-01/816-0214/6m6nf1of0/inde...
This is one of the standard parts of service management, and service management toolsets all have to do it, either employing nice or their own mechanisms. Gerrit Pape's toolset does it with the -n option to chpst, for example.
* http://smarden.org/runit/chpst.8.html
Ironically given the subject of Debian, one can look to the Debian package archive (or indeed the FreeBSD or NetBSD ports tree and some others) to see lots of actual reinventions of a text editor.
* https://packages.debian.org/stable/editors/
* http://www.guckes.net/vi/clones.php3
Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.
> Similarly, the claim that cron is only just now being reinvented from scratch looks rather ill-informed given the existence of tools such as Uwe Ohse's uschedule and the multiple "cron" tools, many of which reinvent the design in significant ways (Bruce Guenter's split of scheduling, spooling, and updating into separate services being a notable example); and given the fact that Paul Vixie's "original" PD Cron was actually itself a from-scratch clone.
My response to both of these are, can you point out any of them that are part of a monolithic system that replaces the traditional PID 0?
Or are you talking about people reinventing small parts of the general system? Yes. UNIX allows people to swap out software for other software. In the original use-cases though, the editor(1), cron(1), and nice(1) were at no point conjoined with the boot menu system, or PID 0.
Indeed, there is a fundamental choice between someone building a replacement for one small part of the general system, to make their life easier, and building a replacement for the entire init system.
