ESR oppose les logiciels à sources ouvertes à ceux à sources cachées. Dans notre cas, avec ces technos, il n'était pas possible de cacher les sources, à moins de dépenser une énergie démesurée à essayer de les cacher.
ESR écrivait a une époque ou le paysage des langages informatiques était bien différent de ce qu'il est aujourd'hui.
Je pense que certaines des technologies que vous utilisez n'existait même pas ou bien elles étaient balbutiantes.
Il aurait toujours été possible de cacher le source a base d'obfuscateur de code source par exemple. Je ne pense pas que ce soit difficile. Tant mieux que vous ne l'ayez pas fait ;)
Un dernier point, que je reviendrai lire dans quelques temps… nous avons fait le pari qu'une application libre, à condition que sa qualité soit suffisante, avait tendance à 1/ se propager plus vite qu'une application proprio de qualité équivalente et 2/ limiter l'apparition de solutions concurrentes libres (hors forks) à l'inverse de ce qui se passerait en proprio. Nous espérons donc, si la condition de qualité est respectée, rattraper les pertes sur les licences et la distribution par des gains accrus sur la formation des prestataires et les demandes de dévs spécifiques.
1) je rajouterai c'est possible que ce point soit vrai lorsque le marketing est équivalent. Cependant les logiciels privateurs dépensent souvent beaucoup en marketing pour se faire une meilleure place au soleil et plus vite.
2) Par définition un fork n'est pas possible avec un code source ferme ;)
Du moment que le développement avance vite et suit les attentes de la communauté, un fork n'a aucune raison de se développer. Les problèmes arrivent lorsque l’équipe de développement ne répond pas a une partie des attentes (développement ralenti, divergence de point de vue sur ce que le logiciel doit faire, etc.).
Finalement, un autre business model est celui de prendre e charge le support ce qui est assez lucratif même s'il faut souvent tenir la main de certains utilisateurs qui ne lisent pas les manuels, ne comprennent rien au fonctionnement du logiciel, font vraiment n'importe quoi, etc. Heureusement ce n'est pas la majorité des utilisateurs, mais ce sont toujours les mêmes qui font n'importe quoi!
Posté par djano .
En réponse à la dépêche Sortie de Variation v1.0.
Évalué à 5.
Dernière modification le 17 juillet 2014 à 11:01.
Bonjour,
Tout d'abord, félicitations pour avoir libéré le fruit de votre travail!
Puis-je vous demander ce que vous espérez de cette libération?
Voulez-vous attirer des contributions? ou bien voulez-vous développer un écosystème d'utilisateurs et de partenaires?
Loin de moi l’idée de critiquer négativement ou de remettre en cause votre décision. Je trouve que c'est une excellente nouvelle pour ce logiciel et le logiciel libre!
Je suis juste resté sur ma faim après cette annonce qui pour moi est plus informative qu'incitative, ce qui est plutôt surprenant lorsque l'annonce est crée part l'auteur du logiciel.
[Slate.fr] Pourquoi on notera bientôt vos comportements d’usager, de client, de consommateur et d’être humain
Ça existe déjà: demandez un prêt immobilier a votre banquier, regardez pour choisir une assurance auto, etc.
Nous sommes déjà notés, rien de nouveau sous le soleil.
Est ce que les grandes entrées tonitruantes dans ce classement sont finies?
Même la vitesse d'augmentation des puissances a ralentie.
Il faut dire que les consommations électricité atteintes deviennent titanesque.
Faut-il regarder du cote du green500 pour retrouver un peu de bataille?
Mais rassembler des gens autour d'un écran … je trouve çà space, ou alors genre méga écran ….
Bref surtout, ne pas faire que les gens consulte le board depuis leurs postes, c'est dommage …
Aaaaaaahh! Je comprend mieux ta critique maintenant.
Oui nous utilisons des boards électroniques, mais nous nous réunissons tous autour d'un unique écran pour chaque sprint planning.
Nous ne faisons pas de sprint planning car l’équipe est suffisamment petite pour qu'on le fasse de manière informelle au jour le jour, parce que les membres de l’équipe sont très autonomes et parce que nos contraintes sont faibles de ce cote la.
Heureusement, la taille de l’écran a bcp grossie dernièrement :)
Oui en effet ce qui compte c'est que l’équipe communique. La notre communique très bien, et l'entraide et très présente donc tout va bien de ce cote la.
Je confirme, ce serait glauque si chacun restait devant son écran.
Oui je pense que l'on n'est sur la même longueur d'onde sur les grands principes.
Et j'ai tendance a vouloir une équipe avec des gens super autonomes et super compétent.
Sûrement une déformation de ce qui est la "norme" selon mes standards.
dans le premier article, les problèmes décrivent des problèmes classiques d’implémentation d'un application (performances de l'application ou donner du feedback a l'utilisateur), et les autres problemes sont tous spécifiques a l’implémentation de leur board qui a l'air un peu boiteuse, et qui surtout n'a rien a voir avec les implémentations actuelles de board.
le second article mentionne qu'"utiliser un board electronique peut avoir de mauvaises conséquences sur les équipes qui ne gèrent pas bien la transition". C'est une phrase tellement generale que tu peux l'appliquer a tout ce que tu veux en remplaçant "board electronique" par "windows", "linux", "rasoir USB", etc.
En gros, ces deux articles ne remettent pas en cause les board electroniques selon moi. Et je maintiens que les membres de l'equipe sont plus important que n'importe quel outil ou processus.
En gros, on est tous d'accord que l'outil pour l'outil ça ne passe pas.
Et l'agile ne passe pas partout non plus.
Tes exemples tiennent plus a la culture d'entreprise ou a la dynamique d'entreprise qu'a l'outil lui même.
;
Dans mon expérience, j'ai vu des gens faire de l'agile en découpant le travail en taches minuscules et a passer plus de temps a gérer ces taches minuscules (en les passant de sprints en sprints et en les requalifiant sans cesse) qu'a faire son autre travail, tout ça dans des meeting super long avec plus de 5 personnes. Tout ça au nom de l'agile!! C'est ce que j'appelle la "bureaucratie agile" qui nous était vendu comme un consultant comme quelque chose d'agile. Si l'on en arrive la, c'est tout sauf agile pour moi. Ce n'est pas pour autant que je rejette les méthodes agiles en bloc.
Pour moi, le truc le plus important et de trouver une dynamique de travail qui permette d'avancer régulièrement et de communiquer ce que l'on fait sans alourdir le travail au jour le jour.
Avoir une personne qui joue uniquement le rôle de scrum master et qui ne fait rien d'autre parce que gérer le processus agile est trop chronophage, c'est exactement l'anti-agile pour moi. Cela fait partie de ce que j'appelle la bureaucratie agile. Il faut alléger un tel processus agile (!?!)
Dans le cas de l'informatisation du board, si tu aimes le défi … mais le feedback est claire, la plupart se casse la pipe avec.
Mince plein de gens ne sont pas au courant qu'ils font n'importe quoi! Et en plus tu sais quoi? Ça marche que quand même!
Bref l'outil ou la méthode n'ont rien a voir, ce qui compte ce sont les gens qui l'animent.
Des projets développés de manière distribuée peuvent fonctionner avec des méthodes agiles sans mur physique.
D'ailleurs j'ai vu des équipes avec des murs physiques qui échouaient quand même, comme quoi ce n'est pas la panacée.
Maintenant, je ne comprend pas bien pourquoi tu mets tant d’énergie a affirmer si énergiquement que ça ne marche pas alors que l'on te dit que l'on y arrive au jour le jour.
As tu une expérience a partager?
Je me dois de te corriger un peu: Google a d'abord bâtit son index sur le nombre de liens arrivant sur une page et le texte que les gens mettaient sur les hyper liens, du coup il s'appuyait sur l'intelligence humaine pour fournir des liens pertinents. Ils ont ensuite indexes le contenu des pages elles mêmes pour construire leur fameux PageRank.
Ask Jeeves avait racheté un moteur de recherche prometteur appelé Teoma (voir wikipedia en anglais) dans lequel ils ont fait peu d'investissement et qui n'a pas connu la même trajectoire que Google.
Je me rappelle qu'avec Altavista il fallait aller voir les 30 ou 50 premiers liens retournes pour trouver un truc un peu pertinent.
L'Open World Forum 2014 qui se tiendra du 30 octobre au 1er novembre prochain
Puisque ce n'est pas précisé, on doit supposer que c'est a Paris?
C'est dommage d'avoir les information de temps mais pas d'espace.
Le parisiano-centrisme est agaçant.
Encore faut-il:
1- arriver a écrire la spec
2- que l’écriture de la spec soit correcte
Pour avoir essaye d’écrire du code avec la méthode B, je peux te garantir que c'est pas demain la veille que tous les logiciels seront écrits avec des méthodes formelles.
Au passage, se targuer de développper un outil de sécurité soit-disant robuste et de niveau commercial (c'est pas moi qui le dit, c'est sur la page d'accueil) et ne pas auditer le code au fil des commits, c'est quand même assez moyen.
Est ce que tu es en train de dire que du code commercial et toujours audite et toujours de bonne qualité et n'a jamais aucun problème?
En Java il y a le hot code replace pour réécrire du code en train d’être débogué.
Depuis le débogueur de l'IDE Eclipse, il est même possible d’exécuter du code simple (limitation de la syntaxe) et d'avoir des effets de bords pour aider au débogage.
Pourquoi la traduction n'est-elle pas directement faite sur Wikipedia FR?
Avez-vous vraiment peur que le nombre de contributeurs concurrent rende difficile l’édition sur Wikipedia?
Fonctionnalités
Seafile dispose de nombreuses fonctionnalités de , qu'on peut répartir en [...snip...]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[^] # Re: Super! mais quel est votre but?
Posté par djano . En réponse à la dépêche Sortie de Variation v1.0. Évalué à 3.
ESR écrivait a une époque ou le paysage des langages informatiques était bien différent de ce qu'il est aujourd'hui.
Je pense que certaines des technologies que vous utilisez n'existait même pas ou bien elles étaient balbutiantes.
Il aurait toujours été possible de cacher le source a base d'obfuscateur de code source par exemple. Je ne pense pas que ce soit difficile. Tant mieux que vous ne l'ayez pas fait ;)
1) je rajouterai c'est possible que ce point soit vrai lorsque le marketing est équivalent. Cependant les logiciels privateurs dépensent souvent beaucoup en marketing pour se faire une meilleure place au soleil et plus vite.
2) Par définition un fork n'est pas possible avec un code source ferme ;)
Du moment que le développement avance vite et suit les attentes de la communauté, un fork n'a aucune raison de se développer. Les problèmes arrivent lorsque l’équipe de développement ne répond pas a une partie des attentes (développement ralenti, divergence de point de vue sur ce que le logiciel doit faire, etc.).
Finalement, un autre business model est celui de prendre e charge le support ce qui est assez lucratif même s'il faut souvent tenir la main de certains utilisateurs qui ne lisent pas les manuels, ne comprennent rien au fonctionnement du logiciel, font vraiment n'importe quoi, etc. Heureusement ce n'est pas la majorité des utilisateurs, mais ce sont toujours les mêmes qui font n'importe quoi!
Merci de votre réponse!!
[^] # Re: Super! mais quel est votre but?
Posté par djano . En réponse à la dépêche Sortie de Variation v1.0. Évalué à 3.
Merci pour votre réponse, c'est plus clair maintenant.
Je me rappelle qu'Eric Raymond avait posté un article sur le fait de mettre un logiciel en open source ou non.
Voici la partie en question dans l'article: http://www.catb.org/esr/writings/cathedral-bazaar/magic-cauldron/ar01s10.html
Il serait intéressant d'avoir votre opinion sur ce choix si cela ne vous dérange pas d'en parler ici?
# Super! mais quel est votre but?
Posté par djano . En réponse à la dépêche Sortie de Variation v1.0. Évalué à 5. Dernière modification le 17 juillet 2014 à 11:01.
Bonjour,
Tout d'abord, félicitations pour avoir libéré le fruit de votre travail!
Puis-je vous demander ce que vous espérez de cette libération?
Voulez-vous attirer des contributions? ou bien voulez-vous développer un écosystème d'utilisateurs et de partenaires?
Loin de moi l’idée de critiquer négativement ou de remettre en cause votre décision. Je trouve que c'est une excellente nouvelle pour ce logiciel et le logiciel libre!
Je suis juste resté sur ma faim après cette annonce qui pour moi est plus informative qu'incitative, ce qui est plutôt surprenant lorsque l'annonce est crée part l'auteur du logiciel.
Alors dites nous en plus:
Que souhaitez vous pour votre logiciel?
Comment le voyez vous évoluer?
Qu'attendez vous de la communauté?
# noter les comportements
Posté par djano . En réponse à la dépêche Revue de presse de l'April pour la semaine 25 de l'année 2014. Évalué à 3.
Ça existe déjà: demandez un prêt immobilier a votre banquier, regardez pour choisir une assurance auto, etc.
Nous sommes déjà notés, rien de nouveau sous le soleil.
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . En réponse à la dépêche Sortie du connecteur Tuleap Agile Planner pour Eclipse en Open Source. Évalué à 2.
Excellent! :D
# Décevant oui!
Posté par djano . En réponse à la dépêche Le Top 500 de juin 2014. Évalué à 6.
Est ce que les grandes entrées tonitruantes dans ce classement sont finies?
Même la vitesse d'augmentation des puissances a ralentie.
Il faut dire que les consommations électricité atteintes deviennent titanesque.
Faut-il regarder du cote du green500 pour retrouver un peu de bataille?
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . En réponse à la dépêche Sortie du connecteur Tuleap Agile Planner pour Eclipse en Open Source. Évalué à 2.
Un "restez debout" :)
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . En réponse à la dépêche Sortie du connecteur Tuleap Agile Planner pour Eclipse en Open Source. Évalué à 3.
Aaaaaaahh! Je comprend mieux ta critique maintenant.
Oui nous utilisons des boards électroniques, mais nous nous réunissons tous autour d'un unique écran pour chaque sprint planning.
Nous ne faisons pas de sprint planning car l’équipe est suffisamment petite pour qu'on le fasse de manière informelle au jour le jour, parce que les membres de l’équipe sont très autonomes et parce que nos contraintes sont faibles de ce cote la.
Heureusement, la taille de l’écran a bcp grossie dernièrement :)
Oui en effet ce qui compte c'est que l’équipe communique. La notre communique très bien, et l'entraide et très présente donc tout va bien de ce cote la.
Je confirme, ce serait glauque si chacun restait devant son écran.
[^] # Re: Agile ?
Posté par djano . En réponse à la dépêche Sortie du connecteur Tuleap Agile Planner pour Eclipse en Open Source. Évalué à 2.
Oui je pense que l'on n'est sur la même longueur d'onde sur les grands principes.
Et j'ai tendance a vouloir une équipe avec des gens super autonomes et super compétent.
Sûrement une déformation de ce qui est la "norme" selon mes standards.
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . En réponse à la dépêche Sortie du connecteur Tuleap Agile Planner pour Eclipse en Open Source. Évalué à 3.
C'est mieux avec des références!
Voici mon analyse des références:
dans le premier article, les problèmes décrivent des problèmes classiques d’implémentation d'un application (performances de l'application ou donner du feedback a l'utilisateur), et les autres problemes sont tous spécifiques a l’implémentation de leur board qui a l'air un peu boiteuse, et qui surtout n'a rien a voir avec les implémentations actuelles de board.
le second article mentionne qu'"utiliser un board electronique peut avoir de mauvaises conséquences sur les équipes qui ne gèrent pas bien la transition". C'est une phrase tellement generale que tu peux l'appliquer a tout ce que tu veux en remplaçant "board electronique" par "windows", "linux", "rasoir USB", etc.
En gros, ces deux articles ne remettent pas en cause les board electroniques selon moi. Et je maintiens que les membres de l'equipe sont plus important que n'importe quel outil ou processus.
[^] # Re: Agile ?
Posté par djano . En réponse à la dépêche Sortie du connecteur Tuleap Agile Planner pour Eclipse en Open Source. Évalué à 2.
En gros, on est tous d'accord que l'outil pour l'outil ça ne passe pas.
Et l'agile ne passe pas partout non plus.
Tes exemples tiennent plus a la culture d'entreprise ou a la dynamique d'entreprise qu'a l'outil lui même.
;
Dans mon expérience, j'ai vu des gens faire de l'agile en découpant le travail en taches minuscules et a passer plus de temps a gérer ces taches minuscules (en les passant de sprints en sprints et en les requalifiant sans cesse) qu'a faire son autre travail, tout ça dans des meeting super long avec plus de 5 personnes. Tout ça au nom de l'agile!! C'est ce que j'appelle la "bureaucratie agile" qui nous était vendu comme un consultant comme quelque chose d'agile. Si l'on en arrive la, c'est tout sauf agile pour moi. Ce n'est pas pour autant que je rejette les méthodes agiles en bloc.
Pour moi, le truc le plus important et de trouver une dynamique de travail qui permette d'avancer régulièrement et de communiquer ce que l'on fait sans alourdir le travail au jour le jour.
Avoir une personne qui joue uniquement le rôle de scrum master et qui ne fait rien d'autre parce que gérer le processus agile est trop chronophage, c'est exactement l'anti-agile pour moi. Cela fait partie de ce que j'appelle la bureaucratie agile. Il faut alléger un tel processus agile (!?!)
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . En réponse à la dépêche Sortie du connecteur Tuleap Agile Planner pour Eclipse en Open Source. Évalué à 2.
Pourquoi prétends tu que ça ne peut pas être agile?
Tu m'as l'air bien dogmatique, ce qui est un comble pour un agiliste.
[^] # Re: Agile ?
Posté par djano . En réponse à la dépêche Sortie du connecteur Tuleap Agile Planner pour Eclipse en Open Source. Évalué à 3.
Mince plein de gens ne sont pas au courant qu'ils font n'importe quoi! Et en plus tu sais quoi? Ça marche que quand même!
Bref l'outil ou la méthode n'ont rien a voir, ce qui compte ce sont les gens qui l'animent.
Des projets développés de manière distribuée peuvent fonctionner avec des méthodes agiles sans mur physique.
D'ailleurs j'ai vu des équipes avec des murs physiques qui échouaient quand même, comme quoi ce n'est pas la panacée.
Maintenant, je ne comprend pas bien pourquoi tu mets tant d’énergie a affirmer si énergiquement que ça ne marche pas alors que l'on te dit que l'on y arrive au jour le jour.
As tu une expérience a partager?
[^] # Re: Méta-moteurs
Posté par djano . En réponse à la dépêche Se passer de Google, Facebook et autres big brothers 2.0 #1 — Les moteurs de recherche. Évalué à 2.
Je me dois de te corriger un peu: Google a d'abord bâtit son index sur le nombre de liens arrivant sur une page et le texte que les gens mettaient sur les hyper liens, du coup il s'appuyait sur l'intelligence humaine pour fournir des liens pertinents. Ils ont ensuite indexes le contenu des pages elles mêmes pour construire leur fameux PageRank.
Ask Jeeves avait racheté un moteur de recherche prometteur appelé Teoma (voir wikipedia en anglais) dans lequel ils ont fait peu d'investissement et qui n'a pas connu la même trajectoire que Google.
Je me rappelle qu'avec Altavista il fallait aller voir les 30 ou 50 premiers liens retournes pour trouver un truc un peu pertinent.
# Voila!
Posté par djano . En réponse à la dépêche Se passer de Google, Facebook et autres big brothers 2.0 #1 — Les moteurs de recherche. Évalué à 3.
http://web.archive.org/web/20140214200727/http://173.21.64.166/photo_album/chron/desktop/opinion/2013_06_21-avoid_duck_duck_go/
[^] # Re: Restler
Posté par djano . En réponse à la dépêche Tuleap 7.0 est disponible. Évalué à 2.
Merci de ta réponse Yannis!
Awww… Je vois que c'est sur du code PHP. Ça correspond effectivement aux exemples que j'avais vu dans la doc de Restler.
Je croyais que Tuleap était écrit en Java. Bon ben c'est pas grave! :)
# Restler
Posté par djano . En réponse à la dépêche Tuleap 7.0 est disponible. Évalué à 2.
Je vois que vous utilisez un projet appelé Restler pour présenter l'API REST.
Comment avez-vous auto généré cette doc?
# Mais ou est ce donc?
Posté par djano . En réponse à la dépêche Appel à proposition du prochain Open World Forum #OWF14. Évalué à 6.
Puisque ce n'est pas précisé, on doit supposer que c'est a Paris?
C'est dommage d'avoir les information de temps mais pas d'espace.
Le parisiano-centrisme est agaçant.
[^] # Re: Liste des générateurs de sites statiques
Posté par djano . En réponse à la dépêche Makefly, une alternative au moteur de blog statique Nanoblogger. Évalué à 2.
Gagné!
Il te faut soumettre une pull request ici: https://github.com/jaspervdj/static-site-generator-comparison
[^] # Re: Implémentation prouvée
Posté par djano . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 2.
Encore faut-il:
1- arriver a écrire la spec
2- que l’écriture de la spec soit correcte
Pour avoir essaye d’écrire du code avec la méthode B, je peux te garantir que c'est pas demain la veille que tous les logiciels seront écrits avec des méthodes formelles.
[^] # Re: ...
Posté par djano . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 3.
Est ce que tu es en train de dire que du code commercial et toujours audite et toujours de bonne qualité et n'a jamais aucun problème?
Les bras m'en tombent…
[^] # Re: Un phare isolé ?
Posté par djano . En réponse à la dépêche Sortie du langage Pharo et de son environnement de développement en version 3.0. Évalué à 2.
En Java il y a le hot code replace pour réécrire du code en train d’être débogué.
Depuis le débogueur de l'IDE Eclipse, il est même possible d’exécuter du code simple (limitation de la syntaxe) et d'avoir des effets de bords pour aider au débogage.
[^] # Re: Besoin de renfort, vraiment ?
Posté par djano . En réponse à la dépêche Core Infrastructure Initiative. Évalué à 1.
Aussi appelé le 120%.
# Pourquoi utiliser un framapad?
Posté par djano . En réponse à la dépêche Appel à traduction et amélioration d'un article sur Wikipédia : liste des migrations vers GNU/Linux. Évalué à 2.
Pourquoi la traduction n'est-elle pas directement faite sur Wikipedia FR?
Avez-vous vraiment peur que le nombre de contributeurs concurrent rende difficile l’édition sur Wikipedia?
# Typo
Posté par djano . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 4.
Il manque quelques mots ici.