• [^] # Re: Solidité de l'équipe

    Posté par . En réponse à la dépêche QSOS ou comment gagner en objectivité dans l'évaluation et la sélection de logiciels libres. Évalué à 2.

    Comme je l'écris au-dessus, on peut même penser que la possibilité de forker est une condition sine qua non pour qu'un logiciel soit réellement libre.

    Le fork, au lieu d'être un risque négatif, devient au contraire une modalité de gestion des projets qui garantit leur bonne santé. On peut voir le fork comme une épée de Damoclès qui limite le pouvoir du tyran ou de l'aristocratie du projet (*) :
    The right to fork guards the project against single points of failure. For example, the right to fork is a powerful check upon the influence of the benevolent dictator on the project's work, and through the project's work, on the community itself. The presence of this right provides strong assurance for any participant in the community to contribute his/her efforts to the community, and lack of it calls into question the open nature of a BenevolentDictator's leadership of that community.
    (cf. http://www.usemod.com/cgi-bin/mb.pl?RightToFork )

    (*) les termes "tyran" et "aristocratie" sont employés ici sans connotation péjorative, de même que "benevolent dictator" dans l'extrait cité


    Alors on peut évidemment s'interroger sur des projets comme OpenOffice.org, qu'il est probablement impossible de reprendre pour une équipe indépendante de l'équipe actuelle (composée en grande partie d'employés de Sun Microsystems).