Trop de dev d'un endroit est un risque, si jamais RH va mal ou si il y a rachat. Maintenant, tu peux pas forcer non plus les gens à travailler sur les projets sauf si tu est leur employeur et les alternatives ont des effets de bord plus genant qu'un risque futur.
Exemple, ne pas bosser autant sur un projet, ça va ralentir le libre. Ne pas embaucher les codeurs principaux d'un projet, ç'est prendre le risque que le mec se barre dans un trou noir potentiel à la Google/Facebook/Apple et ne bosse plus sur le projet,ce qui implique de former quelqu'un ou d'attendre qu'un remplaçant émerge.
Des gens vont dire que l’émergence d'un concurrent est rendu difficile (exemple, Canonical) de part la position de la boite.
Mais ne pas chercher à augmenter son chiffre d'affaire, c'est prendre le risque qu'une boite moins orienté libre et plus grosse prenne le marché et qu'on revienne en arrière (exemple, une domination d'un secteur par vmware ou oracle). Et c'est pas en laissant une plus petite boite prendre la place d'une plus grosse que tu arrives à te battre contre une boite très grosse.
Il faut aussi voir que plus une technologie est générique (genre glibc, gcc), plus ça pourrait poser de souci. Mais plus elle est générique, plus on devrait avoir des contributions variés car la communauté est plus grande donc moins le risque est grand.
Ensuite, ça reste que du très théorique. Après le rachat de Sun par Oracle, les gens de ZFS et Solaris ont réussi à faire vivre le projet. Aprés Mandriva, Mageia est arrivé.
[^] # Re: Calcul
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 4.
Trop de dev d'un endroit est un risque, si jamais RH va mal ou si il y a rachat. Maintenant, tu peux pas forcer non plus les gens à travailler sur les projets sauf si tu est leur employeur et les alternatives ont des effets de bord plus genant qu'un risque futur.
Exemple, ne pas bosser autant sur un projet, ça va ralentir le libre. Ne pas embaucher les codeurs principaux d'un projet, ç'est prendre le risque que le mec se barre dans un trou noir potentiel à la Google/Facebook/Apple et ne bosse plus sur le projet,ce qui implique de former quelqu'un ou d'attendre qu'un remplaçant émerge.
Des gens vont dire que l’émergence d'un concurrent est rendu difficile (exemple, Canonical) de part la position de la boite.
Mais ne pas chercher à augmenter son chiffre d'affaire, c'est prendre le risque qu'une boite moins orienté libre et plus grosse prenne le marché et qu'on revienne en arrière (exemple, une domination d'un secteur par vmware ou oracle). Et c'est pas en laissant une plus petite boite prendre la place d'une plus grosse que tu arrives à te battre contre une boite très grosse.
Il faut aussi voir que plus une technologie est générique (genre glibc, gcc), plus ça pourrait poser de souci. Mais plus elle est générique, plus on devrait avoir des contributions variés car la communauté est plus grande donc moins le risque est grand.
Ensuite, ça reste que du très théorique. Après le rachat de Sun par Oracle, les gens de ZFS et Solaris ont réussi à faire vivre le projet. Aprés Mandriva, Mageia est arrivé.