Philippe F a écrit 2214 commentaires

Ton salaire ? On en discute lors de l'entretien :-))

Ma boite ne peut pas me payer mais ca ne pose pas de probleme parce que je suis encore paye par les assedics (pour info, le gouvernement sponsorise la creation d'entreprise mieux que tous les business angel des etats-unis). En revanche, j'ai du travail et un peu de treso pour deux personnes de plus. Et ces deux personnes supplementaires devraient pouvoir generer suffisamment de revenu pour me payer mon salaire a moi (qui sera largement au dessus du smic, faut pas deconner quand meme).

Donc vous affoler pas, on paye les ingenieurs a un tarif raisonnable.

Ouai, ca marche dans le cas de soft pur. Dans mon cas, une fois qu'on a le soft, il faut compter 30 000 euro pour passer a la realisation de la carte. Ces 30 000 euro ne sont pas open source et doivent etre fourni longtemp avant le premier revenu tire du produit ou du service. Donc avec un modele open source, je peux aller me rhabiller.

C'est le meme probleme que pour les CPU libres. Il y a des couts enormes de fabrication, qui ne peuvent pas etre couvert par le modele open source. Une societe deja etablie peut se permettre de faire un invstissement la-dessus, en se disant qu'elle se rattrapera plus tard. Pas une societe en demarrage comme la notre.

Quel est l'interet d'avoir un logiciel open source non telechargeable ? L"interet de l'open source, c'est de developper une communaute de contributeurs. Si ils ne peuvent pas telecharger, ta communaute est reduite strictement a tes clients. En imaginant qu'un de tes clients soit un developpeur motive, quel est l'interet pour toi de l'autoriser a republier le source ? Autant lui faire une licence qui lui donne le droit de modifier le produit dans le cadre de ses besoins internes et puis basta.

TheKompany a fait des logiciels open source non telechargeable. Non seulement, ils se sont mis a dos une partie de la communaute (quoi, c'est pas telechargeable) mais en plus, ils n'ont eu aucun contributeur. Et le produit n'est pas top. Bref, le bide complet.

Je me place dans un logique economique pure: Avec quoi je gagne de l'argent sur mon logiciel ?
1. formation
2. maintenance
3. installation
4. developpements specifiques

Comment maximiser mes revenus ?
1. en faisant des logiciels tres difficiles a utiliser
2. en faisant des logiciels bugges necessitant beaucoup de maintenance
3. en faisant des logiciels difficile a installer, pour qu'on soit obliger de faire appel a moi pour une installation
4. en faisant des logiciels incomplets pour que me demande des evolutions.

CQFD.

Vous avez remarque, je viens de decrire le modele commercial de SAP. Certains disent que c'est aussi le modele de Motif.

Note que si tu fais un produit grand-public que tu vends, tu as interet au contraire a minimiser 1,2,3 et 4, de facon a genere le maximum de satisfaction et a faire decoller tes ventes.

Bon, donc heureusement que les logiciels libres sont developpes dans une optique qui n'est pas purement commerciale, que les developpeurs ont en general l'amour du travail bien fait, et surtout, que les choses sont deja suffisamment compliquee pour qu'on aie pas besoin d'en rajouter pour generer des revenus avec 1,2,3 et 4.

> Si tu ne fais QUE ton « truc complet phare », tu n'as pas beaucoup d'autres choix que de faire du proprio, puique tu n'as aucun revenu à côté.

Tout a fait. Donc si tu veux developper un produit qui te coute environ 4 annees hommes, tu peux faire le choix de passer 2 ans a 2 pour le developper et de le vendre ensuite (c'est ce que j'ai fait). Mais tu ne peux pas le donner.

Avec un modele mixte, il faut que j'assure mes revenus au minimum. Donc en admettant que je m'en sorte tres bien et que je bosse a mi-temps, il nous faudra 4 ans pour faire le meme produit. Pas de bol, dans 4 ans, ce produit n'aura bien rien d'innovant et aura perdu tout son interet commercial. A ce moment-la, je n'aurai plus qu'a fermer boutique.

En plus, des que ce n'est pas un projet ou il y a beaucoup d'utilisateurs, (comme apache), c'est tres dur d'attirer des developpeurs. On a developpe notre OS pendant un an en open source. On a eu _zero_ contributeurs. D'ailleurs, tu peux aller voir : http://jayacard.sf.net(...)

Donc finalement, j'ai beaucoup a perdre et tres peu a gagner en mettant ce projet en open source.

> Il y a de nombreux exemples, Qt de Trolltech, tous les outils d'installation et de config de mandrake, Dolibarr, NVU, et combien d'autres...

Il y a quelques exemples. Qt etant le plus impressionnant. Dolibarr, je ne connais pas. Les outils d'installe de mandrake sont open source parce que mandrake a d'autres sources de revenu qui financent leur developpement.

En dehors de Qt, il y a ACT qui fait un produit open source qui est aussi vendu, et qui leur sert reellement a assurer leurs revenus. A ma connaissance, ce sont les seuls societes qui vivent de la _vente_ d'un produit open source qu'elles ont developpe elles-meme.

Oui, mais lasso est justement un produit utilise en tant que service.

Easter-Egg ne vend pas lasso.

Chip pour cartes a puce. Je te donne une archi classique:
- chip 8 bit
- 72 k de rom
- 4 k eeprom
- 1k ram
- un UART pour la comm sans-contact bas-niveau
- un co-processeur crypto

Apres, tu as des variations. On commence a voir des micros 16 bits et 32 bits. Mais pour notre marche, on reste sur du 8 bit. Cote rom, on peut descendre a 32k voire 24k, et la, il faut tailler l'OS a la hache pour le faire rentrer.

Par contre, pas de temps reel, pas de scheduler, pas de thread, pas de memoire a gerer, pas reseau et pas de pile IP, pas de peripheriques en dehors du crypto-processeur. En gros, l'OS est tres simple (mono-tache avec peu de services a gerer) donc il suffit d'un peu d'experience en embarque pour etre tout a fait operationnel.

La valeur ajoutee de ce type d'OS, c'est sa taille, sa capacite a repondre a des specs (carte de transport, passeport, cartes bancaires) et sa securite.

Je reponds au ici a tout le thread pour que ma reponse soit bien positionnee visuellement.

Alors, en effet, les doubles-modeles existent, mais ca ne marche pas a tous les coups.

Il faut voir que presque toutes les boites qui font de l'open source font en fait du service. Quand on fait un produit avec une bonne documentation, il n'y a pas besoin de vendre de support derriere, ni de facturer une installation. Il ne te reste qu'un produit a vendre. Finalement, le modele de service open source encourage les produits incomplets, difficiles a installer, a utiliser et a configurer.

Maintenant, imagine que ton produit, tu le vends entre 1000 et 100 000 euro. D'une part, c'est un produit sur un metier dedie, donc il na va pas attirer les foules de developpeurs open source. D'autre part, quand ton client veut en acheter 10, avec une version open source, il peut en acheter 0, ou 1 pour te faire plaisir. Apres, il peut le copier autant de fois qu'il veut. Il peut meme le revendre a ta place. Tu vois tout de suite l'impact sur le chiffre d'affaire.

Dans le cas qui nous occupe, je fais un OS pour carte a puce. Il y a des parties confidentielles sur les specs des chips, qui font que de toute facon, une partie de l'OS n'est pas publiable. Ensuite, publier le code peut nous empecher d'avoir des certifications securitaires EAL4+, donc la decision a ete vite prise. En plus, les gens ne comprennent pas bien. Par exemple, si le gouvernement francais choisit notre solution, il est pas tres rassure de savoir que le gouvernement coreen et le gouvernement pakistanais (noms pris au hasard, rien de personnel) ont les sources du soft et peuvent plus facilement monter une attaque.

Tout ca pour dire qu'on a bien reflechi a la question et que si on veut vivre, il n'y a pas moyen de faire autrement que du proprietaire.

Cela dit, on a jayacard qui dort dans un coin, qu'on ressucitera pour faire un OS de bidouilleur. Ca vous tenterai d'achter des cartes sans-contact et un petit lecteur, pour vous faire votre controle d'acces a la maison ?

Malheureusement, je ne prends pas de contrat en alternance. Je trouve le principe general plutot bon, mais ca ne fonctionne pas avec notre maniere de travailler actuelle.

Aujourd'hui, j'ai des taches de developpements qui me prennent entre 1 et 6 mois a accomplir. Pour ca un stagiaire est parfait. Quand je dis que ca prend 6 mois a developper, ca veut dire qu'on en a besoin pour dans 4 mois et qu'on a negocie avec le client pour passer ca a 6.

Avec de l'alternance, 6 mois de dev, ca fait presque un an en duree. C'est pas compatible avec mes besoins commerciaux.

Donc voila, desole. Pour des boites plus mures, peut-etre que ca marche mieux. Mais en info, on fonctionne vachement sur le mode du projet, et je trouve que ca ne se marrie pas bien avec l'alternance.

Petit oubli sur le lieu de travail.

Donc, c'est a Paris, a cote de Denfert Rocherau pour l'instant, et on doit demenager un juin vers une destination inconnue. Je vais me battre pour qu'elle soit dans Paris intra-muros parce que les heures de transport, c'est chiant.

On a travaille a Cergy pendant 9 mois, c'est pour ca que vous y avez trouve des references.

Je ne sais pas pour Gnome (bien que j'aurai plutot tendance a etre d'accord), mais je peux t'assurer que KDE est principalement developpe en Europe.

Tous les ans, KDE organise une conference (aKademy). Le sujet a ete debatu plusieurs fois dans les listes de KDE et il est tres difficile d'organiser cette conference hors de l'europe, parce que tres peu de developpeurs pouraient y assister.

Le fait d'organiser une conference en Europe pose des problemes aux 4 ou 5 developpeurs americains, mais guere plus.

Pour etre plus precis, KDE est principalement developpe en Allemagne et dans les pays nordiques. C'est pas un choix, c'est une constatation. Je pense qu'il y a des effets de reseaux locaux qui fait que plusieurs developpeurs d'un meme pays vont souvent se regrouper.

Ca n'empeche pas chacun des projets d'accueillir les developpeurs du monde entier.

KDE assiste a tres peu de conferences aux US, en revanche, il est bien present a toutes les conferences allemandes, neerlandaises, autrichiennes, francaises, belges, ...

Un brevet est rendu public au bout de 2 ans (ou bien 1 an, je ne sais plus). En attendant, tu peux violer un brevet sans le savoir. Mais on ne t'en veux pas dans ce cas-la, il faut juste que tu payes les royalties une fois que le brevet est publie.

Alors comment breveter un truc publie ? Normalement, c'est impossible. Mais tu peux trouver des moyens. Genre, le format decrit un mecanisme pour faire X et toi, tu brevettes une implementation de X. Ou bien le format decrit une un mecanisme pour faire Y, sachant que dans 90% des cas, ce sera utilse pour faire Z, mais que pour laisser plus de possibilites d'extensions futures, on ne decrit que Y. Toi, tu brevettes Z.

Bref, il y a pas mal de moyen de contourner la forme, meme si dans le fond, on reste toujours autour du "je brevette une idee ou une implementation logicielle bidon".

Pour ton employeur, pense a ce qui va se passer une semaine plus tard:
- quoi, ca ne marche toujours pas
- ben c'est que il y a quelques bugs compliques que j'ai du mal a regler
- mais je comprends pas, au bout d'un jour, ca marchait deja
- oui, mais c'etait pas fini, il y avait encore du travail plus difficile a faire

Alors que avec les tests unitaires, le depart est plus difficile, mais le finish est plus facile. Surotut quand au bout d'une semaine, il t'explique que tu n'as pas compris sa demande et qu'il faut tout changer. Avec tes tests unitaires, tu es zen.

Tu vois, meme ton patron serait content.

Sinon, pour mieux faire passer la pilule:
- il faut viser en priorite les fonctionnalites les plus utiles
- tu codes et tu testes en meme temps. Donc au bout d'une journee, tu as quand meme une partie du code qui est ecrite.

J'esperais plutot inspirer de l'inspiration cote test unitaires mais il semble que la faineantise soit beaucoup plus populaire :-)

Des assertions ne remplacent pas des tests unitaires. Ca ne fait que verifier que ton programme ne va pas dans des etats fantaisistes.

Les tests unitaires te permettent de valider en permence que ton programme fait ce qu'il doit faire, correctement.

pyqt aussi !

C'est pas KDE 2.1 sur la prochaine sarge ?

Il suffit de s'interfacer sur kio de KDE pour faire marcher ca. Donc pour kyzis, ce sera pas trop complique a rajouter. Il faut juste faire attention, puisque dans libyzis, qui est responsable de l'ouverture et l'enregistrement du fichier, on utilise pas kio. Uh uh, va falloir trouver un moyen pour resoudre ce probleme.

Donc finalement, a la question "qui de l'OS ou du compilateur est la en premier ?", tu reponds le compilateur parce que le processeur est un compilateur.

En fait, je suis d'accord avec toi que tout repose sur le langage du processeur mais je verrai plutot celui-ci comme un systeme d'exploitation. Le processeur lit des donnees (un programme), deplace des donnes de la RAM vers les registres, des registres vers les bus materiels, etc, etc. Tout ca ressemble a un OS.

En revanche, pour ce faire, il a fallu ecrire un interpreteur pour le langage machine, qui tourne dans le processeur. Ca ressemble encore a un OS.

En fait, meme si a priori, le compilateur parait indispensable, c'est beaucoup moins util qu'un OS. Le compilateur ne fait que fabriquer des programmes qui pourront s'executer. Son travail peut etre remplace par un cerveau humain. En 85, je faisais de l'assembleur en ecrivant mon code sur une feille de papier, puis en cherchant dans le bouquin de reference du MSX (assebembleur Z80) les valeurs hexadecimales des instructions, puis en les codant sous forme de chaine de caractere dans un programme en basic et en faisant un appel sur l'adresse des chaines de caractere. Dans ce cas, je me passais d'un compilateur, c'est mon cerveau qui faisait le travail. Mais tout ca n'aurait pas pu avoir lieu si je n'avais pas eu un OS, en l'occurence Microsoft MSX Basic.

Donc pour moi, la reponse est clairement que l'OS etait la avant le compilateur.

Ces dependances devraient diminuer avec Qt4. En effet, Qt 4 separe les classes de la QTL et les classes graphiques. On utilise presque que la QTL.

Cela dit, je ne sais pas comment ca se passe pour l'impression.

Le monsieur t'explique qu'il y a un probleme de vocabulaire. Ce que tu appelles test unitaire est en fait un test fonctionnel. Les tests unitaires et les tests fonctionnels sont deux choses tres bien, mais distinctes.

Le signification de test unitaire est acceptee par beaucoup de monde et signifie "tester independamment des morceaux de code". Le but est de mettre en evidence des problemes dans un morceau precis de code de facon a faire de la non-regression. Cette definition est supportee d'une part par les livres traitant d'extrem programming, d'autre part par la communaute et les outils de test unitaires.

Les tests fonctionnels ont un autre role: validation de l'integration de toutes les briques ensemble, stress de l'application par l'envoi de requetes en serie, reproduction du comportement d'un utilisateur.

Typiquement, comme te le dis le monsieur plus haut, creerClient va juste generer une requete SQL fictive et validera que la requete est ce qu'elle doit etre. Idem pour creerDevis. La conclusion logique, c'est que lancer l'un apres l'autre ne stresse pas du tout l'application car ce sont des tests _unitaires_

Maintenant, tu peux mettre en place des tests fonctionnels, en t'appuyant aussi sur Junit et les executer via un scenario. C'est une bonne idee et je fais ca aussi dans mes projets. Dans ce cas, ton test creera effectivement une vraie base de donnee et reproduira le comportement d'un utilisateur.

C'est le fait que JUnit puisse etre utilise dans deux contextes differents (tests unitaires, tests fonctionnels) qui seme la confusion ici.

En continuant a appeler ton projet JUnitScenario, tu risques de ne pas du tout faire comprendre l'utilite de ton soft (donc tu peux oublier les contributeurs):
- les gens qui ne connaissent rien au test unitaire ne seront pas interesses
- les gens qui connaissent les tests unitaires comme moi trouveront ton bidule inutile.

Je te conseille donc pour le bien de ton projet de faire bien comprendre le message. Qqch comme:
"JunitScenario builds an automation framework on top of JUnit to perform functional tests and stressing tests".

Une fois que ce point la est eclairci, ton projet devient interessant.

Mais si tu veux, tu peux continuer a appeler test unitaire un test fonctionnel. Tu peux aussi appeler le soleil "Lune". Mais ca reste le soleil et personne ne te comprendra.

En tout cas, ca apporte de l'eau a mon moulin personnel : c'est finalement beaucoup plus dur de faire une bonne applet javacard qu'un bon bout de code en C des familles.

DCOP s'appuie sur lib-je-sais-plus-quoi qui est en fait une lib de X pour etablir des communications. Celle-ci s'appuie (si je me souviens bien) sur les atomes X pour faire certains exhanges.

Il y a d'autres parties dans KDE qui dependent des atomes X mais je ne suis pas assez pointu pour te dire lesquelles. Il me semble que la gestion de la session et la creation des repertoires temporaires utilisent partiellement des petits mecanismes de X

Ce que vous faites, j'appelle ca un test fonctionnel. Je reste sceptique dans la mesure ou un test unitaire reste unitaire, c'est a dire dedie a une fonctionnalite precise.

La somme des tests unitaires ne constitue pas un test fonctionnel. Il faut mettre son grain de sel (sa connaissance du fonctionnement du bazar) dedans. Dans mon experience, on s'appuie sur les mecanismes mis en place lors des tests unitaires, mais on ne re-utilise pas les tests unitaires tel quel.

C'est un peu comme la generation automatique de test unitaire a partir des headers. C'est genial sauf que 50 tests unitaires auto-generes ne peuvent remplacer des tests ecrits par le developpeur, qui va tester la ou ca fait mal.

Ce que tu me decris me semble plus facile a mettre en place avec un vrai test, fait non pas d'assemblage de tests unitaires, mais de reproduction du comportement d'un utilisateur.

GNU sans linux, c'est aussi une coquille vide. Heureusement qu'on a un kernel potable avant d'avoir eu un kernel Gnu.