Si [jeu] était libre, il y aurait rapidement presque autant de versions de [jeu] que de joueurs, personne ne se mettrait d'accord sur un gameplay, et, faute de consensus et de communauté, le jeu serait complètement dissout et perdu.
Un projet libre n'a pas obligation à devoir recevoir les avis de chacun et faire consensus, un projet libre n'a pas ouvrir son dépôt de code, il peut même ne distribuer publiquement aucune source tant qu'il ne publie pas le binaire.
Pour empêcher ces problèmes de dispersion, le « propriétaire » n'est pas une solution : la solution c'est d'avoir une ligne directrice claire et bien définie, et de donner tout pouvoir de jugement à une équipe. C'est pas un problème de « propriétaire » ou de « libre ». Évidemment, quand on fait tout en propriétaire, on n'a que son avis, donc la ligne directrice est plus facile à assumer. Mais le libre n'empêche pas d'avoir une ligne directrice. La solution au problème de la dispersion n'est pas dans le propriétaire, mais dans la ligne directrice.
En gros l'équipe de Warsow fait du mapping propriétaire avec une ligne directrice claire et assumée, ils pourraient faire du mapping libre avec la même ligne directrice claire et assumée. On peut faire un Warsow libre en disant « Je n'accepte dans mon tronc commun que les contributions de cochons-punks dans des cartes toute bleues ».
Un nombre considérables de projets libres fonctionnent avec à leur tête une grande gueule qui a tout pouvoir sur ce qui passe et ce qui ne passe pas, le noyau Linux est un bon exemple. Un gars comme Linus a le pouvoir de rembarrer vertement un gros comme Google ou Microsoft et leur tapper sur les doigts en disant « ton code est dégueulasse », ou même « c'est pas ma vision d'un système d'exploitation », mais Linux est un projet libre, avec une direction claire et intransigeante avec ses objectifs.
Le projet Xonotic n'a forké qu'une seule fois : quand Nexuiz a été racheté par Illfonic. Et si quelqu'un me sort un hypothétique fork de Xonotic de derrière les fagots, je lui répondrai que si même moi je n'en ai pas eu connaissance, c'est bien qu'il est resté confidentiel et qu'il n'a eu quasi aucun impact.
Je connais un projet libre qui a beaucoup forké : Tremulous, mais les forks sont là parce que la 1.1 est sortie il y a 6 ans et qu'il n'y a eu aucun mise à jour depuis, ça forke dans tout les sens parce que le tronc commun n'existe pas. Si tout le monde propose sa propre mise à jour, c'est parce qu'il y a besoin d'une mise à jour et que le projet mainstream ne la propose pas ! Donc la meilleur manière de se prémunir des forks gangreneux, c'est d'avoir une équipe vivante et une bonne ligne directrice. Quand un projet a des forks gangreneux autour de lui, c'est que le cœur sens mauvais. Un fork signifie souvent une volonté de survie. Si le projet est bien vivant, il ne forke pas.
Il y a deux types de fork :
Le fork pour survivre : on n'a pas à le craindre quand on lance son projet, il n'apparaîtra que lorsqu'on aura déjà abandonné. C'est le phénomène « les rats quittent le navire ».
le fork pour explorer une nouvelle idée : on n'a pas le craindre s'il n'est pas pertinent : il mourra de lui-même. S'il est pertinent, ça ne sera qu'un projet de plus, dont-on pourra peut-être même récupérer des idées. Beaucoup de jeux libres sont à l'origine des mods. Les mods sont des formes de forks, pas des forks du moteur, mais des mods du gameplay et des assets. Je pense qu'un jeu comme Smokin'guns n'a fait aucun tord à Quake3 en son temps.
Ensuite, j'ajouterai (il ne faut pas se voiler la face) qu'il y a quand même un problème avec les forks dans le monde du jeu libre. Les développeurs de jeux libres ne collaborent entre eux que très rarement. Dès qu'ils veulent explorer une direction ils forkent tout, même le moteur, voilà pourquoi dans un autre commentaire j'ai cité deux forks d'XReaL pour deux forks de Tremulous, ces forks sont complètement inutiles. Là on peut chercher les causes, et on peut penser avec raison que c'est contre productif, mais ce problème n'apparaît qu'à partir du moment où le fork est effectif. C'est pas le fork qui est mauvais ici, c'est la manière de forker qui l'est. Si un projet libre est bien vivant et cohérent, il ne forkera pas, et donc le problème de la manière de forker ne se posera pas.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Remarque d'un joueur
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Warsow, le pragmatisme versus la liberté. Évalué à 5.
Un projet libre n'a pas obligation à devoir recevoir les avis de chacun et faire consensus, un projet libre n'a pas ouvrir son dépôt de code, il peut même ne distribuer publiquement aucune source tant qu'il ne publie pas le binaire.
Pour empêcher ces problèmes de dispersion, le « propriétaire » n'est pas une solution : la solution c'est d'avoir une ligne directrice claire et bien définie, et de donner tout pouvoir de jugement à une équipe. C'est pas un problème de « propriétaire » ou de « libre ». Évidemment, quand on fait tout en propriétaire, on n'a que son avis, donc la ligne directrice est plus facile à assumer. Mais le libre n'empêche pas d'avoir une ligne directrice. La solution au problème de la dispersion n'est pas dans le propriétaire, mais dans la ligne directrice.
En gros l'équipe de Warsow fait du mapping propriétaire avec une ligne directrice claire et assumée, ils pourraient faire du mapping libre avec la même ligne directrice claire et assumée. On peut faire un Warsow libre en disant « Je n'accepte dans mon tronc commun que les contributions de cochons-punks dans des cartes toute bleues ».
Un nombre considérables de projets libres fonctionnent avec à leur tête une grande gueule qui a tout pouvoir sur ce qui passe et ce qui ne passe pas, le noyau Linux est un bon exemple. Un gars comme Linus a le pouvoir de rembarrer vertement un gros comme Google ou Microsoft et leur tapper sur les doigts en disant « ton code est dégueulasse », ou même « c'est pas ma vision d'un système d'exploitation », mais Linux est un projet libre, avec une direction claire et intransigeante avec ses objectifs.
Le projet Xonotic n'a forké qu'une seule fois : quand Nexuiz a été racheté par Illfonic. Et si quelqu'un me sort un hypothétique fork de Xonotic de derrière les fagots, je lui répondrai que si même moi je n'en ai pas eu connaissance, c'est bien qu'il est resté confidentiel et qu'il n'a eu quasi aucun impact.
Je connais un projet libre qui a beaucoup forké : Tremulous, mais les forks sont là parce que la 1.1 est sortie il y a 6 ans et qu'il n'y a eu aucun mise à jour depuis, ça forke dans tout les sens parce que le tronc commun n'existe pas. Si tout le monde propose sa propre mise à jour, c'est parce qu'il y a besoin d'une mise à jour et que le projet mainstream ne la propose pas ! Donc la meilleur manière de se prémunir des forks gangreneux, c'est d'avoir une équipe vivante et une bonne ligne directrice. Quand un projet a des forks gangreneux autour de lui, c'est que le cœur sens mauvais. Un fork signifie souvent une volonté de survie. Si le projet est bien vivant, il ne forke pas.
Il y a deux types de fork :
Ensuite, j'ajouterai (il ne faut pas se voiler la face) qu'il y a quand même un problème avec les forks dans le monde du jeu libre. Les développeurs de jeux libres ne collaborent entre eux que très rarement. Dès qu'ils veulent explorer une direction ils forkent tout, même le moteur, voilà pourquoi dans un autre commentaire j'ai cité deux forks d'XReaL pour deux forks de Tremulous, ces forks sont complètement inutiles. Là on peut chercher les causes, et on peut penser avec raison que c'est contre productif, mais ce problème n'apparaît qu'à partir du moment où le fork est effectif. C'est pas le fork qui est mauvais ici, c'est la manière de forker qui l'est. Si un projet libre est bien vivant et cohérent, il ne forkera pas, et donc le problème de la manière de forker ne se posera pas.
ce commentaire est sous licence cc by 4 et précédentes