J'ai voulu chercher un remplacant dans ma boite et je vais finir oblige d'installer un serveur exchange et de payer un admin windows. C'est quand meme triste mais vraiment, les alternatives libres ne tiennent pas la route.
Pour vraiment favoriser ce type de retour, et bénéficier de l'effet d'entrainement du logiciel libre, je te suggère de mettre un lien sur la page ou on conjugue pour signaler les problèmes.
Voire même de proposer d'aider à remplir la base d'une façon ou d'une autre. C'est a mon avis quelque chose qui devrait être synchronisé avec les autres projets également. Ils devraient proposer directement dans le logiciel de reporter un verbe manquant ou mal conjugué.
Dans les logiciels KDE, il y a dans la menu "A propos" un lien pour reporter un bug sur l'interface web. Tu arrives sur l'interface avec le nom du logiciel et le nom du système d'exploitation pré-rempli. Ce système a vraiment permis d'augmenter le nombre de report, parce que c'est tout simplement plus facile et plus rapide.
Si vous arrivez à mettre en place un tel système, je suis sur que la base pourrait grossir assez vite.
Rien que sur la page principale de sans-mot-dire, il faudrait mettre à mon avis un petit texte du genre : Les verbes conjugués sont issus d'une base de données de verbes, qui est libre et non commerciale. Si vous rencontrez des erreurs ou des omissions, vous êtes invités à nous le signaler par le lien ci-joint et à nous aider à améliorer la base de donnée. C'est avec votre aide qu'elle deviendra de meilleure qualité.
Tout changement majeur dans un logiciel de cette taille necessite beaucoup de travail et beaucoup de temps. De meme, il s'est ecoule beaucoup beaucoup de temps entre la derniere version stable de Gnome 1 et la premiere version stable de Gnome 2.
Un certain nombre de technologies nouvelles sont inscrites au programme de KDE 4.0 , et elles demandent du travail pour arriver a maturite.
J'etait plutot inquiet il y a 6 mois du manque de visibilite d'une prochaine sortie et de l'instabilite de KDE. En lisant les derniers KDE traffic, on voit que toutes les nouvelles technologies sont en phase de stabilisation et que donc les choses se precisent clairement. Moi, je vois bien KDE 4 sortir cet ete.
J'ai du mal à imaginer que tu ne puisses pas comprendre ce que je dis.
Il se trouve que j'ai créé avec succès deux boites, la première où on faisait un produit purement logiciel, et l'autre où on faisait (et fait toujours) du logiciel pour carte à puce qui doit être en rom.
Dans le premier cas, on produisait des logiciels, dans le second, on produit des microcontrolleurs qui contiennent du code non modifiable. C'est à dire qu'on est très proche du principe d'un produit hardware.
Dans ma première boite, en 1 an et demi, on a dépensé à trois environ 4000 euro. Plusieurs ordinateurs, une licence Visual Studio, une licence Qt plus quelques broutilles. Note qu'au bout de 6 mois, on avait déjà un produit montrable pour convaincre nos clients.
Dans ma deuxième boite, même effectif humain de départ. Rien qu'en logiciel on est déjà autour des 10000 euro (licence des compilos proprio). Il nous a fallu un an et demi pour lancer la première fabrication qui a couté environ 30 000 euro. A partir de ce moment là on a eu des prototypes, non vendables. Pour notre premier produit, on a du relancer une fabrication (un peu moins cher cette fois : 15000 euro) et faire une certification du produit (environ 35 000 euro). Finalement, ce n'est même pas ce produit là qu'on a vendu, il a fallu en refaire un autre.
Et là, je n'ai mis aucun coût de salaire. Juste du matériel, du logiciel et de la production.
Pour en revenir au sujet, les coûts initiaux pour un développement hardware, quoi que tu en penses, sont sans commune mesure avec les coûts de développement software.
<<
Tu répond au cout de production après conception en parlant .. du coup de conception intial.
>>
Pour parler du coût d'un produit, tu es obligé de tenir compte de tous les coûts. Le coût de développement initial est tellement important qu'il impacte de façon majeur la marge que tu dois faire sur la production. Dans mon industrie, on ne commence à faire des bénéfices qu'au delà du millions de pièces produites. Quand le client est exigeant, c'est au delà des 3 premiers millions. C'est super difficile de sortir des marchés de plusieurs millions de pièces, donc c'est difficile de rentabiliser juste le développement.
<<
Elle est où la différence avec le gars qui quitte son boulot, créé sa société, mis son temps pour faire un début de développement logiciel. Ensuite il embauche des gens pour continuer, tester, valider. Il embauche encore quelqu'un pour lui parler du coté fonctionnel et valider les calculs, le travail. Il écrit des specs, des connecteurs.
>>
Il y en a plusieurs des différences. L'idée, c'est que quand tu démarres une société en logiciel, tu réduis les coûts au minimum, et c'est possible :
- tu ne te paye pas de salaire
- en général, tu n'as pas de salarié non plus. Dans le meilleurs des cas, tu as un associé qui comme toi n'a pas de salaire
- les compilos sont libres
- pas de coût de production
- tu peux montrer des prototypes à tes clients sans débourser beaucoup
Au final, tu peux démarrer ton projet logiciel pour quelques milliers d'euro. Typiquement, tu vas commencer en mode garage et quand tu auras un proto qui marche et un client prêt à acheter la version finale, tu envisgeras d'embaucher des gens.
Dans le cas du demarrage d'un projet hardware, même en résuisant les coûts au maximum maximum et en restant en mode garage, tu vas t'en sortir pour 50 000 euro. D'où un besoin beaucoup plus important d'assurer tes arrières.
<<
Tous ces gens ils ont besoin de prendre des précautions pour revenir dans leurs couts, qu'ils fassent du hard ou du soft. Ce n'est pas parce que le soft n'est pas tangible qu'il ne coute rien.
>>
Sauf que les coûts dans l'un et l'autre cas sont d'un rapport 10.
Je vois pas trop ce que je peux dire de plus pour te convaincre. Créée une boite pour vendre du hardware libre, on en reparlera.
<<
Je trouve effarant que sur un site dominé par les informaticiens on arrive encore à lire des textes qui insinuent que le coût d'un logiciel est nul ou négligeable (je parle bien du coût, pas du prix)
>>
Bien sur qu'il y a un coût de production d'un logiciel. Mais le coût de production peut pour la très grande partie être converti en temps qui ne coûte relativement rien (quand c'est le tien). Pour le hard, c'est pas convertible (et en plus, tu as en général le même coût en temps personnel).
Autre problème, le coût d'une erreur. Si tu as un bug grave dans ton soft, tu peux faire une mise à jour et l'envoyer à tes clients et deux jours après, tu es un peu moins crédible mais ton problème est résolu.
Dans une carte à puce, si tu as un bug grave, tu as perdu 45 000 euro et tu dois repayer 45 000 euro pour une nouvelle production et tu repars pour un cycle de fabrication d'environ 4 mois pendant lesquels tu vas perdre des clients.
Rien qu'avec ton exemple de l'informaticien passionné et de l'électronicien passionné, on voit la différence. Pour une informaticien passionné, il faut une babasse et un accès internet et il peut s'amuser. Pour un électronicien passionné, il va falloir une babasse, très probablement un accès internet, un poste à souder, des cartes micro-controlleurs, éventuellement un compilateur proprio s'il utilise du matériel hyper spécifique, plus pas mal de matériel électronique. Si il veut faire du pas moche, il faudra même qu'il se paye un moule en plastique. S'il veut faire 10 protos pour ses copains, il faudra qu'il paye le matériel 10 fois. Alors qu'un logiciel peut être téléchargé des milliiers de fois sur sourceforge sans couter un bezef au développeur.
<<
Le coût de production du matériel est beaucoup plus important que celui du logiciel, c'est indéniable. Maintenant ce coût de production il est équivalent chez l'auteur initial et chez le copieur. Ce n'est pas ça qui peut justifier la différence avec la philosophie du libre dans le logiciel.
>>
Ben si. L'auteur de la carte a quitte son boulot, cree une societe, mis son temps et beaucoup de son argent pour faire le design de sa carte. Il va encore investir temps et argent pour debugger le fpga, produire la version ASIC en petite serie, la debugger et enfin avoir a peu pres une carte qui marche.
Il va aussi passer du temps a documenter les specs, ecrire des bouts de drivers, etc etc.
Transversal tech a besoin de recouvrer les couts de toutes ces etapes.
Le copieur lui peut partir du design final et le mettre en production.
En faisant court a l'extreme, on peut dire qu'une grosse difference entre le logiciel libre et le hardware libre, c'est que gcc, c'est gratuit et que copier un logiciel a des millers d'exemplaires, c'est gratuit aussi. Ce n'est pas le cas pour le hardware.
<<
Je tiens juste à remettre les choses dans leur contexte. L'argument des coûts de développements que tu donnes pour justifier la partie non libre, il vaut autant pour le logiciel que pour le matériel.
>>
Ben non. Demarrer un projet logiciel libre et le developper, ca ne coute rien : l'hebergement est gratuit, les compilateurs sont gratuits, le temps personnel est gratuit. Donc tu peux te permettre de tout "donner".
Pour du materiel, tu as un investissement considerable. Juste pour info, la production d'un masque permettant de fabriquer des micro-controlleurs en grosse production coute entre 10ke et 30ke (je parle de mon industrie ici, la carte a puce).
Si tu rajoutes tous les autres couts, tu comprends que l'auteur aie envie de prendre ses precautions pour revenir dans ses couts.
On peut tourner l'argument autrement. A vue de nez, je dirai que l'auteur a mis 2 a 3 annees de salaires dans son projet (je parle en tant que createur d'entreprise). Si toi, tu faisais la meme demarche, mettre 2 a 3 annees de salaires dans un projet, est-ce que tu dirais "oui, les taiwanais soyez gentil, j'ai besoin de rentabiliser ma societe donc me copiez pas tout de suite" ou bien est-ce que tu garderai un mecansimse pour te proteger un minimum ?
Il est evident que l'auteur de ce beau projet de carte graphique a vraiment envie de faire un projet le plus libre possible. Je pense qu'il a regarde cette problematique sous tous les angles possibles et qu'il est parvenu a la conclusion qu'il fallait garder une partie proprio parce que sinon, le risque financier etait trop important pour lui.
Je me suis lance recemment dans Zope, et je dois dire que c'est l'horreur niveau documentation.
Les dernieres version de Zope 2 ne sont pas disponibles en package pour windows, la moitie des liens sur le site web de zope pointent vers des pages inexistantes. Il y a environ 500 produits disponibles avec une description de 1 ligne, donc on ne sait pas vraiment a quoi ils servent ni pour quelle version de zope ils sont disponibles.
Pour ce qui est de zope 3, la documentation est completement a la ramasse. Finalement, j'en etais reste a zope 2 puisque au moins, il y avait un peu de documentation.
J'espere que la communaute zope va reagir un peu et mettre en place de la documentation potable.
C'est vraiment dommage car zope a l'air d'un produit pas mal. Si on regarde du cote de python, sur lequel il est largement base, la documentation est tres bien gere, les modules sont propres, les extensions claires, etc etc.
Je suis surpris de ne le voir mentionne nulle part, alors que ca repond exactement a la problematique evoquee, et ce avec succes, depuis plusieurs mois.
Pourtant, c'est pas comme si le code des logiciels libres etait un modele de beaute. Il y a pas mal de logiciel avec du code immonde.
Des differents articles que j'ai lu (Joel on software en parle pas mal notamment), le developpement de la facon dont il est fait a microsoft est plutot un modele du genre. Tous les logiciels libres ne peuvent pas en dire autant.
Je te signal par exemple que les logiciels ecrit en windows 3.1 tournent toujours et compilent toujours sous windows XP. Combien de logiciels libres sont en mesure d'assurer la compabilite binaire sur 20 ans ?
Faisons un petit bilan:
- linux : cassage de la compabilite binaire tous les mois
- KDE, Gnome : cassage de la compabilite binaires tous les 2-3 ans
- Firefox : cassage de la compabilite des extensions a chaque release mineure
- gcc : pourtant une brique fondamentale, mais cassage de la compabilite au gres des release (et bien a leur insu).
Quand tu vois que l'ensemble des logiciels maintenus par Microsoft represente environ une 50aine de logiciels libres et qu'ils arrivent quand meme a garder la compabilite, tu mesures mieux le travail qu'ils font et sa qualite.
Combien de logiciels libres font des nightly builds ? Combien font systematiquement des tests unitaires ?
Je pense qu'il y a certains logiciels dont les techinques de dev sont au dessus de la moyenne mais dans l'ensemble, c'est souvent en dessous.
Pour prendre un exemple que je connais bien, les tests unitaires et KDE : il y a eu suffisamment de literature pour voir l'interet fondamental de cette pratique. Ca ne fait qu'un ou deux ans que c'est mis en place plus ou moins systematiquement sur KDE.
Je me demande depuis combien d'annees c'est fait chez Microsoft.
En resume, je rejoins tout a fait timaniac. C'est debile de denigrer Microsoft sur des elements qui n'ont aucun fondement. Il y a suffisamment d'elements reels pour ne pas se decredibiliser avec des arguments farfelus.
Un gourou lisp a dit :
<< Dans tout programme de plus de 10000 lignes, il y a forcement un compilateur LISP cache quelque part >>
Je me souviens plus du nombre de lignes, mais je tend a etre d'accord. Des que tu fais un gros projet, tu tombes souvent sur des problematiques de calcul intelligent interne ou de notion de logique, qui au final pourraient tres bien se resoudre avec du LISP.
<< si en plus tu profite de la communauté pour améliorer ton jeu au fur et à mesure ça me parait faisable.
>>
Le miracle de la communaute qui va ameliorer ton jeu alors que tu ne fais rien, c'est encore a voir. Pour contribuer a un jeu comme cela, il faut un tres tres bon niveau, donc il y a tres peu de candidats. Il y a des milliers de projets open source qui n'ont jamais recu une ligne de code de "la communaute". Quelques uns sortent du lot, mais c'est une alchimie difficile a mettre en place.
Perso, j'ai toujours ete sceptique quant au modele d'un jeu entierement libre. C'est genial d'un point de vue global, mais je ne crois pas que ca tienne la route economiquement, et les dernieres nouvelles semblent tristement confirmer cela.
Un jeu, ca coute beaucoup d'argent et quand il est entierement libre, il faut bien reconnaitre que la boite gagne beaucoup moins d'argent qu'avec les modeles purement commerciaux et ouverts.
Les développeurs de kopete sont en train d'étudier une migration complète vers telepathy, et on commencer quelques tests avec un plugin. Je pense que ça voudrait dire plein de bonnes choses pour les deux projets.
Bonobo, c'est la surcouche de Corba qui permet aux applis Gnome de communiquer. Je pense que la phrase est juste, dbus va remplacer bonobo et par là même Corba.
Sinon, dbus, c'est de la balle. Cela va permettre de faire des services qui pourront être utilisés par tous les environnements de bureau de façon indifférente.
Les notifications hardware sont les premiers services à être intégrés dans dbus, mais il va y en avoir d'autres. C'est grâce à des projets comme ça que les bureaux libres peuvent avancer sans se marcher sur les pieds les uns les autres.
xdg-utils permet de faire des opérations standards pour plusieurs desktop :
- installer une entrée menu pour une application
- lancer l'application associée à un fichier donné
- contrôle le screen saver
C'est rien mais le niveau d'intégration qu'il faut pour faire ces choses proprement sur chaque desktop est loin d'être ridicule.
Globalement, ca fait plaisir de voir des leaders des différents projets avancer ensemble sur ces sujets.
CRM114, j'avais regarde, ca a l'air plutot mortel a mettre en place.
De mon cote, c'est greylisting + spamassassin + bogofilter + junk mail filter de thunderbird.
Resultat a la louche :
- spamassassin pas super efficace sur mon compte a moi
- grey listing super efficace
- bogofilter super lent a l'apprentissage
- junk mail filter de thunderbird hyper efficace. Ca m'a plutot surpris.
Et surtout, on le remercie de maintenir NVu et de corriger les bugs qui y sont presents.
Ah ben non, il ne maintient plus la branche NVu 1.0 et il refuse les patchs correctifs qu'on lui envoie. On le remercie quand meme alors en attendant de decouvrir pourquoi.
T'as pense a changer de telephone portable au fait ? Parce que la, ton telephone est bourre de soft proprietaire. Et ton lecteur DVD, ton lecteur de musique portable, etc ?
D'un autre cote, Suse n'a pas les moyens de passer un contrat au noms des developpeurs de Redhat, Mandriva et autres, quand bien meme ils en auraient la volonte.
Cet accord laisse penser que les autres distributions open source ont une chance d'obtenir le meme type de contrat avec Microsoft. Certe, Mandriva n'est pas Novell mais ce qui a ete fait une fois doit pouvoir etre renouvele.
Le projet repond a une problematique que se posent beaucoup de decideurs : qu'en est-il de la qualite des projets open source ? Dans la mesure ou beaucoup de ces projets sont developpes par des individus dont on ne sait a priori pas grand chose, la reponse n'est pas forcement evidente.
En fournissant des outils de mesure de qualite, on peut prouver la qualite effective des projets open source, et faciliter certaines decisions.
Independamment des decideurs presses, ce type d'outil peut aussi etre utile a des projets open source pour ameliorer leur qualite sur certains critres objectifs. Je pense par exemple a coverity. Il est indeniable que le nombre de problemes de securite d'un projet est un indice de sa qualite et les scans de coverity ont contribue a augmenter globalement la qualite de projets open source. Il y a eu le meme effet avec EBN (cf mon post plus haut pour voir ce qu'est EBN).
La relation avec KDE est pour ce que j'en ai compris, que KDE sert d'etalon initial aux outils de mesure. Non pas pour dire "KDE rocks" mais pour jouer sur le fait que KDE est une tres grosse base de code que Sebastian connait bien, sur laquelle il est capable de verifier que les outils qu'il developpent donnent un resultat coherent (ils sait ou le code de KDE est pourri et la ou il est bien).
On peut se poser la question de la qualite des projets close source commerciaux. Pour ce type de projet, finalement, l'unique etalon de mesure a l'heure actuelle, c'est le succes de la societe qui vend le produit. Si la societe marche bien, on suppose que c'est parce que le produit est de bonne qualite.
J'avoue en revanche que je trouve tout comme vous le site web pourri et que c'est que parce que je connais Sebastian Kugler et qu'il m'a parle de ce projet et a quel point ca lui tient a coeur que j'ai confiance de ce qui en ressortira
J'ai discute avec Sebastian Kugler, qui est un activiste de KDE (sur le plan de la communication notamment) et qui vient de rentrer au board de KDE. Il fait partie de ce projet, ainsi que Adriaan de Groot.
Adriaan maintient "the english breakfast network" ( http://www.englishbreakfastnetwork.org/ ) qui sous un nom assez obtus, est un site web faisant des analyses de code sur le code de KDE et reporte des problemes standards:
- methodes, classes ou parametres non documentees
- analyses sur la documentation utilsateur (problemes d'utilisation de docbook)
- analyses sur le code, pour chercher des constructions non optimisees, des petites erreurs, des problemes dans l'assignation des licences, etc.
J'avoue avoir initialement les memes reserves que vous sur ce projet mais en discutant avec lui, j'ai vu qu'il y avait une approche a la fois pratique et academique.
Note: l'analyseur de code est base sur le parser de C++ de kdevelop
Le projet part donc deja avec quelques outils.
Sebastian et Adriaan ont une tres bonne comprehension de l'open source et sont des gens tres pragmatiques. Je leur fais confiance pour ne pas nous sortir un machin completement inutilisable.
La metrique utilisee par EBN est super simpliste: documenter toutes ses fonctions et tous ses parametres, eviter des constructions dangereuses, non optimisees, obsoletes ou jettant un flou juridique (melange de licence, fichiers avec une mauvaise licence, etc). Elle ne permet pas de mesurer objectivement la qualite de KDE. Mais deja, elle a permis d'ameliorer la qualite du code de KDE.
Donc meme si on a aboutit pas a des outils mettant une note objective sur 20 a un projet, on aboutira pour sur a des outils permettant globalement d'ameliorer la qualite de nos chers projects Open Source, de la meme facon que les scan de coverity ont ameliorer la securite des projets open source.
Je suis quand meme convaincu que avec des gens intelligent comme Sebastian, le projet ira beaucoup plus loin que cela.
J'ai galere aussi avec pydoc et avec les autres generateurs de documentation sous python. Globalement, je reste tres decu de l'etat de tout ca.
DOxygen est quand meme celui qui a le plus de potentiel, etant donne la qualite de la documentation qu'il genere (en C++ et en java). Vivement que quelqu'un reporte le flambeau du parser python.
Quelqu'un l'a deja utilise en python ? La derniere fois que j'ai essaye, c'etait bugge a mort. Impossible d'avoir du cross referencement correct des noms de fonctions dans les autres documentations. Les variables globales etaient ignorees. Soi-disant, ca supporte la documentation format python mais en fait, ca ne marchait pas du tout. Etc etc.
J'ai pas l'impression que la generation python soit testee correctement.
En gros, en un an et demi, il n'etait pas possible de corriger les bugs (sournois certe) mis en evidence par le test acid2 sur une branche stable de gecko.
Alors que Konqueror a corrige ces meme bugs en 9 mois sur une branche stable ?
Ca fait pas tres serieux quant a l'energie qui est investie dans le developpement de gecko ou dans la qualite du moteur html.
Pour les versions traduites, c'est en cours de refonte. Il y a eu une session sur ce sujet lors de akademy. En fait, c'est un truc vraiment complexe que de faire un site web traduisible en 23 langues, accessibles aux handicapes, propre, facile a naviguer, joli, facile a faire evoluer et qui resiste bien a la charge.
Si vous voulez participer d'ailleurs, l'equipe web de KDE cherche de l'aide.
[^] # Re: Pour migrer, ok, mais après ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche OpenChange: Communiquez avec Exchange depuis Linux. Évalué à 1.
J'ai voulu chercher un remplacant dans ma boite et je vais finir oblige d'installer un serveur exchange et de payer un admin windows. C'est quand meme triste mais vraiment, les alternatives libres ne tiennent pas la route.
[^] # Re: Le choix c'est bien...
Posté par Philippe F (site web personnel) . En réponse à la dépêche La conjugaison française libre. Évalué à 3.
Voire même de proposer d'aider à remplir la base d'une façon ou d'une autre. C'est a mon avis quelque chose qui devrait être synchronisé avec les autres projets également. Ils devraient proposer directement dans le logiciel de reporter un verbe manquant ou mal conjugué.
Dans les logiciels KDE, il y a dans la menu "A propos" un lien pour reporter un bug sur l'interface web. Tu arrives sur l'interface avec le nom du logiciel et le nom du système d'exploitation pré-rempli. Ce système a vraiment permis d'augmenter le nombre de report, parce que c'est tout simplement plus facile et plus rapide.
Si vous arrivez à mettre en place un tel système, je suis sur que la base pourrait grossir assez vite.
Rien que sur la page principale de sans-mot-dire, il faudrait mettre à mon avis un petit texte du genre :
Les verbes conjugués sont issus d'une base de données de verbes, qui est libre et non commerciale. Si vous rencontrez des erreurs ou des omissions, vous êtes invités à nous le signaler par le lien ci-joint et à nous aider à améliorer la base de donnée. C'est avec votre aide qu'elle deviendra de meilleure qualité.
[^] # Re: PAM ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouvelles fonctions de hachage. Évalué à 10.
--------> []
[^] # Re: Retard...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Semaine KDE à Paris. Évalué à 3.
Un certain nombre de technologies nouvelles sont inscrites au programme de KDE 4.0 , et elles demandent du travail pour arriver a maturite.
J'etait plutot inquiet il y a 6 mois du manque de visibilite d'une prochaine sortie et de l'instabilite de KDE. En lisant les derniers KDE traffic, on voit que toutes les nouvelles technologies sont en phase de stabilisation et que donc les choses se precisent clairement. Moi, je vois bien KDE 4 sortir cet ete.
[^] # Re: Pas vraiment libre
Posté par Philippe F (site web personnel) . En réponse à la dépêche Projet Open Graphics : 1ère étape terminée. Évalué à 10.
Il se trouve que j'ai créé avec succès deux boites, la première où on faisait un produit purement logiciel, et l'autre où on faisait (et fait toujours) du logiciel pour carte à puce qui doit être en rom.
Dans le premier cas, on produisait des logiciels, dans le second, on produit des microcontrolleurs qui contiennent du code non modifiable. C'est à dire qu'on est très proche du principe d'un produit hardware.
Dans ma première boite, en 1 an et demi, on a dépensé à trois environ 4000 euro. Plusieurs ordinateurs, une licence Visual Studio, une licence Qt plus quelques broutilles. Note qu'au bout de 6 mois, on avait déjà un produit montrable pour convaincre nos clients.
Dans ma deuxième boite, même effectif humain de départ. Rien qu'en logiciel on est déjà autour des 10000 euro (licence des compilos proprio). Il nous a fallu un an et demi pour lancer la première fabrication qui a couté environ 30 000 euro. A partir de ce moment là on a eu des prototypes, non vendables. Pour notre premier produit, on a du relancer une fabrication (un peu moins cher cette fois : 15000 euro) et faire une certification du produit (environ 35 000 euro). Finalement, ce n'est même pas ce produit là qu'on a vendu, il a fallu en refaire un autre.
Et là, je n'ai mis aucun coût de salaire. Juste du matériel, du logiciel et de la production.
Pour en revenir au sujet, les coûts initiaux pour un développement hardware, quoi que tu en penses, sont sans commune mesure avec les coûts de développement software.
<<
Tu répond au cout de production après conception en parlant .. du coup de conception intial.
>>
Pour parler du coût d'un produit, tu es obligé de tenir compte de tous les coûts. Le coût de développement initial est tellement important qu'il impacte de façon majeur la marge que tu dois faire sur la production. Dans mon industrie, on ne commence à faire des bénéfices qu'au delà du millions de pièces produites. Quand le client est exigeant, c'est au delà des 3 premiers millions. C'est super difficile de sortir des marchés de plusieurs millions de pièces, donc c'est difficile de rentabiliser juste le développement.
<<
Elle est où la différence avec le gars qui quitte son boulot, créé sa société, mis son temps pour faire un début de développement logiciel. Ensuite il embauche des gens pour continuer, tester, valider. Il embauche encore quelqu'un pour lui parler du coté fonctionnel et valider les calculs, le travail. Il écrit des specs, des connecteurs.
>>
Il y en a plusieurs des différences. L'idée, c'est que quand tu démarres une société en logiciel, tu réduis les coûts au minimum, et c'est possible :
- tu ne te paye pas de salaire
- en général, tu n'as pas de salarié non plus. Dans le meilleurs des cas, tu as un associé qui comme toi n'a pas de salaire
- les compilos sont libres
- pas de coût de production
- tu peux montrer des prototypes à tes clients sans débourser beaucoup
Au final, tu peux démarrer ton projet logiciel pour quelques milliers d'euro. Typiquement, tu vas commencer en mode garage et quand tu auras un proto qui marche et un client prêt à acheter la version finale, tu envisgeras d'embaucher des gens.
Dans le cas du demarrage d'un projet hardware, même en résuisant les coûts au maximum maximum et en restant en mode garage, tu vas t'en sortir pour 50 000 euro. D'où un besoin beaucoup plus important d'assurer tes arrières.
<<
Tous ces gens ils ont besoin de prendre des précautions pour revenir dans leurs couts, qu'ils fassent du hard ou du soft. Ce n'est pas parce que le soft n'est pas tangible qu'il ne coute rien.
>>
Sauf que les coûts dans l'un et l'autre cas sont d'un rapport 10.
Je vois pas trop ce que je peux dire de plus pour te convaincre. Créée une boite pour vendre du hardware libre, on en reparlera.
<<
Je trouve effarant que sur un site dominé par les informaticiens on arrive encore à lire des textes qui insinuent que le coût d'un logiciel est nul ou négligeable (je parle bien du coût, pas du prix)
>>
Bien sur qu'il y a un coût de production d'un logiciel. Mais le coût de production peut pour la très grande partie être converti en temps qui ne coûte relativement rien (quand c'est le tien). Pour le hard, c'est pas convertible (et en plus, tu as en général le même coût en temps personnel).
Autre problème, le coût d'une erreur. Si tu as un bug grave dans ton soft, tu peux faire une mise à jour et l'envoyer à tes clients et deux jours après, tu es un peu moins crédible mais ton problème est résolu.
Dans une carte à puce, si tu as un bug grave, tu as perdu 45 000 euro et tu dois repayer 45 000 euro pour une nouvelle production et tu repars pour un cycle de fabrication d'environ 4 mois pendant lesquels tu vas perdre des clients.
Rien qu'avec ton exemple de l'informaticien passionné et de l'électronicien passionné, on voit la différence. Pour une informaticien passionné, il faut une babasse et un accès internet et il peut s'amuser. Pour un électronicien passionné, il va falloir une babasse, très probablement un accès internet, un poste à souder, des cartes micro-controlleurs, éventuellement un compilateur proprio s'il utilise du matériel hyper spécifique, plus pas mal de matériel électronique. Si il veut faire du pas moche, il faudra même qu'il se paye un moule en plastique. S'il veut faire 10 protos pour ses copains, il faudra qu'il paye le matériel 10 fois. Alors qu'un logiciel peut être téléchargé des milliiers de fois sur sourceforge sans couter un bezef au développeur.
Ma conclusion : l'electronique coûte plus cher.
[^] # Re: Pas vraiment libre
Posté par Philippe F (site web personnel) . En réponse à la dépêche Projet Open Graphics : 1ère étape terminée. Évalué à 9.
Le coût de production du matériel est beaucoup plus important que celui du logiciel, c'est indéniable. Maintenant ce coût de production il est équivalent chez l'auteur initial et chez le copieur. Ce n'est pas ça qui peut justifier la différence avec la philosophie du libre dans le logiciel.
>>
Ben si. L'auteur de la carte a quitte son boulot, cree une societe, mis son temps et beaucoup de son argent pour faire le design de sa carte. Il va encore investir temps et argent pour debugger le fpga, produire la version ASIC en petite serie, la debugger et enfin avoir a peu pres une carte qui marche.
Il va aussi passer du temps a documenter les specs, ecrire des bouts de drivers, etc etc.
Transversal tech a besoin de recouvrer les couts de toutes ces etapes.
Le copieur lui peut partir du design final et le mettre en production.
En faisant court a l'extreme, on peut dire qu'une grosse difference entre le logiciel libre et le hardware libre, c'est que gcc, c'est gratuit et que copier un logiciel a des millers d'exemplaires, c'est gratuit aussi. Ce n'est pas le cas pour le hardware.
<<
Je tiens juste à remettre les choses dans leur contexte. L'argument des coûts de développements que tu donnes pour justifier la partie non libre, il vaut autant pour le logiciel que pour le matériel.
>>
Ben non. Demarrer un projet logiciel libre et le developper, ca ne coute rien : l'hebergement est gratuit, les compilateurs sont gratuits, le temps personnel est gratuit. Donc tu peux te permettre de tout "donner".
Pour du materiel, tu as un investissement considerable. Juste pour info, la production d'un masque permettant de fabriquer des micro-controlleurs en grosse production coute entre 10ke et 30ke (je parle de mon industrie ici, la carte a puce).
Si tu rajoutes tous les autres couts, tu comprends que l'auteur aie envie de prendre ses precautions pour revenir dans ses couts.
On peut tourner l'argument autrement. A vue de nez, je dirai que l'auteur a mis 2 a 3 annees de salaires dans son projet (je parle en tant que createur d'entreprise). Si toi, tu faisais la meme demarche, mettre 2 a 3 annees de salaires dans un projet, est-ce que tu dirais "oui, les taiwanais soyez gentil, j'ai besoin de rentabiliser ma societe donc me copiez pas tout de suite" ou bien est-ce que tu garderai un mecansimse pour te proteger un minimum ?
Il est evident que l'auteur de ce beau projet de carte graphique a vraiment envie de faire un projet le plus libre possible. Je pense qu'il a regarde cette problematique sous tous les angles possibles et qu'il est parvenu a la conclusion qu'il fallait garder une partie proprio parce que sinon, le risque financier etait trop important pour lui.
# C'est pas un mal
Posté par Philippe F (site web personnel) . En réponse à la dépêche Web Component Development with Zope 3. Évalué à 2.
Les dernieres version de Zope 2 ne sont pas disponibles en package pour windows, la moitie des liens sur le site web de zope pointent vers des pages inexistantes. Il y a environ 500 produits disponibles avec une description de 1 ligne, donc on ne sait pas vraiment a quoi ils servent ni pour quelle version de zope ils sont disponibles.
Pour ce qui est de zope 3, la documentation est completement a la ramasse. Finalement, j'en etais reste a zope 2 puisque au moins, il y avait un peu de documentation.
J'espere que la communaute zope va reagir un peu et mettre en place de la documentation potable.
C'est vraiment dommage car zope a l'air d'un produit pas mal. Si on regarde du cote de python, sur lequel il est largement base, la documentation est tres bien gere, les modules sont propres, les extensions claires, etc etc.
[^] # Re: Utilisation des applications sans 'installation'
Posté par Philippe F (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 1.
Je suis surpris de ne le voir mentionne nulle part, alors que ca repond exactement a la problematique evoquee, et ce avec succes, depuis plusieurs mois.
[^] # Re: Partisant ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche La guerre contre l'ODF et le RGI fait rage.... Évalué à 4.
Des differents articles que j'ai lu (Joel on software en parle pas mal notamment), le developpement de la facon dont il est fait a microsoft est plutot un modele du genre. Tous les logiciels libres ne peuvent pas en dire autant.
Je te signal par exemple que les logiciels ecrit en windows 3.1 tournent toujours et compilent toujours sous windows XP. Combien de logiciels libres sont en mesure d'assurer la compabilite binaire sur 20 ans ?
Faisons un petit bilan:
- linux : cassage de la compabilite binaire tous les mois
- KDE, Gnome : cassage de la compabilite binaires tous les 2-3 ans
- Firefox : cassage de la compabilite des extensions a chaque release mineure
- gcc : pourtant une brique fondamentale, mais cassage de la compabilite au gres des release (et bien a leur insu).
Quand tu vois que l'ensemble des logiciels maintenus par Microsoft represente environ une 50aine de logiciels libres et qu'ils arrivent quand meme a garder la compabilite, tu mesures mieux le travail qu'ils font et sa qualite.
Combien de logiciels libres font des nightly builds ? Combien font systematiquement des tests unitaires ?
Je pense qu'il y a certains logiciels dont les techinques de dev sont au dessus de la moyenne mais dans l'ensemble, c'est souvent en dessous.
Pour prendre un exemple que je connais bien, les tests unitaires et KDE : il y a eu suffisamment de literature pour voir l'interet fondamental de cette pratique. Ca ne fait qu'un ou deux ans que c'est mis en place plus ou moins systematiquement sur KDE.
Je me demande depuis combien d'annees c'est fait chez Microsoft.
En resume, je rejoins tout a fait timaniac. C'est debile de denigrer Microsoft sur des elements qui n'ont aucun fondement. Il y a suffisamment d'elements reels pour ne pas se decredibiliser avec des arguments farfelus.
[^] # Re: pourquoi le lip
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 3.
<< Dans tout programme de plus de 10000 lignes, il y a forcement un compilateur LISP cache quelque part >>
Je me souviens plus du nombre de lignes, mais je tend a etre d'accord. Des que tu fais un gros projet, tu tombes souvent sur des problematiques de calcul intelligent interne ou de notion de logique, qui au final pourraient tres bien se resoudre avec du LISP.
[^] # Re: Nekeme
Posté par Philippe F (site web personnel) . En réponse à la dépêche Projet Ryzom Libre. Évalué à 3.
>>
Le miracle de la communaute qui va ameliorer ton jeu alors que tu ne fais rien, c'est encore a voir. Pour contribuer a un jeu comme cela, il faut un tres tres bon niveau, donc il y a tres peu de candidats. Il y a des milliers de projets open source qui n'ont jamais recu une ligne de code de "la communaute". Quelques uns sortent du lot, mais c'est une alchimie difficile a mettre en place.
[^] # Re: Nekeme
Posté par Philippe F (site web personnel) . En réponse à la dépêche Projet Ryzom Libre. Évalué à 2.
Un jeu, ca coute beaucoup d'argent et quand il est entierement libre, il faut bien reconnaitre que la boite gagne beaucoup moins d'argent qu'avec les modeles purement commerciaux et ouverts.
[^] # Re: Kpart ou Dcop ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche D-Bus 1.0, future fondation de nos bureaux. Évalué à 10.
http://telepathy.freedesktop.org/wiki/
Les développeurs de kopete sont en train d'étudier une migration complète vers telepathy, et on commencer quelques tests avec un plugin. Je pense que ça voudrait dire plein de bonnes choses pour les deux projets.
[^] # Re: Kpart ou Dcop ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche D-Bus 1.0, future fondation de nos bureaux. Évalué à 10.
Sinon, dbus, c'est de la balle. Cela va permettre de faire des services qui pourront être utilisés par tous les environnements de bureau de façon indifférente.
Les notifications hardware sont les premiers services à être intégrés dans dbus, mais il va y en avoir d'autres. C'est grâce à des projets comme ça que les bureaux libres peuvent avancer sans se marcher sur les pieds les uns les autres.
Le blog de Aaron Seigo parle d'un dbus-viewer, successeur du kdcop :
http://aseigo.blogspot.com/2006/11/dbus-viewer.html
Dans les autres projets freedesktop qui assurent, citons le package xdg-utils maintenant développé au sein du groupe de portland.
http://portland.freedesktop.org/xdg-utils-1.0/
xdg-utils permet de faire des opérations standards pour plusieurs desktop :
- installer une entrée menu pour une application
- lancer l'application associée à un fichier donné
- contrôle le screen saver
C'est rien mais le niveau d'intégration qu'il faut pour faire ces choses proprement sur chaque desktop est loin d'être ridicule.
Globalement, ca fait plaisir de voir des leaders des différents projets avancer ensemble sur ces sujets.
[^] # Re: 40% seulement?
Posté par Philippe F (site web personnel) . En réponse au journal Spamassassin/Bogofilter : net avantage à second !. Évalué à 2.
De mon cote, c'est greylisting + spamassassin + bogofilter + junk mail filter de thunderbird.
Resultat a la louche :
- spamassassin pas super efficace sur mon compte a moi
- grey listing super efficace
- bogofilter super lent a l'apprentissage
- junk mail filter de thunderbird hyper efficace. Ca m'a plutot surpris.
[^] # Re: url ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche OpenMoko : sortie en janvier 2007 d'un téléphone-GPS enfin libre !. Évalué à 1.
http://linuxfr.org/~liatogo/22509.html
[^] # Re: Merci Monsieur Glazman
Posté par Philippe F (site web personnel) . En réponse au journal Merci glazou !. Évalué à 8.
Ah ben non, il ne maintient plus la branche NVu 1.0 et il refuse les patchs correctifs qu'on lui envoie. On le remercie quand meme alors en attendant de decouvrir pourquoi.
[^] # Re: Packages concernés?
Posté par Philippe F (site web personnel) . En réponse à la dépêche gNewSense 1.0 : nouvelle distribution entièrement libre. Évalué à 1.
[^] # Re: Portefeuille de Brevets ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à 4.
D'un autre cote, Suse n'a pas les moyens de passer un contrat au noms des developpeurs de Redhat, Mandriva et autres, quand bien meme ils en auraient la volonte.
Cet accord laisse penser que les autres distributions open source ont une chance d'obtenir le meme type de contrat avec Microsoft. Certe, Mandriva n'est pas Novell mais ce qui a ete fait une fois doit pouvoir etre renouvele.
[^] # Re: sceptique
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'UE co-finance un observatoire de la qualité des logiciels open source.. Évalué à 4.
En fournissant des outils de mesure de qualite, on peut prouver la qualite effective des projets open source, et faciliter certaines decisions.
Independamment des decideurs presses, ce type d'outil peut aussi etre utile a des projets open source pour ameliorer leur qualite sur certains critres objectifs. Je pense par exemple a coverity. Il est indeniable que le nombre de problemes de securite d'un projet est un indice de sa qualite et les scans de coverity ont contribue a augmenter globalement la qualite de projets open source. Il y a eu le meme effet avec EBN (cf mon post plus haut pour voir ce qu'est EBN).
La relation avec KDE est pour ce que j'en ai compris, que KDE sert d'etalon initial aux outils de mesure. Non pas pour dire "KDE rocks" mais pour jouer sur le fait que KDE est une tres grosse base de code que Sebastian connait bien, sur laquelle il est capable de verifier que les outils qu'il developpent donnent un resultat coherent (ils sait ou le code de KDE est pourri et la ou il est bien).
On peut se poser la question de la qualite des projets close source commerciaux. Pour ce type de projet, finalement, l'unique etalon de mesure a l'heure actuelle, c'est le succes de la societe qui vend le produit. Si la societe marche bien, on suppose que c'est parce que le produit est de bonne qualite.
J'avoue en revanche que je trouve tout comme vous le site web pourri et que c'est que parce que je connais Sebastian Kugler et qu'il m'a parle de ce projet et a quel point ca lui tient a coeur que j'ai confiance de ce qui en ressortira
[^] # Re: Preuves scientifiques?
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'UE co-finance un observatoire de la qualité des logiciels open source.. Évalué à 6.
Adriaan maintient "the english breakfast network" ( http://www.englishbreakfastnetwork.org/ ) qui sous un nom assez obtus, est un site web faisant des analyses de code sur le code de KDE et reporte des problemes standards:
- methodes, classes ou parametres non documentees
- analyses sur la documentation utilsateur (problemes d'utilisation de docbook)
- analyses sur le code, pour chercher des constructions non optimisees, des petites erreurs, des problemes dans l'assignation des licences, etc.
J'avoue avoir initialement les memes reserves que vous sur ce projet mais en discutant avec lui, j'ai vu qu'il y avait une approche a la fois pratique et academique.
Note: l'analyseur de code est base sur le parser de C++ de kdevelop
Le projet part donc deja avec quelques outils.
Sebastian et Adriaan ont une tres bonne comprehension de l'open source et sont des gens tres pragmatiques. Je leur fais confiance pour ne pas nous sortir un machin completement inutilisable.
La metrique utilisee par EBN est super simpliste: documenter toutes ses fonctions et tous ses parametres, eviter des constructions dangereuses, non optimisees, obsoletes ou jettant un flou juridique (melange de licence, fichiers avec une mauvaise licence, etc). Elle ne permet pas de mesurer objectivement la qualite de KDE. Mais deja, elle a permis d'ameliorer la qualite du code de KDE.
Donc meme si on a aboutit pas a des outils mettant une note objective sur 20 a un projet, on aboutira pour sur a des outils permettant globalement d'ameliorer la qualite de nos chers projects Open Source, de la meme facon que les scan de coverity ont ameliorer la securite des projets open source.
Je suis quand meme convaincu que avec des gens intelligent comme Sebastian, le projet ira beaucoup plus loin que cela.
[^] # Re: Doxygen en python
Posté par Philippe F (site web personnel) . En réponse à la dépêche Doxygen en 1.5.0. Évalué à 1.
DOxygen est quand meme celui qui a le plus de potentiel, etant donne la qualite de la documentation qu'il genere (en C++ et en java). Vivement que quelqu'un reporte le flambeau du parser python.
# Doxygen en python
Posté par Philippe F (site web personnel) . En réponse à la dépêche Doxygen en 1.5.0. Évalué à 2.
J'ai pas l'impression que la generation python soit testee correctement.
[^] # Re: ... et le test ACID ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Firefox 2 arrive (IE7 aussi). Évalué à 6.
Alors que Konqueror a corrige ces meme bugs en 9 mois sur une branche stable ?
Ca fait pas tres serieux quant a l'energie qui est investie dans le developpement de gecko ou dans la qualite du moteur html.
[^] # Re: en français
Posté par Philippe F (site web personnel) . En réponse au journal Nouveau (?) look pour kde.org. Évalué à 2.
Si vous voulez participer d'ailleurs, l'equipe web de KDE cherche de l'aide.