Dimdim racheté par Salesforce, la version opensource est abandonnée...

Posté par  (Mastodon) . Modéré par tuiu pol.
Étiquettes : aucune
15
9
jan.
2011
Internet
Salesforce, éditeur de solutions de CRM (gestion de la relation client) en ligne, vient de racheter DimDim, un éditeur indien, qui fournissait une solution de conférence / réunion en ligne (webmeeting). DimDim avait pour particularité d'avoir ouvert le code de son logiciel serveur. Suite au rachat, les comptes de test seront fermés d'ici au 15 mars. DimDim cessera de contribuer au code opensource (qui restera disponible sur SourceForge).

À ce jour DimDim était une des solutions permettant de réaliser des présentations, formations, réunions à distance sur une base de logiciels libres. Les alternatives propriétaires limitent pour la plupart l'utilisation d'OS libres, le plus souvent en ne proposant pas leur utilisation pour les postes « maîtres » (par exemple Adobe Connect).

WebHuddle reste une solution totalement libre, mais qui n'évolue plus depuis plusieurs années. BigBlueButton est une autre alternative libre, mais plus orientée sur le monde universitaire.

Aller plus loin

  • # Open Source ...

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

    J'avais voulu essayé dimdim il y a quelque temps : j'ai surtout le souvenir d'un soft opensource fourni sans aucune documentation sur comment on l'installe, le compile ou autre ce qui le rend pas utilisable ailleurs que sur une centos ou la VM fourni.

    En gros j'en été arrivé à : sans le support officiel on peut se gratter pour l'utiliser comme on veut car pas de doc.

    J'aurais préféré qu'un rachat améliore ce côté là car il semble mériter à être connu plutôt que de repousser les admins qui veulent le mettre en place.

  • # L'open source n'a pas besoin de Dimdim

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

    openmeetings existe !

    [http://code.google.com/p/openmeetings/]
    Conférence vidéo, tableau blanc.... Testé et approuvé.

  • # y aura t il un fork ?

    Posté par  . Évalué à 1.

    y aura t il un fork ? C'est dommage qu'il ai peu ou pas de produits de ce type en Open Source !

  • # GPL etc

    Posté par  . Évalué à 3.

    Il est évident que la licence et le mode de développement sont deux choses différentes. La surprise de l'existence des "fauxpen source" est juste la réalisation de cette différence.

    Avoir un soft disponible sous GPL n'implique pas que son développement soit communautaire, il implique qu'on ait accès aux sources et qu'on ait le droit de le forker. En fait, je n'arrive pas à imaginer un cas où une entreprise libère un logiciel et que le développement devienne communautaire. À mon avis, on ne peut avoir un développement communautaire que si ce modèle existe depuis le début du développement. Et je pense qu'on ne puisse pas exiger d'une entreprise qu'elle adopte un développement communautaire. Une entreprise peut très bien publier le code, fournir une intreface pour les rapports de bugs, et garder le développement en interne. Le logiciel n'en est pas moins libre, il est juste développé de manière centralisée. D'ailleurs, pas besoin d'entreprises, il y a de nombreux logiciels libres qui sont développés de cette manière.

    Ce qui est plus inquiétant à mon avis, ce n'est pas le développement centralisé, c'est le changement de licence. Le logiciel libre est censé apporter de nombreux avantages, parmi lesquels la pérénnité du modèle de développement. Imaginons un appel d'offre, la licence libre est évidemment mise en avant; si d'un coup le logiciel se ferme, un organisme peut rester bloqué sur une solution propriétaire (ou sur une version qui n'évolue plus). Ça veut dire qu'il faut penser à blinder les contrats pour pouvoir le rompre avec éventuellement une pénalité et un préavis si la licence du logiciel change; au niveau d'une petite entreprise par exemple ca représente des détails juridiques en plus à devoir prendre en compte, et ça peut être lourd.

    Ce genre de situation met bien en évidence l'importance de ne JAMAIS céder ses droits d'auteur à un organisme centralisateur, même si c'est pour le bien du soft. Une fois le code bourré de patchs d'auteurs différents, le mode de développement peut changer, mais plus la licence. Je pense que la communauté se doit de se protéger de cette manière, si on demande son aide une fois, il ne faut pas qu'une marche arrière soit possible. Après tout, dans cette affaire, l'entreprise n'avait jamais rien exigé de personne, elle peut changer d'avis. Mais les systèmes de cession des droits d'auteur ont l'effet pervers de rendre possible les décisions arbitraires, et c'est inacceptable.

    D'ailleurs, l'exemple du tr\es ingénieux changement de licence de Wikipédia montre qu'il est tout à fait possible de changer une licence dans l'esprit du libre sans avoir à centraliser les contributions.

    • [^] # Re: GPL etc

      Posté par  . Évalué à 1.

      « Ce genre de situation met bien en évidence l'importance de ne JAMAIS céder ses droits d'auteur à un organisme centralisateur, même si c'est pour le bien du soft. Une fois le code bourré de patchs d'auteurs différents, le mode de développement peut changer, mais plus la licence. »

      C'est une solution dans le cas où il y a beaucoup de contributions, sinon il est facile à l'entreprise de réécrire les quelques bouts de code dont ils ne sont pas propriétaires du copyright.

      Aussi, ça peut être embêtant si on a pas spécifié « version un-telle ou supérieure ». Par exemple certaines parties du noyau Linux sont en GPL 2 only, et certains dev ne sont plus joignables, donc impossible de passer à la GPL 3+. Enfin bon de toute façon Linus n'aime pas la GPL v3 (c'est peut-être juste un prétexte pour ne pas devoir réécrire du vieux code que plus personne ne comprend ->[]).

Suivre le flux des commentaires

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