-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pour reprendre le cas d'IBM, ils n'ont pas livré leur produit à
l'open source, mais plutot ce que j'appelerai le "Core".
En gros, pour transposer sur SPIP, on fait evoluer le produit
(c'est la que
ca peut ne pas etre "politiquement correct" car on ne suis
pas forcement la
philo initiale), on lui rajoute une belle boite à outil, mais ce
qu'on developpe dessus, les "briques fonctionnelles", restent du
"developpement
specifique" vendu (quitte à vendre plusieurs fois la meme chose en
l'adaptant un peu).
Ca se joue donc plutot au niveau de la limite entre outils et
developpement
specifique, mais ils ont tout interet à en lacher un maximum
pour faire
evoluer "à l'oeil" leur boite à outil tout en se garantissant
quasiment une
compatibilité.
Encore une fois, je suis assez d'accord sur le principe, c'est un
peu degueulasse de ne pas le faire en concertation, mais c'est
comme ca que ca
marche aujourd'hui ...
ce n'est pas une raison pour être d'accord avec et pour être super
content de l'apprendre. De plus, ce n'est pas le même problème là,
puisque les briques fonctionnelles dont tu parles, si j'ai bien
compris, ne sont pas, elles, en open source (et cela n'est bien
évidemment pas pour me réjouir). A mon avis, ce n'est pas un bon
choix à long terme, bien que je suppose que ce soit déjà pas mal 
Une société ne livre pas du code à l'open source sans en
attendre un retour
sur investissement. Hors le meilleur moyen de maitriser le
risque, c'est de
decider tout seul quand quoi et comment, mais on prend le
risque de ne pas
etre suivit si on s'est trop ecarté de la philosophie initial
du projet.
C'est bizarre, j'ai l'impression que tu décris des gens qui veulent
faire de l'open source 'parce que ca fait bien' sans penser vraiment
que ce soit un mode de développement viable, intéresant et
performant.
Bien sur, l'integration serait plus facile si le code etait
livré au fur et
à mesure, mais ils prendrait le risque de se faire doubler
par une autre
boite.
Quel est le risque? Qu'une autre boîte n'ait aucun projet en ce
moment, et passe donc son temps sur Internet à essayer de trouver des
projets à "voler"? Qu'une telle boîte ait les moyens financiers pour
développer, tester, intégrer, un logiciel dont elle n'a pas entendu
parler avant, pour une cible qu'elle ne connait pas encore, plus vite
qu'une communauté de développeurs/testeurs open source au courant de
la situation? Ils pourront peut être obtenir une première version
plus vite, mais de là à ce que le produit soit de qualité, il y a un
grand pas. Et c'est tout bénéf pour la boîte qui a développé en open
source, et qui arrive avec son logiciel tip top. Non, je ne vois pas
le risque.
Sortir un produit et le livrer, meme completement, à l'open
source n'est pas
si grave, commercialement, on est les premier sur le marché,
ceux qui se
mettent à suivre n'ont pas le meme recule ni la "legitimité"
(quoi qu'un peu
artificielle). Et c'est toujours bon d'avoir des concurrent,
surtout quand
on est sur qu'ils ont un temps de retard ...
Tu sembles donc sûr que la boîte dont je parlais plus haut existe
(puisque tu penses qu'il ne faut pas livrer le code avant la sortie),
mais tu ne crois pas qu'une telle boîte ait les compétences pour
rattraper son "retard"? De plus la légitimité est la même que tu ais
donné le projet en open source au début ou à la fin de la phase de
dév.
Meme si l'attitude peut paraitre choquante, elle me parait
"normale" dans le
contexte actuel et au final, tout le monde y gagnera, meme si
il y a moyen
de faire progresser le code plus vite autrement, c'est
toujours mieux que
rien.
Que ce soit mieux que rien ne veut pas dire que ce soit "normal" et
qu'on doive s'en féliciter.
Enfin, c'est juste mon avis.
hihihi, pareil
PS : si la societe en question n'est pas bete, elle participe
deja au projet
et apporte deja du code et du debug, mais surtout rien
d'inovant, que sur
l'existant fonctionnel ...
ben justement, c'est ça que je ne trouve pas correct.