J'ai lu plein de réactions concernant le fork des projet, et je pense intéressant de rajouter mon point de vue:
Pour moi, le but des licences libres et de disposer du code source *utilisable* , avant tout d'empêcher une société d'enfermer ses utilisateurs dans ses produits.
Car, quoique l'on dise, le but *absolu* des sociétées est de faire de l'argent, et sur un marché de renouvellement comme le notre, la seule solution est de rendre obsolète les produits existant le plus rapidement possible.
A mon avis, c'est pour ca que de nombreux produits hig-tech sont vendu avec des évolutions mineures qui auraient pu donner lieu à des mises à jour soft, *mais* on préfère vendre le nouveau produit au prix fort (je pense en particulier aux routeurs wifi, téléphones,...)
Ceci explique aussi la durée de vie ridicule des produits actuels (batteries qui ne tiennent plus rien au bout d'un an par exemple).
Un autre exemple plus industriel, plutôt dans l'air du temps:
PeopleSoft se fait racheter par Oracle, ce dernier tente de faire migrer les utilisateurs qui n'en ont pas vraiment besoin, mais ils doivent le faire car c'est trop risqué de continuer sans support. Pire encore, si les utilisateurs utilisent une version hébergé de leur logiciel...
On peux imaginer que, si le logiciel de PeopleSoft avait été open-source, une boite aurais pu monter un fork et continuer la maintenance...
(Ce n'est qu'un exemple capillotracté, hein ;-) )
Bref, pour moi le but et l'intérêt d'abord et avant tout de libérer les utilisateurs finaux des contraintes purements marketings et commerciales des éditeurs, petits et grands.
Car, pour un utilisateur, si l'éditeur est une sociétée, et même si celle ci est de bonne fois, rien n'empêche un rachat, une changement de direction, un départ de l'équipe technique, ... Dans ce cas, un fork permet de sauver ceux qui se sont basé dessus.
Pour un éditeur indépendant (tel un shareware), ou un groupe de personnes, ca permet de continuer le logiciel via un fork si un problème arrive à la personne concernée.
En plus, cela force l'éditeur à répondre à la demande des utilisateurs, plutôt qu'a des actionnaires ou direction, sous peine de mort rapide de la structure en question. Bref, ca oblige tout le monde à ramer dans la même direction.
(Ca reste quand même l'éditeur le mieux placé pour faire les modifications demandées par les utilisateurs, techniquement parlant)
Un bon exemple de succès vis-à-vis de ce modèle c'est Trolltech.
Alors, c'est sur on peux toujours forker à tord et à travers, mais il n'y a aucun intérêt à le faire a cause de modifications mineures, même si elles ne plaisent pas. Par contre, le jour (hypotétique) où, par exemple, Apple se fait racheter par M$ et celui-ci décide d'intégrer IE dans tous les iphones, là les possésseurs d'iphone seraient bien content d'avoir les sources, afin qu'une petite équipe produise un fork...
(C'est encore un exemple foireux, mais Apple reste connu pour imposer des restrictions et modifications unilatérales de ses produits via les maj de firmware ... Et c'est loin d'être le seul)
[^] # Re: Controle et libre?
Posté par C. OB (site web personnel) . En réponse à la dépêche Le projet Webkit clarifie ses règles. Évalué à 3.
Pour moi, le but des licences libres et de disposer du code source *utilisable* , avant tout d'empêcher une société d'enfermer ses utilisateurs dans ses produits.
Car, quoique l'on dise, le but *absolu* des sociétées est de faire de l'argent, et sur un marché de renouvellement comme le notre, la seule solution est de rendre obsolète les produits existant le plus rapidement possible.
A mon avis, c'est pour ca que de nombreux produits hig-tech sont vendu avec des évolutions mineures qui auraient pu donner lieu à des mises à jour soft, *mais* on préfère vendre le nouveau produit au prix fort (je pense en particulier aux routeurs wifi, téléphones,...)
Ceci explique aussi la durée de vie ridicule des produits actuels (batteries qui ne tiennent plus rien au bout d'un an par exemple).
Un autre exemple plus industriel, plutôt dans l'air du temps:
PeopleSoft se fait racheter par Oracle, ce dernier tente de faire migrer les utilisateurs qui n'en ont pas vraiment besoin, mais ils doivent le faire car c'est trop risqué de continuer sans support. Pire encore, si les utilisateurs utilisent une version hébergé de leur logiciel...
On peux imaginer que, si le logiciel de PeopleSoft avait été open-source, une boite aurais pu monter un fork et continuer la maintenance...
(Ce n'est qu'un exemple capillotracté, hein ;-) )
Bref, pour moi le but et l'intérêt d'abord et avant tout de libérer les utilisateurs finaux des contraintes purements marketings et commerciales des éditeurs, petits et grands.
Car, pour un utilisateur, si l'éditeur est une sociétée, et même si celle ci est de bonne fois, rien n'empêche un rachat, une changement de direction, un départ de l'équipe technique, ... Dans ce cas, un fork permet de sauver ceux qui se sont basé dessus.
Pour un éditeur indépendant (tel un shareware), ou un groupe de personnes, ca permet de continuer le logiciel via un fork si un problème arrive à la personne concernée.
En plus, cela force l'éditeur à répondre à la demande des utilisateurs, plutôt qu'a des actionnaires ou direction, sous peine de mort rapide de la structure en question. Bref, ca oblige tout le monde à ramer dans la même direction.
(Ca reste quand même l'éditeur le mieux placé pour faire les modifications demandées par les utilisateurs, techniquement parlant)
Un bon exemple de succès vis-à-vis de ce modèle c'est Trolltech.
Alors, c'est sur on peux toujours forker à tord et à travers, mais il n'y a aucun intérêt à le faire a cause de modifications mineures, même si elles ne plaisent pas. Par contre, le jour (hypotétique) où, par exemple, Apple se fait racheter par M$ et celui-ci décide d'intégrer IE dans tous les iphones, là les possésseurs d'iphone seraient bien content d'avoir les sources, afin qu'une petite équipe produise un fork...
(C'est encore un exemple foireux, mais Apple reste connu pour imposer des restrictions et modifications unilatérales de ses produits via les maj de firmware ... Et c'est loin d'être le seul)
ob