
A l'époque où ils ont forké Debian, la communication publique des "Veteran Unix Admins" était nettement sur les thèmes d'un fort rejet de systemd et un attachement fort à sysvinit. J'ai lu dès le début la critique faite aux VUA de passer une énergie importante à monter leur propre infra, à la maintenir, à maintenir et faire évoluer des choses qui leur sont propres, pour continuer leur combat d'arrière-garde après avoir perdu la bataille dans presque toutes les distros, plutôt que de chercher à garder et améliorer la compatibilité sysvinit des packages Debian au sein de Debian, au moins une fois que les choses se seraient calmées après l'âpre débat terminé par un vote du Technical Committee qui avait déjà poussé Debian vers systemd comme les autres distros. Je suis d'accord avec cette critique. Bien sûr qu'il aurait fallu (continuer à) contourner les upstreams qui ne veulent gérer que systemd, et faire évoluer sysvinit au sein de Debian plutôt qu'au sein de Devuan... mais par rapport à forker une distro mère comme Debian, qui pouvait - et ne s'en est évidemment pas privé, il n'y avait aucune raison technique ou légale de s'en priver - importer des versions de sysvinit et des scripts modifiées par Devuan, j'ai du mal à penser que ça aurait été plus lourd.
Sur le plan général, je ne comptais pas critiquer la duplication d'effort en open source, seulement pointer que même en la quasi-absence d'une telle duplication, c'est déjà très difficile de trouver un financement pour la quasi-totalité des logiciels ouverts

Vous aussi en faites presque forcément l'expérience dans les logiciels ouverts que vous maintenez / auxquels vous contribuez; j'en fais l'expérience sur libti*/gfm/tilp et par l'absence d'une génération suivante implémentée dans un langage plus moderne plus sûr mais toujours interopérable avec C, ajoutant une API asynchrone parce que c'est comme ça que fonctionnent des technos apparues "récemment" permettant de remplir de façon intéressante des use cases importants.
La duplication d'effort fait partie à la fois de la beauté, et des limitations, de l'approche open source. La critique "il y a trop de distros" est à la fois très vieille - elle est dans une certaine mesure antérieure à Linux, la fragmentation des BSDs et Unix propriétaires a été une faiblesse - et fondée pour certaines distros qui n'apportent que de faibles customisations à une grosse distro mère.