Tout le monde ne parle pas politique et autres débats de société et encore moins de façon extrême ou autre. Tout le monde ne se livre pas à du harcèlement.
C'est justement là où la migration est nécessaire et là où la limite "je ne pourrai pas accéder à mon historique" est un frein.
C'est juste un constat dans la mouvance actuelle de migrer de twitter vers mastodon. Les convaincus acceptent les défauts, les novices en souffrent.
Je ne cherche pas à dénigrer Mastodon ni à encenser Twitter. Des personnes qui migrent et qui sont déçues seront beaucoup plus contre-productives pour prêcher la bonne parole (Mastodon) que des personnes qui savent d'avance à quoi s'attendre voire des personnes qui n'auront juste pas migré.
Twitter n'est pas mieux parce qu'on n'a pas le choix, Twitter est mieux sur ce point là car si tu as un discours consensuel tu ne te fais pas bannir à cause du discours d'autres utilisateurs.
Est ce que ça veut dire que c'est fondamentalement mieux ? Évidemment que non.
Je précise le cas : vous êtes sur un serveur Mastodon qui se fait bannir en totalité car divergence de vision sur la stratégie de modération.
Cela peut être totalement indépendant de ce que vous publiez ; en ce sens la migration de compte me semble nécessaire sur Mastodon là où ça n'est pas obligatoire dans l'écosystème Twitter.
Cela ne change rien et ne remet pas en cause l'intérêt de Mastodon, la puissance de la fédération et l'intérêt d'avoir qqchose de décentralisé.
En lisant le thread j'ai cru comprendre que la migration d'un serveur à un autre était bien prévue (exports csv etc) mais qu'une migration définitive avait pour conséquence la perte d'historique…
Ai-je bien compris ? (Ça me paraît très limité sur le plan gestion des données personnelles - même si je comprends aussi les enjeux de modération etc)
En fait les deux protocoles ne sont pas comparables dans l'usage :
WebDav c'est accédé par les clients et donc il faut développer une robustesse à l'ensemble des clients qui exploitent le protocole. Mettre en place le mécanisme de versionning qui analyse les requêtes WebDAV c'est implémenter un mécanisme de transaction pour traiter les différents cas de figure qui peuvent intervenir en 1 ou plusieurs requêtes HTTP. C'est super, c'est intéressant, mais vu l'utilisation de WebDAV on a meilleur temps de dépenser notre énergie ailleurs
WOPI c'est utilisé pour interconnecter Collabora Online. C'est utilisé entre des briques serveur, c'est un environnement maîtrisé. Le coût d'implémentation ? 4 endpoints d'Api (avec grosso modo 2 semaines d'exploration initiale pour s'approprier le protocole). Ça marche.
Si tu veux faire du WebDAV, fais. Si tu veux gagner de l'argent, fais un calcul de coût et de rentabilité et peut être que tu utiliseras WebDAV, peut-être pas.
Mais si tu ne propose pas du WebDAV, ça veut dire que tu ne permet pas à tes utilisateurs de récupérer les fichiers, comme ils le veulent, avec l'OS qu'ils veulent, donc le besoin n'a rien à voir :)
Tracim le propose. Mais c'est compliqué à exploiter au quotidien, sauf dans une démarche simple récupération ou envoi de fichiers.
L'historique géré dans Tracim est mis à mal avec WebDAV.
Est-ce que WOPI est mieux ? C'est pas vraiment ce que je pense. Ce que je pense, c'est que mettre du WebDAV entre les mains d'utilisateurs c'est du temps de support garanti car les navigateurs de fichiers gèrent le protocole*mais pas tout à fait* et même chacun un peu comme il veut
Le protocole est beaucoup moins puissant que WebDAV à ma connaissance, mais aussi beaucoup plus simple à exploiter.
WebDAV a le défaut d'être implementable de différentes façons, ce qui fait qu'on peut difficilement faire reposer des process dessus.
Exemple : dans Tracim on historique les contenus, y compris quand on déplace un fichier (tu gardes l'historique du fichier). L'interface WebDAV propose aussi ce mécanisme. Mais certains clients ont eu la bonne idée d'implémenter le couper-coller comme une suppression-création et d'autres font un "move", ce qui engendre des comportements inattendus et surtout hétérogènes.
C'est pas la faute du protocole fondamentalement, mais qqchose de pas assez cadré laisse la porte ouverte …
T'es un business, ton but c'est d'être viable, de générer du revenu, de payer tes employers, de payer ta direction. Bref, le but d'un business c'est de faire de la thune.
Avec le temps, je me suis rendu compte pour faire de l'argent avec du libre, il faut…. de l'argent, beaucoup d'argent.
Tu peux faire du business autour du libre assez facilement sans argent : tu fais de la prestation.
Être éditeur c'est plus difficile car la stratégie c'est d'avoir un avantage concurrentiel et si ton soft est vraiment libre, il faut trouver autre chose que la R&D (cf le fil que j'ai avec Zenitram)
Tu peux être sur une niche aussi. Ça se fait plutôt bien.
Tu parles de grosses boîtes qui font de l'argent avec du libre, mais ce n'est pas ça qu'ils vendent. Ni Google ni Amazon n'ont un modèle économique basé sur le logiciel libre. C'est une des composantes de leur activité mais ce n'est pas ça qu'ils vendent.
Si tu veux vraiment tirer ton épingle du jeu avec du libre, il me semble que la seule solution est que le libre soit un moyen et non une finalité.
Par exemple en ciblant exclusivement les collectivités - voir la scope entrouvert. Par exemple en ayant une stratégie de mutualisation des développements (cf la boîte de l'ancien associé de Cozy qui trainait pas mal dans le coin). Par exemple en développant une image de marque, en montrant la qualité de ton travail, en développant une philosophie en phase avec ta clientèle (ce qu'on fait à Algoo)
Ce que je dis c'est que pour vendre du service sur des logiciels libres, il faut déjà des logiciels. Et développer des logiciels a un coût, qu'il faut encaisser d'une manière ou d'une autre.
Je ne défend aucun modèle je dis juste que si une boîte fait toute la R&D et que les autres se contentent d'exploiter le logiciel, c'est pas "à armes égales".
Vendre des livrables ça se fait. Collabora le fait. Vendre du service ça se fait. XWiki, Algoo, ta boîte le font. Ne pas pouvoir faire face à la concurrence, ça existe aussi : quand Amazon "attaque" Elastic, c'est compliqué.
J'ai l'impression que dès que les enjeux sont très forts, le modèle éditeur de logiciels libres est très délicat à gérer.
de profiter d'un monopole sous excuse qu'elle a investit dans la R&D avant. Le passé est le passé
Sur ce point je suis en désaccord. Faire de la R&D c'est pas du passé, c'est dans la durée : il faut maintenir une équipe car un logiciel qui n'évolue plus est un logiciel mort.
Je ne connais pas le modèle économique de sentry ; un éditeur est généralement le plus à même de maintenir le logiciel et le faire évoluer. Mais pour cela il faut que des clients acceptent l'idée de miser dans la durée.
Pour revenir au sujet de la R&D, il faut qu'elle soit faite, et dans la durée. C'est un centre de coût qu'il faut intégrer dans l'équation de la gestion de l'entreprise, au même titre que la comptabilité, les RH, etc. Ne pas le vendre en tant que tel n'est pas un problème, mais il faut le financer.
À chacun de trouver la manière de faire qui lui convient le mieux ; à chacun de décider de ce qui est le plus pertinent compte tenu de son environnement économique (concurrence, typologie de clientèle, capacité à fédérer les efforts, etc)
Et je reste assez convaincu que certains écosystèmes sont nettement plus sauvages que d'autres (et que donc y faire du libre est d'autant plus difficile)
les libertés du libre, la compétition à armes égales
Si une boîte finance la R&D et les autres ne font que récupérer ce n'est pas à armes égales.
Le modèle dolibarr ou postgresql, je pense qu'on peut parler de libre à armes égales.
D'autres modèles ne sont pas à armes égales (sans dire que c'est dans un sens ou dans l'autre) : l'éditeur a l'inconvénient des frais de R&D et l'avantage de maîtrise produit et roadmap.
Je connais peu de boîtes qui font vraiment du libre car c'est compliqué et ça dépend beaucoup de la typologie de clientèle.
Si tu es ok pour nous aider à travers tes retours et qu'on puisse les exploiter facilement , je te mets en contact avec les 2 personne qui bossent sur l'interface et l'ux. Ça permettrait de faire des échanges potentiellement en partage d'écran, de vive voix et ça évitera les intermédiaires (ce que je fais ici si je partage tes retours ;).
Si tu es ok, envoie moi un email : Damien point Accorsi arobase Algoo point fr. Ensuite je te mettrai en relation directe avec les bonnes personnes
les utilisateurs d'outils bureautique veulent des solutions simples à utiliser plus que des solutions rigoureuses et puissantes
Pourquoi utilisent-ils Word et Excel qui sont tous sauf simples ? :-)
Parce que tout le monde l'utilise. Tu trouveras toujours quelqu'un pour t'aider (y compris les fans de libreOffice;)
La complexité du concept de branches et révisions, etc sont au delà de ce qu'on recherche dans un outil collaboratif bureautique.
Moi aussi je voudrais construire moi même une maison sans formation en maçonnerie, plomberie et électricité, mais comment faire ?
On ne parle pas de rédiger une publication scientifique ou un livre où les règles à respecter sont nombreuses et complexes mais de rédiger des documents de travail - CR d'intervention, courrier, réponse à appel d'offre. La qualité technique de construction n'est pas critique car ces documents ne sont pas amenés à évoluer dans la durée.
Si je reprends ton exemple dans le domaine de la construction : qui n'a jamais bricolé lui même une étagère, une salle de bain, une dalle ou encore un muret. On apprend les rudiments et on arrive au niveau de qualité attendu - qui pourra être critiqué par un professionnel, mais si ça fait le boulot, ça fait le boulot.
Je dis pas que c'est bien (ni que c'est mal) ; c'est plutôt un constat.
Travailler ensemble n'est pas naturel pour beaucoup de personnes. Souvent c'est vu comme je fais ma partie et je la livre, processus dans lequel il est exclu d'intervenir. Cela peut d'ailleurs se comprendre pour des raisons d'efficacité. Mais il y a également la notion de transparence qui est souvent rejetée, type : "non je te montre pas c'est pas terminé. Je te montrerai une fois que j'ai résolu les derniers points ".
On retrouve ça très souvent aussi dans le domaine du développement.
La collaboration encapsule la production d'information, mais également sa diffusion, la recherche, les sollicitations.
La valeur ajoutée de Tracim devient évidente lorsqu'on exploite ces différents aspects :
un évènement n'est pas mis dans son agenda perso puis dans l'agenda partagé mais directement dans l'agenda partagé (que chacun intègre avec son agenda perso)
on documente les nouvelles révisions de document
on considère le travail comme appartenant à l'équipe et non à l'individu
on veut affecter des tâches à des personnes (y compris associées à des documents précis) et en suivre l'exécution
on communique avec l'équipe
on veut garder trace de l'histoire pour permettre aux nouveaux venus d'entrer dans le sujet le plus rapidement possible avec toutes les informations en main
D'ailleurs au sujet de l'édition en ligne, je serais très curieux de connaître le nombre de personnes qui l'utilise vraiment pour de la collaboration. Mon ressenti est surtout que c'est utilisé comme un confort d'utilisation : mon document est toujours disponible et la dernière version, quel que soit l'appareil à partir duquel j'y accède.
Les développeurs qui n'ont pas de PC pour télétravailler ou qui télétravaillent avec un ordinateur personnel ont forcément été confrontés à un moment ou à un autre à une version de leur code qui est malheureusement sur l'autre machine.
C'est un sujet super intéressant sur lequel on a passé du temps sur Tracim :
les gestionnaires de version pourraient s'appuyer sur le souce XML, mais le contenu est fortement structuré et faire des diff d'arbres est complexe et pas de résolution unique
En conséquence du point ci-dessus, les diff de documents bureautique c'est compliqué, ça marchotte quand ça existe mais rien de très abouti
Je n'ai jamais regardé les outils de fusion existant, mais logiquement vu 1 et 2, ça ne peut pas se résoudre simplement
Je rajouterai aussi :
les utilisateurs d'outils bureautique veulent des solutions simples à utiliser plus que des solutions rigoureuses et puissantes
La complexité du concept de branches et révisions, etc sont au delà de ce qu'on recherche dans un outil collaboratif bureautique.
Pour des gens dont le quotidien est fait de rédaction collaborative, ça serait sûrement le pied - mais ceux-là utilisent souvent déjà des outils à base de fichiers source textuels.
Par exemple les documents embarquent des solutions de commentaires, de révision, etc, mais qui les utilise ? Peu de personnes (y compris les gens au fait tels que les développeurs).
Dans ce contexte, l'édition collaborative en ligne est la seule solution qui réponde. C'est pas l'idéal mais ça marche - en tout cas sur des documents modestes.
La rédaction de longs documents reste dans tous les cas plus confortable sur son ordinateur, avec une suite bureautique native.
Le retour "dans Tracim on ne passe pas facilement d'une application à une autre alors que les autres solutions le permettent" me semble inapproprié : le paradigme de Tracim, c'est basé sur les espaces de collaboration, pas sur les applications.
Je ne connais pas odoo, je connais un peu nextcloud. Dans Nextcloud, par exemple, il me semble pas que tu retrouves en un clic les notes du projet courant : tu bascules d'une application à une autre, toutes données comprises.
Le paradigme Tracim est plutôt une forge de collaboration. Dans gitlab par exemple, tu ne bascules pas de "tous les codes sources à tous les tickets" : tu es dans un contexte projet.
Ça ne veut pas dire qu'il n'y a pas des choses à améliorer ; mais prendre Tracim comme une somme d'applications c'est voué à la déception car ce n'est pas ça qui le définit.
Tracim s'installe facilement avec l'image docker ; il faut un serveur dédié ceci dit.
Nextcloud, si je ne me trompe pas, c'est du PHP donc + classique comme Starck technique.
Par contre, aujourd'hui souvent on s'attend à avoir de l'édition collaborative type collabora online, et la la complexité technique de Tracim n'est plus un sujet : c'est pas plus compliqué que Collabora Online.
Ça fait probablement 5 ans qu'on voulait faire un client de synchronisation et qu'on a creusé et abandonné des pistes. Et qu'on avait fini par laisser tomber, faute de priorité et de financement (on n'a pas d'investisseurs à Algoo, on développe ce que nos clients demandent et financent).
Quand bux m'a montré son projet, j'ai été emballé et d'autant plus que le projet trsync s'est développé sans nécessité de faire évoluer le cœur de Tracim : trsync s'appuie sur les APIs et sur le websocket pour établir la communication bidirectionnelle. Comme l'interface utilisateur en fait - mais du coup l'API est largement suffisante pour traiter le sujet.
En finançant une partie du travail sur trsync, j'ai voulu rendre l'outil utilisable par le grand public - installeur Windows, icône visible dans le bureau, etc.
Trsync est composé de plusieurs briques et est donc + facilement accessible à un contributeur. Trsync est un projet indépendant de Algoo et de Tracim.
Je suis content que Algoo ait contribué à un projet indépendant, et ce d'autant plus qu'on utilise trsync en production en interne chez Algoo, notamment pour les personnes administratives qui s'affranchissent naturellement de la problématique fichier local vs fichier distant.
Prochaine contribution financière ? Probablement qqchose autour des notifications, mentions ou tâches pour interagir avec Tracim directement depuis son bureau. J'imagine bien trsync devenir le client officiel natif (et contrairement à beaucoup de solutions, ce n'est pas un navigateur internet embarqué mais bien une application native)
[^] # Re: On ne peut pas migrer ses messages
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Si vous êtes sur mastodon.social ou mastodon.online, ceci peut vous concerner. Évalué à 4.
C'est justement là où la migration est nécessaire et là où la limite "je ne pourrai pas accéder à mon historique" est un frein.
C'est juste un constat dans la mouvance actuelle de migrer de twitter vers mastodon. Les convaincus acceptent les défauts, les novices en souffrent.
Je ne cherche pas à dénigrer Mastodon ni à encenser Twitter. Des personnes qui migrent et qui sont déçues seront beaucoup plus contre-productives pour prêcher la bonne parole (Mastodon) que des personnes qui savent d'avance à quoi s'attendre voire des personnes qui n'auront juste pas migré.
[^] # Re: On ne peut pas migrer ses messages
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Si vous êtes sur mastodon.social ou mastodon.online, ceci peut vous concerner. Évalué à 4.
Twitter n'est pas mieux parce qu'on n'a pas le choix, Twitter est mieux sur ce point là car si tu as un discours consensuel tu ne te fais pas bannir à cause du discours d'autres utilisateurs.
Est ce que ça veut dire que c'est fondamentalement mieux ? Évidemment que non.
[^] # Re: On ne peut pas migrer ses messages
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Si vous êtes sur mastodon.social ou mastodon.online, ceci peut vous concerner. Évalué à 3.
Je précise le cas : vous êtes sur un serveur Mastodon qui se fait bannir en totalité car divergence de vision sur la stratégie de modération.
Cela peut être totalement indépendant de ce que vous publiez ; en ce sens la migration de compte me semble nécessaire sur Mastodon là où ça n'est pas obligatoire dans l'écosystème Twitter.
Cela ne change rien et ne remet pas en cause l'intérêt de Mastodon, la puissance de la fédération et l'intérêt d'avoir qqchose de décentralisé.
[^] # Re: On ne peut pas migrer ses messages
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Si vous êtes sur mastodon.social ou mastodon.online, ceci peut vous concerner. Évalué à 4.
Ce problème d'invisibilisation "malgré soi" ne se pose pas dans l'écosystème Twitter à ma connaissance.
# On ne peut pas migrer ses messages
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Si vous êtes sur mastodon.social ou mastodon.online, ceci peut vous concerner. Évalué à 6.
En lisant le thread j'ai cru comprendre que la migration d'un serveur à un autre était bien prévue (exports csv etc) mais qu'une migration définitive avait pour conséquence la perte d'historique…
Ai-je bien compris ? (Ça me paraît très limité sur le plan gestion des données personnelles - même si je comprends aussi les enjeux de modération etc)
[^] # Re: Choix étonnant
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal La communauté GNOME remplace ses mailing lists par Discourse. Évalué à 2.
Ou un Tracim (mais ya beaucoup de JS …)
[^] # Re: Websocket
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 4.
En fait les deux protocoles ne sont pas comparables dans l'usage :
Si tu veux faire du WebDAV, fais. Si tu veux gagner de l'argent, fais un calcul de coût et de rentabilité et peut être que tu utiliseras WebDAV, peut-être pas.
[^] # Re: Websocket
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 2.
Tracim le propose. Mais c'est compliqué à exploiter au quotidien, sauf dans une démarche simple récupération ou envoi de fichiers.
L'historique géré dans Tracim est mis à mal avec WebDAV.
[^] # Re: Websocket
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 4.
WebDAV c'est aussi des données XML …
Est-ce que WOPI est mieux ? C'est pas vraiment ce que je pense. Ce que je pense, c'est que mettre du WebDAV entre les mains d'utilisateurs c'est du temps de support garanti car les navigateurs de fichiers gèrent le protocole*mais pas tout à fait* et même chacun un peu comme il veut
[^] # Re: Websocket
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 4.
tu voulais sans doute écrire WOPI.
Le protocole est beaucoup moins puissant que WebDAV à ma connaissance, mais aussi beaucoup plus simple à exploiter.
WebDAV a le défaut d'être implementable de différentes façons, ce qui fait qu'on peut difficilement faire reposer des process dessus.
Exemple : dans Tracim on historique les contenus, y compris quand on déplace un fichier (tu gardes l'historique du fichier). L'interface WebDAV propose aussi ce mécanisme. Mais certains clients ont eu la bonne idée d'implémenter le couper-coller comme une suppression-création et d'autres font un "move", ce qui engendre des comportements inattendus et surtout hétérogènes.
C'est pas la faute du protocole fondamentalement, mais qqchose de pas assez cadré laisse la porte ouverte …
[^] # Re: BSL
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Sentry redevient privateur. Évalué à 5.
Tu peux faire du business autour du libre assez facilement sans argent : tu fais de la prestation.
Être éditeur c'est plus difficile car la stratégie c'est d'avoir un avantage concurrentiel et si ton soft est vraiment libre, il faut trouver autre chose que la R&D (cf le fil que j'ai avec Zenitram)
Tu peux être sur une niche aussi. Ça se fait plutôt bien.
Tu parles de grosses boîtes qui font de l'argent avec du libre, mais ce n'est pas ça qu'ils vendent. Ni Google ni Amazon n'ont un modèle économique basé sur le logiciel libre. C'est une des composantes de leur activité mais ce n'est pas ça qu'ils vendent.
Si tu veux vraiment tirer ton épingle du jeu avec du libre, il me semble que la seule solution est que le libre soit un moyen et non une finalité.
Par exemple en ciblant exclusivement les collectivités - voir la scope entrouvert. Par exemple en ayant une stratégie de mutualisation des développements (cf la boîte de l'ancien associé de Cozy qui trainait pas mal dans le coin). Par exemple en développant une image de marque, en montrant la qualité de ton travail, en développant une philosophie en phase avec ta clientèle (ce qu'on fait à Algoo)
# J'ai lu...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Une usurpation d'identité qui s'est retournée contre ses propres commanditaires. Évalué à 10.
Je ne vois pas trop où on peut dire que ça se retourne contre le commanditaire.
À l'heure du télétravail et des réseaux sociaux, et de la vie publique, c'est assez flippant.
Combien de personnes vont faire cette démarche plutôt que de juste laisser tomber ?
:-/
[^] # Re: BSL
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Sentry redevient privateur. Évalué à 7.
Ce que je dis c'est que pour vendre du service sur des logiciels libres, il faut déjà des logiciels. Et développer des logiciels a un coût, qu'il faut encaisser d'une manière ou d'une autre.
Je ne défend aucun modèle je dis juste que si une boîte fait toute la R&D et que les autres se contentent d'exploiter le logiciel, c'est pas "à armes égales".
Vendre des livrables ça se fait. Collabora le fait. Vendre du service ça se fait. XWiki, Algoo, ta boîte le font. Ne pas pouvoir faire face à la concurrence, ça existe aussi : quand Amazon "attaque" Elastic, c'est compliqué.
J'ai l'impression que dès que les enjeux sont très forts, le modèle éditeur de logiciels libres est très délicat à gérer.
Sur ce point je suis en désaccord. Faire de la R&D c'est pas du passé, c'est dans la durée : il faut maintenir une équipe car un logiciel qui n'évolue plus est un logiciel mort.
Je ne connais pas le modèle économique de sentry ; un éditeur est généralement le plus à même de maintenir le logiciel et le faire évoluer. Mais pour cela il faut que des clients acceptent l'idée de miser dans la durée.
Pour revenir au sujet de la R&D, il faut qu'elle soit faite, et dans la durée. C'est un centre de coût qu'il faut intégrer dans l'équation de la gestion de l'entreprise, au même titre que la comptabilité, les RH, etc. Ne pas le vendre en tant que tel n'est pas un problème, mais il faut le financer.
À chacun de trouver la manière de faire qui lui convient le mieux ; à chacun de décider de ce qui est le plus pertinent compte tenu de son environnement économique (concurrence, typologie de clientèle, capacité à fédérer les efforts, etc)
Et je reste assez convaincu que certains écosystèmes sont nettement plus sauvages que d'autres (et que donc y faire du libre est d'autant plus difficile)
[^] # Re: BSL
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Sentry redevient privateur. Évalué à 6.
Si une boîte finance la R&D et les autres ne font que récupérer ce n'est pas à armes égales.
Le modèle dolibarr ou postgresql, je pense qu'on peut parler de libre à armes égales.
D'autres modèles ne sont pas à armes égales (sans dire que c'est dans un sens ou dans l'autre) : l'éditeur a l'inconvénient des frais de R&D et l'avantage de maîtrise produit et roadmap.
Je connais peu de boîtes qui font vraiment du libre car c'est compliqué et ça dépend beaucoup de la typologie de clientèle.
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 3.
Je transmets ça demain 👍
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 4.
Si tu es ok pour nous aider à travers tes retours et qu'on puisse les exploiter facilement , je te mets en contact avec les 2 personne qui bossent sur l'interface et l'ux. Ça permettrait de faire des échanges potentiellement en partage d'écran, de vive voix et ça évitera les intermédiaires (ce que je fais ici si je partage tes retours ;).
Si tu es ok, envoie moi un email : Damien point Accorsi arobase Algoo point fr. Ensuite je te mettrai en relation directe avec les bonnes personnes
[^] # Re: Pot pourri
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 4.
Parce que tout le monde l'utilise. Tu trouveras toujours quelqu'un pour t'aider (y compris les fans de libreOffice;)
On ne parle pas de rédiger une publication scientifique ou un livre où les règles à respecter sont nombreuses et complexes mais de rédiger des documents de travail - CR d'intervention, courrier, réponse à appel d'offre. La qualité technique de construction n'est pas critique car ces documents ne sont pas amenés à évoluer dans la durée.
Si je reprends ton exemple dans le domaine de la construction : qui n'a jamais bricolé lui même une étagère, une salle de bain, une dalle ou encore un muret. On apprend les rudiments et on arrive au niveau de qualité attendu - qui pourra être critiqué par un professionnel, mais si ça fait le boulot, ça fait le boulot.
Je dis pas que c'est bien (ni que c'est mal) ; c'est plutôt un constat.
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 4.
Merci pour le retour en tout cas.
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 7.
Travailler ensemble n'est pas naturel pour beaucoup de personnes. Souvent c'est vu comme je fais ma partie et je la livre, processus dans lequel il est exclu d'intervenir. Cela peut d'ailleurs se comprendre pour des raisons d'efficacité. Mais il y a également la notion de transparence qui est souvent rejetée, type : "non je te montre pas c'est pas terminé. Je te montrerai une fois que j'ai résolu les derniers points ".
On retrouve ça très souvent aussi dans le domaine du développement.
La collaboration encapsule la production d'information, mais également sa diffusion, la recherche, les sollicitations.
La valeur ajoutée de Tracim devient évidente lorsqu'on exploite ces différents aspects :
[^] # Re: Pot pourri
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 9.
D'ailleurs au sujet de l'édition en ligne, je serais très curieux de connaître le nombre de personnes qui l'utilise vraiment pour de la collaboration. Mon ressenti est surtout que c'est utilisé comme un confort d'utilisation : mon document est toujours disponible et la dernière version, quel que soit l'appareil à partir duquel j'y accède.
Les développeurs qui n'ont pas de PC pour télétravailler ou qui télétravaillent avec un ordinateur personnel ont forcément été confrontés à un moment ou à un autre à une version de leur code qui est malheureusement sur l'autre machine.
[^] # Re: Pot pourri
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 10.
C'est un sujet super intéressant sur lequel on a passé du temps sur Tracim :
Je rajouterai aussi :
Pour des gens dont le quotidien est fait de rédaction collaborative, ça serait sûrement le pied - mais ceux-là utilisent souvent déjà des outils à base de fichiers source textuels.
Par exemple les documents embarquent des solutions de commentaires, de révision, etc, mais qui les utilise ? Peu de personnes (y compris les gens au fait tels que les développeurs).
Dans ce contexte, l'édition collaborative en ligne est la seule solution qui réponde. C'est pas l'idéal mais ça marche - en tout cas sur des documents modestes.
La rédaction de longs documents reste dans tous les cas plus confortable sur son ordinateur, avec une suite bureautique native.
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 5.
Merci pour tous ces retours.
Le retour "dans Tracim on ne passe pas facilement d'une application à une autre alors que les autres solutions le permettent" me semble inapproprié : le paradigme de Tracim, c'est basé sur les espaces de collaboration, pas sur les applications.
Je ne connais pas odoo, je connais un peu nextcloud. Dans Nextcloud, par exemple, il me semble pas que tu retrouves en un clic les notes du projet courant : tu bascules d'une application à une autre, toutes données comprises.
Le paradigme Tracim est plutôt une forge de collaboration. Dans gitlab par exemple, tu ne bascules pas de "tous les codes sources à tous les tickets" : tu es dans un contexte projet.
Ça ne veut pas dire qu'il n'y a pas des choses à améliorer ; mais prendre Tracim comme une somme d'applications c'est voué à la déception car ce n'est pas ça qui le définit.
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 2.
Tracim s'installe facilement avec l'image docker ; il faut un serveur dédié ceci dit.
Nextcloud, si je ne me trompe pas, c'est du PHP donc + classique comme Starck technique.
Par contre, aujourd'hui souvent on s'attend à avoir de l'édition collaborative type collabora online, et la la complexité technique de Tracim n'est plus un sujet : c'est pas plus compliqué que Collabora Online.
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 2.
Ah c'est intéressant ça. Quelles ont été les objections ?
# Réaction en tant que créateur de Tracim et dirigeant Algoo
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal 1ʳᵉ version "grand public" de TrSync. Évalué à 10.
Ça fait probablement 5 ans qu'on voulait faire un client de synchronisation et qu'on a creusé et abandonné des pistes. Et qu'on avait fini par laisser tomber, faute de priorité et de financement (on n'a pas d'investisseurs à Algoo, on développe ce que nos clients demandent et financent).
Quand bux m'a montré son projet, j'ai été emballé et d'autant plus que le projet trsync s'est développé sans nécessité de faire évoluer le cœur de Tracim : trsync s'appuie sur les APIs et sur le websocket pour établir la communication bidirectionnelle. Comme l'interface utilisateur en fait - mais du coup l'API est largement suffisante pour traiter le sujet.
En finançant une partie du travail sur trsync, j'ai voulu rendre l'outil utilisable par le grand public - installeur Windows, icône visible dans le bureau, etc.
Trsync est composé de plusieurs briques et est donc + facilement accessible à un contributeur. Trsync est un projet indépendant de Algoo et de Tracim.
Je suis content que Algoo ait contribué à un projet indépendant, et ce d'autant plus qu'on utilise trsync en production en interne chez Algoo, notamment pour les personnes administratives qui s'affranchissent naturellement de la problématique fichier local vs fichier distant.
Prochaine contribution financière ? Probablement qqchose autour des notifications, mentions ou tâches pour interagir avec Tracim directement depuis son bureau. J'imagine bien trsync devenir le client officiel natif (et contrairement à beaucoup de solutions, ce n'est pas un navigateur internet embarqué mais bien une application native)