Vivre du logiciel libre : un exemple

Posté par  . Modéré par Fabien Penso.
Étiquettes : aucune
0
10
mai
2002
Commercial
Steven M. Rubin nous explique dans cet article comment il vit du logiciel libre avec l'exemple de Electric, un logiciel sur lequel il a travaillé il y a 20 ans et que la société éditrice a accepté de placer sous licence GPL quand elle a mis la clé sous la porte.

Une lecture très intéressante en somme :-)

Aller plus loin

  • # note, juste en passant

    Posté par  (site web personnel) . Évalué à 10.

    Pour avoir essayé Electric, dans l'optique d'une utilisation dans un projet "trollesque", mais avec la nécessité du sérieux, ben je ne pense pas que ce soit vraiment utlisisable à grande échelle (temps, taille du circuit et nombre de personne).

    Surtout, quand je l'ai essayé, ce cong refuse de compiler du VHDL qu'il n'a pas lui-même généré, ce qui est un peu aussi cong que (K?)Lyx qui aux dernières nouvelles refuse d'importer du LaTex ...

    Recommandation : utiliser les outils VHDL standard !!!

    Par exemple, Simili à http://www.symphonyeda.com(...) :-)

    C'est pas "libre" mais au moins c'est standard, en attendant que le projet FreeHDL sorte qqc de potable... et qui ne coredumpe pas...

    YG
    • [^] # Re: note, juste en passant

      Posté par  (site web personnel) . Évalué à 10.

      Pourquoi ne pas corriger les problèmes qui font
      que cet outil n'accepte pas de VHDL standard ?

      Ca devrait etre moins compliqué que de tout
      redevelopper en libre.
      • [^] # Re: note, juste en passant

        Posté par  (site web personnel) . Évalué à 3.

        C'est un problème de conception, et surtout
        peu de personnes auraient envie de toucher à ce code.

        En plus ça n'a pas été fait pour être un outil VHDL,
        mais un outil de conception pour le layout des ASIC,
        il y a une nuance...

        Donc le mec a implémenté une toute petite
        partie du (lourd) standard tout simplement parce
        que le reste des fonctionalités n'ont pas d'utilité
        dans le cadre de son environnement de travail.

        Enfin, je crois. à vous de vérifier.
  • # Intéressant, mais...

    Posté par  (site web personnel) . Évalué à 10.

    Ca ressemble à l'histoire de OpenCascade de Matra datavision. Mais tous les types de logiciels ne peuvent être traités ainsi. Les logiciels métiers se prêtentent très bien à cette façon de rémunérer leurs auteurs. Ce n'est pas évident avec des logiciels généralistes et plus simples pour lesquels il n'y besoin ni de support, ni de formation.

    Un argument m'a frappé : on n'achète pas un logiciel à une petite société car c'est risqué pour l'acheteur. Par contre si le logiciel est GPL, l'argument ne tient plus.
    • [^] # Re: Intéressant, mais...

      Posté par  (site web personnel) . Évalué à 10.

      bonne analyse.

      Cependant, pour la remarque sur le prix, je dois quand même rappeler que le monde de la microélectronique semble fonctionner à l'envers. Ils sont prêts à dépenser des millions pour des conneries et vous refuser une augmentation ou même l'accès à une doc.

      Ils sont comme ça.

      nicO pourra certainement confirmer : le prix est une chose. C'est aussi souvent un investissement à moyen terme et le GNU a un peu de mal à être compris, surtout à cause des FUD de M$ et des équivalents dans cette industrie. Par contre ce qu'ils veulent ce sont des garanties ! Parce que un million restera toujours un million et les investisseurs exigent des résultats positifs en temps et en heure.

      Ces gens-là connaissent les lois du marché : si tu ne vends pas assez cher, tu ne fais pas de bénef et tu coules, donc tu ne peux plus faire la maintenance et le support. Et tomber en rade d'un ordi en plein bouclage de projet c'est dur mais ça se remplace. Par contre un outil customisé pour une application extrêmement pointue, le client risque de ne jamais s'en relever. Vu comme ça c'est plus compréhensible, non ?

      si en plus ils peuvent éviter de dépenser 10 millions pour une connerie, ils le feront.

      GNU ne leur apporte pas de garantie "directe" comme le support, la hotline et "l'ingénieur d'application qui t'envoie chier si tu lui demande de l'aide". Par contre la garantie indirecte est justement de ne jamais être dépendant d'une seule source et dans cette industrie, les compagnies apparaissent souvent moins vite qu'elles ne disparaissent...

      Donc GNU-style HW a "seulement" besoin de travaux suffisamment avancés pour allumer la mèche. Pour l'instant, F-CPU, LEON et Opencores ce sont de petits rigolos à leurs yeux mais les enjeux vont beaucoup plus loin, il faut "juste" dégainer les bons arguments (cf ce papier et la réponse du Pérou à M$).

      Ce monde-là souffre d'une intoxication mentale et d'un bourrage de crâne entretenus par la pression des investisseurs qui n'y connaissent rien. Il y a 20 ans, comme le mentionne l'auteur, chaque boite avait ses outils et ça ne se fait plus de nos jours, les années 80 ont vu une concentration massive des développements et une spécialisation pointue. Chacun reste dans son domaine. Un fondeur ne fera pas de développement de circuit, il se contente le plus souvent d'améliorer ses process chimiques...

      Pourvu qu'on arrive à mettre notre grain de sable dedans :-) ce sera tout bénef pour tout le monde, au niveau prix, compétitivité, qualité et obsolescence.

      J'espère que c'est moins confus maintenant.
    • [^] # Re: Intéressant, mais...

      Posté par  . Évalué à 10.

      Je suis bien d'accord sur le fait que tout logiciel ne peut suivre ce modèle.

      Il est toujours intéressant de voir comment on peut vivre du logiciel libre à travers diverses expériences, c'est comme ça que le schimilibii...ilic avance ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.