Hé, dites, vous avez vu, le dingue qui pilote SCO a dit qu'il allait
casser l'arangemet à l'amiable USL vs Berkeley concernant les sources de
BSD. Je me demande si SCO a fait le ménage dans les sources d'UNIX
System V pour re-attribuer toutes les notices de copyright BSD qui
avaient disparu à l'epoque.
Cette affaire est incroyable: alors qu'on se dit qu'il sont allés au
bout et qu'ils ne peuvent pas délirer plus loin, ils trouvent encore une
idée de procès à faire. Quelle créativité!
--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Pffff. Fichtre, est-ce que cela va retarder une éventuelle migration Unix|GNU/Linux|MSWindows -> *BSD ? Peut être pas, ça va peut être faire parler des *BSD également ...
Ben oui, SCO va nous faire de la pub. Enfin je me demande si ils sont au courrant qu'il y a 3 BSD.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Marwan Burelle <burelle@lri.fr> wrote:
Pffff. Fichtre, est-ce que cela va retarder une éventuelle migration
Unix|GNU/Linux|MSWindows -> *BSD ?
Peut être pas, ça va peut être faire parler des *BSD également ...
Ben oui, SCO va nous faire de la pub. Enfin je me demande si ils sont au
courrant qu'il y a 3 BSD.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Pffff. Fichtre, est-ce que cela va retarder une éventuelle migration Unix|GNU/Linux|MSWindows -> *BSD ? Peut être pas, ça va peut être faire parler des *BSD également ...
Ben oui, SCO va nous faire de la pub. Enfin je me demande si ils sont au courrant qu'il y a 3 BSD.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu
Non, une simple constatation. Un Unix open source peut se scléroser par endroit parce qu'aucun développeur ne souhaite travailler sur tel ou tel aspect. Ceci ne se produit pas si le développeur est embauché pour y travailler à plein temps...
Ca n'est pas incompatible: si des boites utilisent de l'open source, elles peuvent de temps à autre payer quelqu'un pour remettre à niveau certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Non, une simple constatation. Un Unix open source peut se scléroser par
endroit parce qu'aucun développeur ne souhaite travailler sur tel ou tel
aspect. Ceci ne se produit pas si le développeur est embauché pour y
travailler à plein temps...
Ca n'est pas incompatible: si des boites utilisent de l'open source,
elles peuvent de temps à autre payer quelqu'un pour remettre à niveau
certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Non, une simple constatation. Un Unix open source peut se scléroser par endroit parce qu'aucun développeur ne souhaite travailler sur tel ou tel aspect. Ceci ne se produit pas si le développeur est embauché pour y travailler à plein temps...
Ca n'est pas incompatible: si des boites utilisent de l'open source, elles peuvent de temps à autre payer quelqu'un pour remettre à niveau certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Éric Lévénez
Le 20/11/03 19:39, dans <1g4qmkv.6oiprevi3zapN%, « Emmanuel Dreyfus » a écrit :
Ben oui, SCO va nous faire de la pub. Enfin je me demande si ils sont au courrant qu'il y a 3 BSD.
Le quatrième étant Mac OS X, et il y a MirBSD et encore d'autres groupuscules BSDistes. Mais pour Mac OS X, je pense que Darl est au courant, et même très au courant de son existence. Les autres BSD n'ont pas beaucoup d'intérêt financièrement.
Et à propos de BSD, BSD/OS est mort ou pas ? Ils devaient sortir un 5.1 mais rien en vue...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/11/03 19:39, dans <1g4qmkv.6oiprevi3zapN%manu@netbsd.org>, « Emmanuel
Dreyfus » <manu@netbsd.org> a écrit :
Ben oui, SCO va nous faire de la pub. Enfin je me demande si ils sont au
courrant qu'il y a 3 BSD.
Le quatrième étant Mac OS X, et il y a MirBSD et encore d'autres
groupuscules BSDistes. Mais pour Mac OS X, je pense que Darl est au courant,
et même très au courant de son existence. Les autres BSD n'ont pas beaucoup
d'intérêt financièrement.
Et à propos de BSD, BSD/OS est mort ou pas ? Ils devaient sortir un 5.1 mais
rien en vue...
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/11/03 19:39, dans <1g4qmkv.6oiprevi3zapN%, « Emmanuel Dreyfus » a écrit :
Ben oui, SCO va nous faire de la pub. Enfin je me demande si ils sont au courrant qu'il y a 3 BSD.
Le quatrième étant Mac OS X, et il y a MirBSD et encore d'autres groupuscules BSDistes. Mais pour Mac OS X, je pense que Darl est au courant, et même très au courant de son existence. Les autres BSD n'ont pas beaucoup d'intérêt financièrement.
Et à propos de BSD, BSD/OS est mort ou pas ? Ils devaient sortir un 5.1 mais rien en vue...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Thierry Thomas
Jeudi 20 novembre 2003 à 18:46 GMT, Éric Lévénez a écrit :
Ben oui, SCO va nous faire de la pub. Enfin je me demande si ils sont au courrant qu'il y a 3 BSD.
Le quatrième étant Mac OS X, et il y a MirBSD et encore d'autres groupuscules BSDistes.
Le cinquième étant le vol du dragon... -- Th. Thomas.
Jeudi 20 novembre 2003 à 18:46 GMT, Éric Lévénez a écrit :
Ben oui, SCO va nous faire de la pub. Enfin je me demande si ils sont au
courrant qu'il y a 3 BSD.
Le quatrième étant Mac OS X, et il y a MirBSD et encore d'autres
groupuscules BSDistes.
Le cinquième étant le vol du dragon...
--
Th. Thomas.
Le quatrième étant Mac OS X, et il y a MirBSD et encore d'autres groupuscules BSDistes. Le cinquième étant le vol du dragon...
Je voudrais pas avoir l'air de la ramener, mais dargonfly, c'est une libellule.
Bon, ensuite on peut compter les myriades de projets de recherche dérivés de BSD, mais c'est clair que ca n'interessera pas SCO.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Eric Masson
"Thierry" == Thierry Thomas writes:
Thierry> Le cinquième étant le vol du dragon...
Quelqu'un l'utilise par ici ?
J'aimerais bien y jeter un oeil mais je suis à court de machines :/
Eric Masson
-- LG: Conclusion il faut distribuer fcsm en shareware sur tous le CD de revues mac :-) CF: Faudrait un DVD... JNS: Double face hein !! -+- JNS in Guide du Macounet Pervers : fcsm comme on l'aime -+-
"Thierry" == Thierry Thomas <tthomas@mail.dotcom.fr> writes:
Thierry> Le cinquième étant le vol du dragon...
Quelqu'un l'utilise par ici ?
J'aimerais bien y jeter un oeil mais je suis à court de machines :/
Eric Masson
--
LG: Conclusion il faut distribuer fcsm en shareware sur tous le CD de
revues mac :-) CF: Faudrait un DVD...
JNS: Double face hein !!
-+- JNS in Guide du Macounet Pervers : fcsm comme on l'aime -+-
J'aimerais bien y jeter un oeil mais je suis à court de machines :/
Eric Masson
-- LG: Conclusion il faut distribuer fcsm en shareware sur tous le CD de revues mac :-) CF: Faudrait un DVD... JNS: Double face hein !! -+- JNS in Guide du Macounet Pervers : fcsm comme on l'aime -+-
jeremy
Le cinquième étant le vol du dragon...
le vol du dragon... hein...
il est ou mon smiley "mega mort de rire" ??!!? , faut je le trouve là
Le cinquième étant le vol du dragon...
le vol du dragon... hein...
il est ou mon smiley "mega mort de rire" ??!!? , faut je le trouve là
il est ou mon smiley "mega mort de rire" ??!!? , faut je le trouve là
Miod Vallat
Non, une simple constatation. Un Unix open source peut se scléroser par endroit parce qu'aucun développeur ne souhaite travailler sur tel ou tel aspect. Ceci ne se produit pas si le développeur est embauché pour y travailler à plein temps...
Ca n'est pas incompatible: si des boites utilisent de l'open source, elles peuvent de temps à autre payer quelqu'un pour remettre à niveau certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs.
Certes, mais rien ne les oblige à le faire (ou à rendre ces dépoussiérages et améliorations publiques)...
Non, une simple constatation. Un Unix open source peut se scléroser par
endroit parce qu'aucun développeur ne souhaite travailler sur tel ou tel
aspect. Ceci ne se produit pas si le développeur est embauché pour y
travailler à plein temps...
Ca n'est pas incompatible: si des boites utilisent de l'open source,
elles peuvent de temps à autre payer quelqu'un pour remettre à niveau
certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs.
Certes, mais rien ne les oblige à le faire (ou à rendre ces
dépoussiérages et améliorations publiques)...
Non, une simple constatation. Un Unix open source peut se scléroser par endroit parce qu'aucun développeur ne souhaite travailler sur tel ou tel aspect. Ceci ne se produit pas si le développeur est embauché pour y travailler à plein temps...
Ca n'est pas incompatible: si des boites utilisent de l'open source, elles peuvent de temps à autre payer quelqu'un pour remettre à niveau certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs.
Certes, mais rien ne les oblige à le faire (ou à rendre ces dépoussiérages et améliorations publiques)...
manu
Miod Vallat wrote:
Ca n'est pas incompatible: si des boites utilisent de l'open source, elles peuvent de temps à autre payer quelqu'un pour remettre à niveau certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs. Certes, mais rien ne les oblige à le faire (ou à rendre ces
dépoussiérages et améliorations publiques)...
Ils le font pourtant souvent, et pour plusieurs raisons.
La première, c'est que vendre du logiciel basé sur du logiciel libre, c'est dur. Y'a la version libre à coté, faut mettre le paquet pour eviter qu'elle ne te rattrape. Surtout qu'en partant de ses sources, tu as eventuellement bien excité un ou deux developpeurs doués qui vont prendre un malin plaisir à re-implementer en libre les avantages competitifs que tu t'es escrimer à mettre en place. La strategie super à la mode, c'est donc de ne même pas essayer de vendre le logiciel, mais de vendre du service ou du materiel.
Exception: Apple, qui vends MacOS X. Mais MacOS X a beau être basé sur Darwin, ca n'est pas un projet qui est parti d'un projet libre pré-existant. C'est plutot Darwin qui est une emmanation de MacOS X.
Si tu es une boite qui vends du service ou du materiel, le logiciel, tu as tout interet à le rendre libre. Tu ne le vends pas donc tu n'y perds rien, et tu y gagnes le support de la communauté, ce qui, si cela peut ne pas faire de bien, en tout cas ne peut pas faire de mal.
Problème: parfois, le logiciel rendu libre trahit un avantage competitif dans ton materiel. Pas de problème, tu attends 6 mois et tu rends ton logiciel libre. En 6 mois l'avantage competitif est obsolete, donc il n'y a plus rien à gagner, et par contre tu gagnes le support de ton logiciel par la communauté.
La deuxieme raison, elle est là: le support de la communauté. Tu y gagnes la relecture de ton code, les contributions des autres, et le support technique assuré en partie par la communauté.
La troisieme raison, c'est que la demande du public est de plus en plus forte pour ca. On en a marre de se taper des systèmes proprietaires pleins de bugs qu'on ne peut pas corriger.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Miod Vallat <miod@online.fr> wrote:
Ca n'est pas incompatible: si des boites utilisent de l'open source,
elles peuvent de temps à autre payer quelqu'un pour remettre à niveau
certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs.
Certes, mais rien ne les oblige à le faire (ou à rendre ces
dépoussiérages et améliorations publiques)...
Ils le font pourtant souvent, et pour plusieurs raisons.
La première, c'est que vendre du logiciel basé sur du logiciel libre,
c'est dur. Y'a la version libre à coté, faut mettre le paquet pour
eviter qu'elle ne te rattrape. Surtout qu'en partant de ses sources, tu
as eventuellement bien excité un ou deux developpeurs doués qui vont
prendre un malin plaisir à re-implementer en libre les avantages
competitifs que tu t'es escrimer à mettre en place. La strategie super à
la mode, c'est donc de ne même pas essayer de vendre le logiciel, mais
de vendre du service ou du materiel.
Exception: Apple, qui vends MacOS X. Mais MacOS X a beau être basé sur
Darwin, ca n'est pas un projet qui est parti d'un projet libre
pré-existant. C'est plutot Darwin qui est une emmanation de MacOS X.
Si tu es une boite qui vends du service ou du materiel, le logiciel, tu
as tout interet à le rendre libre. Tu ne le vends pas donc tu n'y perds
rien, et tu y gagnes le support de la communauté, ce qui, si cela peut
ne pas faire de bien, en tout cas ne peut pas faire de mal.
Problème: parfois, le logiciel rendu libre trahit un avantage competitif
dans ton materiel. Pas de problème, tu attends 6 mois et tu rends ton
logiciel libre. En 6 mois l'avantage competitif est obsolete, donc il
n'y a plus rien à gagner, et par contre tu gagnes le support de ton
logiciel par la communauté.
La deuxieme raison, elle est là: le support de la communauté. Tu y
gagnes la relecture de ton code, les contributions des autres, et le
support technique assuré en partie par la communauté.
La troisieme raison, c'est que la demande du public est de plus en plus
forte pour ca. On en a marre de se taper des systèmes proprietaires
pleins de bugs qu'on ne peut pas corriger.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Ca n'est pas incompatible: si des boites utilisent de l'open source, elles peuvent de temps à autre payer quelqu'un pour remettre à niveau certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs. Certes, mais rien ne les oblige à le faire (ou à rendre ces
dépoussiérages et améliorations publiques)...
Ils le font pourtant souvent, et pour plusieurs raisons.
La première, c'est que vendre du logiciel basé sur du logiciel libre, c'est dur. Y'a la version libre à coté, faut mettre le paquet pour eviter qu'elle ne te rattrape. Surtout qu'en partant de ses sources, tu as eventuellement bien excité un ou deux developpeurs doués qui vont prendre un malin plaisir à re-implementer en libre les avantages competitifs que tu t'es escrimer à mettre en place. La strategie super à la mode, c'est donc de ne même pas essayer de vendre le logiciel, mais de vendre du service ou du materiel.
Exception: Apple, qui vends MacOS X. Mais MacOS X a beau être basé sur Darwin, ca n'est pas un projet qui est parti d'un projet libre pré-existant. C'est plutot Darwin qui est une emmanation de MacOS X.
Si tu es une boite qui vends du service ou du materiel, le logiciel, tu as tout interet à le rendre libre. Tu ne le vends pas donc tu n'y perds rien, et tu y gagnes le support de la communauté, ce qui, si cela peut ne pas faire de bien, en tout cas ne peut pas faire de mal.
Problème: parfois, le logiciel rendu libre trahit un avantage competitif dans ton materiel. Pas de problème, tu attends 6 mois et tu rends ton logiciel libre. En 6 mois l'avantage competitif est obsolete, donc il n'y a plus rien à gagner, et par contre tu gagnes le support de ton logiciel par la communauté.
La deuxieme raison, elle est là: le support de la communauté. Tu y gagnes la relecture de ton code, les contributions des autres, et le support technique assuré en partie par la communauté.
La troisieme raison, c'est que la demande du public est de plus en plus forte pour ca. On en a marre de se taper des systèmes proprietaires pleins de bugs qu'on ne peut pas corriger.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Miod Vallat
Ca n'est pas incompatible: si des boites utilisent de l'open source, elles peuvent de temps à autre payer quelqu'un pour remettre à niveau certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs. Certes, mais rien ne les oblige à le faire (ou à rendre ces
dépoussiérages et améliorations publiques)...
Ils le font pourtant souvent, et pour plusieurs raisons.
Ils le font le moins possible. Le compte-gouttes, pour des choses sans importance, suffit à t'attirer la sympathie populaire, et tu n'as besoin de rien de plus.
La première, c'est que vendre du logiciel basé sur du logiciel libre, c'est dur. Y'a la version libre à coté, faut mettre le paquet pour eviter qu'elle ne te rattrape. Surtout qu'en partant de ses sources, tu
Pas vraiment. Tu peux déguiser tant que tu veux. Intégrer comme partie insignifiante-en-apparence-mais-pas-du-tout-en-fait au sein d'une application métier. Ça marche rudement bien.
as eventuellement bien excité un ou deux developpeurs doués qui vont prendre un malin plaisir à re-implementer en libre les avantages competitifs que tu t'es escrimer à mettre en place. La strategie super à la mode, c'est donc de ne même pas essayer de vendre le logiciel, mais de vendre du service ou du materiel.
Le côté «aiguillon» fonctionne mieux dans les dires que dans la réalité. Apple en profite très bien, d'ailleurs.
La deuxieme raison, elle est là: le support de la communauté. Tu y gagnes la relecture de ton code, les contributions des autres, et le support technique assuré en partie par la communauté.
Ce point étant bien l'Esbrouffe, avec un E majuscule, du libre. De la même façon que les vendeurs de logiciels propriétaires agitent le père fouettard du thème «si vous piratez, vous aurez des virus», les contributeurs du libre agitent la carotte du thème «si vous opensourcez, on relira et corrigera votre code».
Non seulement, peu de gens le font, mais en plus, il s'agit rarement des gens les plus compétents. Si par hasard des gens compétents, capables d'apporter un plus à ton code, ils ne le feront que s'ils sont fortement intéressés par le code que tu publies, ce qui réduit encore le public de personnes concernées.
Tiens, dis, j'ai dans mon escarcelle du code pour la plate-forme Siemens Callbridge CP, qui n'a été vendue qu'en Suisse (pour un client avec lequel Siemens ne pouvait pas courir le risque de se fâcher). À peine trois mille lignes, dont un tiers qui sont des palliatifs pour des problèmes dans le comportement de CB CP avec la spécification Callpath d'IBM (a l'époque). Si je convaincs mon entreprise de la diffuser en open source, viendras-tu en corriger les problèmes ?
Ah oui, c'est peut-être un peu trop métier... (-:
La troisieme raison, c'est que la demande du public est de plus en plus forte pour ca. On en a marre de se taper des systèmes proprietaires pleins de bugs qu'on ne peut pas corriger.
Oui, et puis ? Tout ceci mène à des initiatives comme la diffusion verrouillé de sources, telle que la font Sun ou Microsoft. Rien ne change, sauf que tu as l'illusion de pouvoir faire quelque chose. Mais si tu t'aventures à modifier le code, tu te rends soudain compte qu'il te manque de nombreux outils de développement qui, eux, ne sont certainement pas gratuits et pour lequel tu n'as pas la licence...
Tous les systèmes ne sont pas aussi simples à compiler qu'un *BSD où un compilateur C suffit, et construira awk, flex, pmake, yacc et config, qui suffiront pour le reste...
Ca n'est pas incompatible: si des boites utilisent de l'open source,
elles peuvent de temps à autre payer quelqu'un pour remettre à niveau
certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs.
Certes, mais rien ne les oblige à le faire (ou à rendre ces
dépoussiérages et améliorations publiques)...
Ils le font pourtant souvent, et pour plusieurs raisons.
Ils le font le moins possible. Le compte-gouttes, pour des choses sans
importance, suffit à t'attirer la sympathie populaire, et tu n'as
besoin de rien de plus.
La première, c'est que vendre du logiciel basé sur du logiciel libre,
c'est dur. Y'a la version libre à coté, faut mettre le paquet pour
eviter qu'elle ne te rattrape. Surtout qu'en partant de ses sources, tu
Pas vraiment. Tu peux déguiser tant que tu veux. Intégrer comme partie
insignifiante-en-apparence-mais-pas-du-tout-en-fait au sein d'une
application métier. Ça marche rudement bien.
as eventuellement bien excité un ou deux developpeurs doués qui vont
prendre un malin plaisir à re-implementer en libre les avantages
competitifs que tu t'es escrimer à mettre en place. La strategie super à
la mode, c'est donc de ne même pas essayer de vendre le logiciel, mais
de vendre du service ou du materiel.
Le côté «aiguillon» fonctionne mieux dans les dires que dans la réalité.
Apple en profite très bien, d'ailleurs.
La deuxieme raison, elle est là: le support de la communauté. Tu y
gagnes la relecture de ton code, les contributions des autres, et le
support technique assuré en partie par la communauté.
Ce point étant bien l'Esbrouffe, avec un E majuscule, du libre. De la
même façon que les vendeurs de logiciels propriétaires agitent le père
fouettard du thème «si vous piratez, vous aurez des virus», les
contributeurs du libre agitent la carotte du thème «si vous opensourcez,
on relira et corrigera votre code».
Non seulement, peu de gens le font, mais en plus, il s'agit rarement des
gens les plus compétents. Si par hasard des gens compétents, capables
d'apporter un plus à ton code, ils ne le feront que s'ils sont fortement
intéressés par le code que tu publies, ce qui réduit encore le public de
personnes concernées.
Tiens, dis, j'ai dans mon escarcelle du code pour la plate-forme Siemens
Callbridge CP, qui n'a été vendue qu'en Suisse (pour un client avec
lequel Siemens ne pouvait pas courir le risque de se fâcher). À peine
trois mille lignes, dont un tiers qui sont des palliatifs pour des
problèmes dans le comportement de CB CP avec la spécification Callpath
d'IBM (a l'époque). Si je convaincs mon entreprise de la diffuser en
open source, viendras-tu en corriger les problèmes ?
Ah oui, c'est peut-être un peu trop métier... (-:
La troisieme raison, c'est que la demande du public est de plus en plus
forte pour ca. On en a marre de se taper des systèmes proprietaires
pleins de bugs qu'on ne peut pas corriger.
Oui, et puis ? Tout ceci mène à des initiatives comme la diffusion
verrouillé de sources, telle que la font Sun ou Microsoft. Rien ne
change, sauf que tu as l'illusion de pouvoir faire quelque chose. Mais
si tu t'aventures à modifier le code, tu te rends soudain compte qu'il
te manque de nombreux outils de développement qui, eux, ne sont
certainement pas gratuits et pour lequel tu n'as pas la licence...
Tous les systèmes ne sont pas aussi simples à compiler qu'un *BSD où un
compilateur C suffit, et construira awk, flex, pmake, yacc et config,
qui suffiront pour le reste...
Ca n'est pas incompatible: si des boites utilisent de l'open source, elles peuvent de temps à autre payer quelqu'un pour remettre à niveau certains elements. IBM surfe pas mal sur cette tendance, d'ailleurs. Certes, mais rien ne les oblige à le faire (ou à rendre ces
dépoussiérages et améliorations publiques)...
Ils le font pourtant souvent, et pour plusieurs raisons.
Ils le font le moins possible. Le compte-gouttes, pour des choses sans importance, suffit à t'attirer la sympathie populaire, et tu n'as besoin de rien de plus.
La première, c'est que vendre du logiciel basé sur du logiciel libre, c'est dur. Y'a la version libre à coté, faut mettre le paquet pour eviter qu'elle ne te rattrape. Surtout qu'en partant de ses sources, tu
Pas vraiment. Tu peux déguiser tant que tu veux. Intégrer comme partie insignifiante-en-apparence-mais-pas-du-tout-en-fait au sein d'une application métier. Ça marche rudement bien.
as eventuellement bien excité un ou deux developpeurs doués qui vont prendre un malin plaisir à re-implementer en libre les avantages competitifs que tu t'es escrimer à mettre en place. La strategie super à la mode, c'est donc de ne même pas essayer de vendre le logiciel, mais de vendre du service ou du materiel.
Le côté «aiguillon» fonctionne mieux dans les dires que dans la réalité. Apple en profite très bien, d'ailleurs.
La deuxieme raison, elle est là: le support de la communauté. Tu y gagnes la relecture de ton code, les contributions des autres, et le support technique assuré en partie par la communauté.
Ce point étant bien l'Esbrouffe, avec un E majuscule, du libre. De la même façon que les vendeurs de logiciels propriétaires agitent le père fouettard du thème «si vous piratez, vous aurez des virus», les contributeurs du libre agitent la carotte du thème «si vous opensourcez, on relira et corrigera votre code».
Non seulement, peu de gens le font, mais en plus, il s'agit rarement des gens les plus compétents. Si par hasard des gens compétents, capables d'apporter un plus à ton code, ils ne le feront que s'ils sont fortement intéressés par le code que tu publies, ce qui réduit encore le public de personnes concernées.
Tiens, dis, j'ai dans mon escarcelle du code pour la plate-forme Siemens Callbridge CP, qui n'a été vendue qu'en Suisse (pour un client avec lequel Siemens ne pouvait pas courir le risque de se fâcher). À peine trois mille lignes, dont un tiers qui sont des palliatifs pour des problèmes dans le comportement de CB CP avec la spécification Callpath d'IBM (a l'époque). Si je convaincs mon entreprise de la diffuser en open source, viendras-tu en corriger les problèmes ?
Ah oui, c'est peut-être un peu trop métier... (-:
La troisieme raison, c'est que la demande du public est de plus en plus forte pour ca. On en a marre de se taper des systèmes proprietaires pleins de bugs qu'on ne peut pas corriger.
Oui, et puis ? Tout ceci mène à des initiatives comme la diffusion verrouillé de sources, telle que la font Sun ou Microsoft. Rien ne change, sauf que tu as l'illusion de pouvoir faire quelque chose. Mais si tu t'aventures à modifier le code, tu te rends soudain compte qu'il te manque de nombreux outils de développement qui, eux, ne sont certainement pas gratuits et pour lequel tu n'as pas la licence...
Tous les systèmes ne sont pas aussi simples à compiler qu'un *BSD où un compilateur C suffit, et construira awk, flex, pmake, yacc et config, qui suffiront pour le reste...
