Qu'on aime ou pas Zenitram il est resté factuel. Et je le rejoins : la justice ne s'applique pas sur la base d'émotions mais de faits.
Pour évaluer un litige, il faut avoir la version des deux parties sinon comment avoir un avis objectif ?
Zenitram ne dit pas que ton ex employeur a raison et que tu es responsable de ce qui t'es arrivé mais que si tu as présenté ton dossier comme tu viens de nous le présenter, il n'est pas étonné que la justice n'ait pas tranché en ta faveur.
La justice ce n'est pas le bien contre le mal mais la présomption d'innocence et le respect des règles établies (la loi) ou la sanction. Ça s'appuie sur des faits établis et prouvés.
Si tu es victime de viol mais que tu n'as strictement aucune preuve, ton agresseur ne sera très probablement pas condamné. Est-ce que c'est juste par rapport à la réalité des faits ? Probablement que non. Est-ce que c'est juste par rapport à la meilleure manière d'appliquer la loi : je pense que oui. Malheureusement.
Oui, c'est l'excuse sortie plusieurs fois pour fermer.
Parfois c'est vrai et parfois non. Il y a des marchés qui sont tellement corrompus que tu ne peux pas y aller / y rester si tu respectes les règles légales et l'éthique. La corruption, le lobbying, la concurrence déloyale, l'espionnage industriel, ce n'est pas juste dans les livres.
Une entreprise n'a pas vocation à changer les règles du jeu mais à assurer sa viabilité économique. Si tu veux changer les règles du jeu, il faut faire de la politique.
En d'autres mots, il faut que le libre devienne équivalent à une obligation légale.
Ça serait idéal ; mais regarde : le gouvernement a publié un référentiel général d'interopérabilité et il est le premier à ne pas le respecter. Pourquoi attendre d'une entreprise qu'elle fasse mieux ?
Ce dernier point me semble t'il est tout à fait compréhensible
C'est que tu n'as pas compris que le libre est justement pour que les autres aient la liberté de faire ce que tu penses légitime d'interdire, ça fait partie des 4 libertés (faire ce que tu veux de ce que tu as reçu).
Ce que tu n'as pas compris, c'est que MapBox a choisi de mettre en place une stratégie s'appuyant sur du logiciel libre pour différentes raisons. Que cette stratégie ne répond pas à ses attentes et qu'ils changent. Il n'est pas question d'interdire de faire quoi que ce soit à qui que ce soit : c'est juste un changement de stratégie.
Le fait de dire "ils ont fait exprès de choisir une stratégie en s'appuyant sur du libre pour gagner de la notoriété et maintenant qu'ils ont cette notoriété ils arrêtent" ce n'est pas un fait. En tout cas je n'ai rien lu qui aille dans ce sens. C'est une hypothèse qui se tient, et qui ne se tient ni plus ni moins que "ils ont choisi une stratégie en s'appuyant sur du libre pour développer un bien commun tout en gagnant correctement leur vie et ça ne répond pas à leurs attentes et ils changent donc de stratégie". La différence, c'est que dans un cas c'est un changement de stratégie à dessein tandis que dans l'autre cas c'est du pragmatisme de gestion d'entreprise.
Par exemple, si tu as une rentabilité 2 fois moindre que tes concurrents, c'est une chose à prendre en compte, et c'est une position qui est difficilement tenable sur le long terme.
Oui, le libre fait chier, le libre t’empêche d'interdire ce qui t'emmerde que les autres fassent.
Le libre ne fait pas chier ; le libre implique des choses et comme tu le dis ça n'empêche pas d'interdire. Je ne vois à aucun endroit MapBox dire "le libre nous fait chier, on arrête" mais "la nouvelle version ne sera pas en libre". C'est un choix stratégique. Point.
Il faut donc que ceux qui ne veulent pas laisser ces libertés soient pas bien vues.
Là on est 100% d'accord (sauf si ta cible c'est MapBox. Parce qu'à ma connaissance, il n'y a pas de + contributeur dans le domaine de la cartographie, donc tirer sur MapBox, c'est contre-productif).
Il y a un sacré travail sur le sujet, auprès des entreprises utilisatrices, auprès des politiques … et auprès des libristes eux-même. On peut faire un sondage pour savoir combien de libristes préfèrent Chrome à Firefox par exemple. Ou qui préfèrent acheter chez Amazon que ailleurs. Chacun a de bonnes raisons de favoriser ceux qui devraient être moins bien vus.
Par ailleurs il me semble que mapbox est contributeur de nombreux modules libres disponible indépendamment de leur solution.
Oui, classique, comme Google et compagnie : faire en libre ce qui n'est pas bankable mais garder le bankable. Perso, je m’intéresse toujours au bankable, désolé :).
Que des boites fassent du libre en non bankable est un petit plus.
Que des boites fassent du libre en bankable est un gros plus.
Je m'intéresse au bankable aussi. Ce n'est pas la majorité des cas (le nombre de pro techno google ou pro amazon dans les colonnes de LinuxFR est symptômatique de cela : la libération du bankable n'est pas la priorité absolue, même pour les libristes)
Et pour moi, c'est subjectif certes, il faut que les boites qui font un gros plus soient plus reconnues dans la communauté du libre que les boites qui font un petit plus. Mais surtout que celles qui faisaient un gros plus puis ont font un petit aient le succès du petit plus (perdre l'aura qu'ils ont récupéré du gros plus en libre), ce qui n'est pas le cas aujourd'hui (du coup c'est bénéf à fond de commencer par du libre pour se faire connaître puis fermer).
Pas simple, mais il faut trouver une méthode pour que le libre devienne une condition nécessaire.
Je suis bien d'accord avec toi. Et je ne vois pas vraiment de solution, en particulier parce que « les libristes » eux-même ont un positionnement qui est discutable par rapport à cela. (et je ne parle pas des visiteurs de nos stands Tracim sur les événements qui critiquent notre position d'entreprise ou le mode de gouvernance d'Algoo sous prétexte qu'on devrait être une SCOP voire une association de bénévoles pour vraiment respecter le libre)
On peut voir "du dev gratos" comme de la mutualisation de compétences.
On peut voir du "dev gratos" comme un échange de bons procédés (mise à disposition de travail de r&d gratuitement contre retours).
Il me semblait avoir lu qqpart que c'était lié au fait que de gros acteurs exploitaient sans rétribution et que économiquement ce n'est simplement pas tenable.
Ce dernier point me semble t'il est tout à fait compréhensible (y compris pour arrêter de faire du libre), et est indépendant de "se faire une communauté sur le dos du libre et ensuite fermer le code".
Par ailleurs il me semble que mapbox est contributeur de nombreux modules libres disponible indépendamment de leur solution.
Je trouve cette clarification très importante et intéressante. Je vois du coup le framework comme un outil de programmation rapide d'interface utilisateur.
Dans le cas du développement d'un outil de gestion, du coup, j'aurais tendance à le comparer dans une certaine mesure à Django que j'utilise personnellement pour dév des outils perso via quasi-exclusivement Django Admin (l'interface d'admin de Django).
Concrètement, dans quel cas conseilles-tu d'utiliser le framework ? Pour développer un nouvel outil ? Proposer une interface utilisateur à un outil ou du code existant sous forme de CLI ou de lib ?
Il est question de "travail collaboratif sécurisé", ce qui fondamentalement ne veut pas dire grand chose.
« Travail collaboratif » me semble assez explicite : la possibilité d'échanger/communiquer/travailler pour deux personnes et plus.
« sécurisé » est toujours plus relatif au contexte : chiffrement en transit, bout-en-bout, sur quel périmètre, pour quel modèle de menace, etc. D'où la précision ajoutée dans la phrase qui suit.
Par ailleurs dire que ça ne vient pas dire grand chose ne veut fondamentalement pas dire grand chose non plus :). On ne sait pas ce qui n'est pas clair ou assez précis pour toi ici.
Oui tu as complètement raison :)
Pour moi c'est la notion "c'est sécurisé" qui est floue. Par exemple si tu veux déployer sur une infrastructure en laquelle tu n'as pas totalement confiance, cryptpad me semble une bonne solution. Si en revanche ton infrastructure fait partie du "périmètre de confiance", Tracim répondra et proposera un périmètre fonctionnel plus large sur des sujets qui ne sont pas adressables (ou très difficilement) avec un chiffrement de bout-en-bout. Par exemple implémenter un moteur de recherche nécessite d'indexer le contenu (donc d'y avoir accès). Avec un chiffrement de bout-en-bout c'est relativement complexe, a fortiori dans une application web.
Un autre point important pour les notions de sécurité sur une application en ligne : il y a la sécurité "by design" dans le produit (exemples : chiffrement de bout en bout, modèles de gestion des droits d'accès, méthode de développement, etc) mais également la manière dont est déployé l'outil. Et enfin - et surtout - la manière dont est utilisé l'outil.
Pour le reste, je suis d'accord avec tes réponses. Les deux points clé de mon commentaire sont vraiment la reformulation du titre (qui est très bien comme tu viens de le faire) et la notion de sécurité qui mérite d'être clarifiée sans quoi elle apporte peu.
Il est question de "travail collaboratif sécurisé", ce qui fondamentalement ne veut pas dire grand chose.
Du coup comme cette terminologie n'est pas explicitée, la dépêche ressemble à une liste plus ou moins cohérente de logiciels.
Par exemple on trouve libreoffice online en alternative à cryptpad alors que l'un est un éditeur de documents bureautique en ligne et l'autre une solution chiffrée de bout en bout.
Il n'est pas fait mention de Etherpad ou Ethercalc non plus. Est-ce pour des raisons de sécurité ? Si oui, pourquoi libreoffice apparaît (à ma connaissance libreoffice online ne fait pas de chiffrement) ?
Il est également évoqué NextCloud et onlyoffice groups par exemple mais pas Tracim.
Au niveau visioconférence les solutions sont elles équivalentes ? Quelles sont les possibilités de chacune d'un point de vue sécurité ? Et d'un point de vue collaboration ?
La démarche est intéressante mais finalement le manque d'objectivité qui était le reproche principal fait à MariePa est aussi présent dans cette dépêche. Idem pour le flou autour des solutions évoquées.
Je comprends qu'une telle dépêche ne puisse avoir la prétention de présenter toutes les solutions existantes, mais là on mélange 2 thématiques (la sécurité et les solutions de travail en équipe) sans expliquer la démarche, les critères pour "définir" quelles solutions sont pertinentes.
Par exemple en tant que leader de Tracim, j'aurais tendance à me dire "ah ben dommage Tracim n'apparaît pas dans cette liste, c'est contre productif pour notre logiciel". Mais en même temps Tracim n'est pas une solution orientée chiffrement de bout en bout. Mais en même temps c'est le cas de plusieurs solutions évoquées - si on parle de Libreoffice ou Onlyoffice groups, Tracim me semble pertinent. Si on parle de chiffrement de bout en bout ça ne l'est pas (cela veut il dire que Tracim n'est pas sécurisé ? Non pas nécessairement).
Il me semble que le titre est trompeur et qu'il serait plus approprié sous une forme du type : "quelques solutions libres permettant de collaborer en ligne avec un niveau de confidentialité potentiellement fort". (Je reconnais que cette formulation un peu longue;)
Enfin dernier point lié au titre, on s'attendrait potentiellement à des conseils sur comment sécuriser ces outils, mais cf n'est pas le cas non plus. Jitsi meet par exemple peut être utilisé avec différents niveaux de confidentialité, liés à la manière de l'utiliser mais également à la manière de le configurer.
Pour les 249$ j'ai fait le calcul temps non facturé à court terme vs coût en mode clé en main. Mais comme tu dis j'ai l'impression que c'est une stratégie court terme car ça nous dépanne, mais je ne vois aucune offre vraiment cohérente.
Pour une intégration continue à faible volume (ce qui colle à l'offre à 70$), je vois plutôt une mini équipe de développement, et dans ce cas 70$ c'est cher.
Bon en fait c'est plus grave que prévu. On a dû passer sur l'offre à 249$ pour que ce soit fluide au quotidien. Ça a permis de comprendre aussi un peu plus que c'était une bonne idée de migrer. L'interface de gestion est médiocre, les factures générées incompréhensible…
Ça accélère notre projet de migration vers concourse. On vous en redit plus dans quelques semaines.
Travis a « gagné » - À court terme. […] on va passer sur une solution alternative dès qu'on peut.
A court terme peut-être, mais si tu fais durer le "dès qu'on peut" tu leur donneras raison…
Peut-être que vous avez des trucs très complexes, mais perso j'essaye d'avoir le plus de choses possibles dans le code source pour pouvoir justement passer d'un hébergeur à un autre sans que ça dure longtemps (et même si tu passes en auto-hébergement, ça vaut le coup de faire pour au cas où pic de charge etc).
Non on n'a pas de trucs super complexes mais plutôt un problème de bande passante : compte-tenu des projets en cours, on a tout intérêt à dépenser 70$/mois quelques temps avant de basculer.
D'ailleurs, c'est pour ça (pb de bande passante) que j'ai publié 2 opportunités récemment sur LinuxFR :
Au passage, 10000 crédits ça n'est pas parlant pour de l'intégration continue. Il faut déjà les convertir en minutes. Et compte-tenu de l'approche jusqu'à présent, il n'était pas évident de savoir à quoi s'attendre.
Pour savoir à quoi cela correspond, cela nécessite de mener des investigations pour savoir "ce qu'on consomme", c'est pas arrivé en mode "on vous prévient d'avance pour que vous anticipiez".
Aujourd'hui on est devenu client. Travis a « gagné » - À court terme. Je mets des guillemets parce qu'on était déjà prêt à passer sur une offre payante mais qu'ils ne proposaient rien de compatible avec nos besoins.
Mais c'est une victoire à court terme car compte-tenu de la manière de faire, et malgré nos échanges avec le service commercial, on va passer sur une solution alternative dès qu'on peut.
Sans doute. Dans l'historique de notre messagerie interne on était bloqué le 23/11. Je ne sais pas précisément quand le mail a été envoyé mais je me souviens bien des discussions en interne où chacun ne comprenait pas de manière explicite / identique / limpide comment on était impactés.
Autant Travis n'est pas responsable de tout (à commencer par fournir gratuitement un service utilisé par une entreprise - si tu ne paies pas tu ne peux pas t'attendre à avoir des garanties), autant ils n'ont pas communiqué de manière claire sur le changement qui s'opérait.
S'acoquiner avec une boîte en mode SAAS c'est une stratégie à l'encontre de la liberté et de l'indépendance.
Sans jugement, ce n'est pas le cas avec github et travis ?
Github : plus ou moins. Github te donne accès à une communauté à laquelle tu n'as pas accès autrement. Techniquement, c'est du git, on est capable + ou - facilement de se passer de leurs services si nécessaire. Le point important de Github c'est que c'est un réseau social (au sens premier du terme) et dont il est difficile de se passer dans un projet libre qui est en phase d'acquisition de notoriété / communauté.
Travis : on l'a choisi par confort : c'était intégré dans github donc pour caricaturer : "on a écrit quelques fichiers Yaml et puis voilà". Ça serait une erreur de rester sur cette plateforme aujourd'hui compte-tenu de son changement de stratégie et des alternatives possibles. On a par ailleurs des process d'intégration continue qui tournent ailleurs, par exemple la génération d'images docker qui est gérée via un Jenkins auto-hébergé.
Nous sommes directement concernés par l'évolution du service que présente ici Zenitram. Nous avons eu la même analyse : non, Travis CI n'est pas "gratuit pour les logiciels libres".
Qu'ils gagnent leur vie n'est pas un problème - le développement et l'exploitation d'infrastructure ont un coût même s'il s'agit de logiciel libre - mais les conditions ne sont pas claires et pas cohérentes.
On a fait les frais de cette offre qui n'est plus vraiment gratuite. Ce n'est pas fondamentalement grave dans notre cas : on est une boîte, on a de l'argent - d'ailleurs on a cherché à devenir client mais Travis CI n'avait aucune offre intéressante pour nos besoins ; mais le fait est : la démarche n'est pas claire, la condition "logiciel libre" n'est pas complète et ce n'est pas explicite. Par ailleurs - et je trouve ça plus grave, il a fallu qu'on arrive dans une situation où "notre CI ne tournait plus" pour comprendre que les conditions avaient changé de sorte que nous avions consommé notre quota et plus de CI pendant potentiellement 2 semaines.
Encore une fois, le problème n'est pas tant un problème d'argent qu'un problème de communication : en tant que dirigeant d'entreprise, je préfère payer 70$/mois quitte a prévoir une migration plutôt que de me retrouver face à une situation inattendue : vous avez brûlé tous vos crédits de CI "logiciel libre", on ne fait plus rien tourner mais à aucune moment on ne vous a prévenu clairement que ce serait le cas.
Le bon côté des choses, c'est que ça simplifie la prise de décision :)
Je parle en tant que dirigeant d'entreprise. On développe Tracim en utilisant Github. On a mis en place historiquement l'intégration continue en s'appuyant sur Travis CI gratuitement. Au bout d'un moment, on a voulu plus de puissance pour notre CI, on a donc regardé les offres proposées. À l'époque, ça commençait autour de 200$/mois et après discussion avec l'équipe commerciale, on n'allait pas gagner en performance parce qu'on aurait moins de coeurs dispo (un coeur dédié, mais pas de parallélisation possible).
Récemment ça a changé. On s'est posé la question de passer sur leur offre payante. On a testé. Pas mieux que gratuit. Puis est arrivée la démarche évoquée par Zenitram : le gratuit qui ne le devient plus tant que ça.
Quitte à dépenser de l'argent pour la CI, la décision qu'on a prise :
chercher une solution libre qu'on va implémenter en auto-hébergé
passage sur l'offre payante en attendant pour ne pas se trouver bloqué.
L'intégration continue Github ou Gitlab, le problème c'est que ça n'est pas libre (gitlab en partie, mais dès qu'on paie, on passe sur du propriétaire, il me semble - donc on n'a pas de frontière claire). S'acoquiner avec une boîte en mode SAAS c'est une stratégie à l'encontre de la liberté et de l'indépendance.
On a évalué les solutions Travis CI, Buildbot, Concourse, Drone, Github Action, GOCD, Gitlab CI et Jenkins et au final il me semble que c'est Concourse qui est la solution retenue… Seb, Raph, Philippe ou Guénael pourront compléter s'ils passent par là…
D'ailleurs ça vaudrait peut-être le coup de partager ici le fruit de notre réflexion…
le CEO, fondateur de la boite dans les années 80, est plutôt opposé au concept car il pense que l'interaction entre les gens est importante pour les échanges d'idées, toussa
De mon côté, compte-tenu de mon expérience professionnel en tant que collaborateur de télétravailleurs, en tant que télétravailleur moi-même et désormais en tant que dirigeant d'entreprise animateur d'équipe, je suis convaincu que
l'innovation est plus forte en présentiel
l'esprit et la cohésion d'équipe à distance c'est plus compliqué, en tout cas pour certaines personnes (dit autrement : certains sont + câblés pour le télétravail que d'autres).
Au final, ça dépend des gens. (réponse de Normand;)
J'ai bien compris ; ce que j'évoque c'est le choix de ta boîte de remplacer ton poste de travail par un bureau virtuel…
Alors que comme tu le dis tes outils c'est un poste de travail avec les logiciels que tu utilises.
La différence entre le travail en présentiel et à distance c'est uniquement le "tuyau entre ton ordinateur et le lieu de stockage ; c'est ce tuyau qu'il faut adapter et c'est ce que ta boîte n'a pas fait exactement puisqu'ils ont aussi remplacé le terminal (en mettant un bureau virtuel au lieu de ton bureau "Windows").
Et c'est de là que vient le problème à mon sens, pas de l'inanité des outils dans le cloud.
Le vrai problème que tu évoques n'est pas lié aux solutions de travail « dans le cloud » ; le vrai problème est de mettre en place des outils différents pour travailler en présentiel et à distance.
C'est quoi la différence ?
A priori on ne parle pas ici d'un travail d'itinérant qui n'opère pas sur les même tâches lorsqu'il est à distance mais de faire le même travail en présentiel ou en télétravail.
Il y a bien sûr des outils complémentaires nécessaires pour travailler à distance - le téléphone, la visioconférence ou la messagerie instantanée par exemple - mais les outils du quotidien doivent devraient rester les même. S'ils ne sont pas adaptés au travail à distance, pourquoi le seraient-ils pour travailler en présentiel ?
Si la politique de l'organisation est d'avoir tout en interne, je ne vois pas d'alternative plus pertinente qu'un VPN.
Après il faut accepter la charge de travail pour la maintenance, backup, … Tu peux avoir des techniques pro open source mais encore il faudra rapidement quelqu'un de dédié à cette gestion.
Euh… il n'y a pas que les logiciels propriétaires qui sont disponibles sous forme de service. C'est d'ailleurs un gros intérêt des logiciels libres : pouvoir exploiter un service clé-en-main sachant qu'il peut être internalisé à tout moment.
L'exploitation d'un service a un coût qu'il s'agisse de logiciel propriétaire ou libre ; choisir une solution "on premise" ou "hébergée" est orthogonal à la problématique de la licence.
Aujourd'hui, Tracim s'appuie principalement sur un accès authentifié aux ressources qu'il gère. On peut contourner ce mécanisme pour publier des choses publiquement, mais ce n'est pas (encore) le coeur de cible d'utilisation
Dans un contexte associatif où les membres sont les intervenants, il me semble que Tracim répond bien aux différents aspects évoqués :
forum pour les organisations de week-end (en admtettant qu'on puisse en réorganiser un jour…)
La fonctionnalité "discussion" adresse a priori ce besoin. Une manière de faire serait de :
créer un espace "open" dans tracim pour l'événement (open = que chaque utilisateur peut rejoindre sur simple demande)
dans cet espace, les utilisateurs Tracim pourront lancer des discussions puis en gérer le statut.
la description de l'espace pourra mettre en relief dès le début la date de l'événement, sa description, un lien vers les principaux documents, éventuellement un agenda partagé, etc.
partage de documents pour les fiches d'inscriptions, les compte rendus de réunion, les factures…
Un espace à disposition de tous les membres de l'association pourra centraliser les documents partagés et modèles de documents comme la fiche d'inscription.
les membres du CA ou du bureau auront un rôle de contributeur ou gestionnaire (création de document, modifications, organisation)
les membres de l'association prendront un rôle "lecteur" pour récupérer les documents.
Concernant les factures, un espace confidentiel permettra de stocker les documents ; chaque facture pourra être partagée individuellement à l'aide d'un lien de partage personnalisé (on saisit l'email et un lien est généré pour l'utilisateur et un email est envoyé. Ce lien peut être protégé par mot de passe le cas échéant)
agenda de l'asso
la fonctionnalité d'agenda de Tracim permet de réaliser ça. On pourra avoir un agenda par espace partagé, ce qui permet d'avoir un agenda global, un agenda par projet ou par événement. les utilisateurs pourront accéder soit à chaque agenda séparément, soit à une vue globale agrégeant tous les agendas.
Parmi les nouveautés récentes (non encore présentées dans les dépêches LinuxFR) :
le rafraîchissement en temps réel sur les notes, commentaires et fils de discussion
le mur de notifications qui permet d'identifier les nouveautés
la possibilité de mentionner les personnes dans les notes et commentaires
la possibilité de créer des espaces confidentiels (invisible aux personnes non invitées), sur demande (on peut demander l'accès et un gestionnaire valide/invalide la demande) et ouverts (on peut accéder à l'espace sur simple clic ou en sortir si on n'est pas intéressé)
Dans ce qui arrive :
un fil d'actualité par espace et global
un moteur de recherche multi-critères facile d'utilisation et intuitif
Et ce dont je n'ai pas parlé mais qui fait aussi la différence : moteur de recherche qui peut indexer le contenu des documents, interface responsive, api rest intégrale, intégration libreoffice online ou collabora, galerie photo, …
[^] # Re: Ben non
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Comment se faire justice soi-même ?. Évalué à 10.
Qu'on aime ou pas Zenitram il est resté factuel. Et je le rejoins : la justice ne s'applique pas sur la base d'émotions mais de faits.
Pour évaluer un litige, il faut avoir la version des deux parties sinon comment avoir un avis objectif ?
Zenitram ne dit pas que ton ex employeur a raison et que tu es responsable de ce qui t'es arrivé mais que si tu as présenté ton dossier comme tu viens de nous le présenter, il n'est pas étonné que la justice n'ait pas tranché en ta faveur.
La justice ce n'est pas le bien contre le mal mais la présomption d'innocence et le respect des règles établies (la loi) ou la sanction. Ça s'appuie sur des faits établis et prouvés.
Si tu es victime de viol mais que tu n'as strictement aucune preuve, ton agresseur ne sera très probablement pas condamné. Est-ce que c'est juste par rapport à la réalité des faits ? Probablement que non. Est-ce que c'est juste par rapport à la meilleure manière d'appliquer la loi : je pense que oui. Malheureusement.
[^] # Re: L'open source tant qu'il y a besoin de se faire connaître, mais après...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal mapbox n'est plus libre, vive maplibre. Évalué à 8.
Parfois c'est vrai et parfois non. Il y a des marchés qui sont tellement corrompus que tu ne peux pas y aller / y rester si tu respectes les règles légales et l'éthique. La corruption, le lobbying, la concurrence déloyale, l'espionnage industriel, ce n'est pas juste dans les livres.
Une entreprise n'a pas vocation à changer les règles du jeu mais à assurer sa viabilité économique. Si tu veux changer les règles du jeu, il faut faire de la politique.
Ça serait idéal ; mais regarde : le gouvernement a publié un référentiel général d'interopérabilité et il est le premier à ne pas le respecter. Pourquoi attendre d'une entreprise qu'elle fasse mieux ?
Ce que tu n'as pas compris, c'est que MapBox a choisi de mettre en place une stratégie s'appuyant sur du logiciel libre pour différentes raisons. Que cette stratégie ne répond pas à ses attentes et qu'ils changent. Il n'est pas question d'interdire de faire quoi que ce soit à qui que ce soit : c'est juste un changement de stratégie.
Le fait de dire "ils ont fait exprès de choisir une stratégie en s'appuyant sur du libre pour gagner de la notoriété et maintenant qu'ils ont cette notoriété ils arrêtent" ce n'est pas un fait. En tout cas je n'ai rien lu qui aille dans ce sens. C'est une hypothèse qui se tient, et qui ne se tient ni plus ni moins que "ils ont choisi une stratégie en s'appuyant sur du libre pour développer un bien commun tout en gagnant correctement leur vie et ça ne répond pas à leurs attentes et ils changent donc de stratégie". La différence, c'est que dans un cas c'est un changement de stratégie à dessein tandis que dans l'autre cas c'est du pragmatisme de gestion d'entreprise.
Par exemple, si tu as une rentabilité 2 fois moindre que tes concurrents, c'est une chose à prendre en compte, et c'est une position qui est difficilement tenable sur le long terme.
Le libre ne fait pas chier ; le libre implique des choses et comme tu le dis ça n'empêche pas d'interdire. Je ne vois à aucun endroit MapBox dire "le libre nous fait chier, on arrête" mais "la nouvelle version ne sera pas en libre". C'est un choix stratégique. Point.
Là on est 100% d'accord (sauf si ta cible c'est MapBox. Parce qu'à ma connaissance, il n'y a pas de + contributeur dans le domaine de la cartographie, donc tirer sur MapBox, c'est contre-productif).
Il y a un sacré travail sur le sujet, auprès des entreprises utilisatrices, auprès des politiques … et auprès des libristes eux-même. On peut faire un sondage pour savoir combien de libristes préfèrent Chrome à Firefox par exemple. Ou qui préfèrent acheter chez Amazon que ailleurs. Chacun a de bonnes raisons de favoriser ceux qui devraient être moins bien vus.
Je m'intéresse au bankable aussi. Ce n'est pas la majorité des cas (le nombre de pro techno google ou pro amazon dans les colonnes de LinuxFR est symptômatique de cela : la libération du bankable n'est pas la priorité absolue, même pour les libristes)
Je suis bien d'accord avec toi. Et je ne vois pas vraiment de solution, en particulier parce que « les libristes » eux-même ont un positionnement qui est discutable par rapport à cela. (et je ne parle pas des visiteurs de nos stands Tracim sur les événements qui critiquent notre position d'entreprise ou le mode de gouvernance d'Algoo sous prétexte qu'on devrait être une SCOP voire une association de bénévoles pour vraiment respecter le libre)
[^] # Re: L'open source tant qu'il y a besoin de se faire connaître, mais après...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal mapbox n'est plus libre, vive maplibre. Évalué à 4.
On peut voir "du dev gratos" comme de la mutualisation de compétences.
On peut voir du "dev gratos" comme un échange de bons procédés (mise à disposition de travail de r&d gratuitement contre retours).
Il me semblait avoir lu qqpart que c'était lié au fait que de gros acteurs exploitaient sans rétribution et que économiquement ce n'est simplement pas tenable.
Ce dernier point me semble t'il est tout à fait compréhensible (y compris pour arrêter de faire du libre), et est indépendant de "se faire une communauté sur le dos du libre et ensuite fermer le code".
Par ailleurs il me semble que mapbox est contributeur de nombreux modules libres disponible indépendamment de leur solution.
[^] # Re: Perplexe
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Développer une interface web avec le toolkit Atlas (1/2). Évalué à 5.
Je trouve cette clarification très importante et intéressante. Je vois du coup le framework comme un outil de programmation rapide d'interface utilisateur.
Dans le cas du développement d'un outil de gestion, du coup, j'aurais tendance à le comparer dans une certaine mesure à Django que j'utilise personnellement pour dév des outils perso via quasi-exclusivement Django Admin (l'interface d'admin de Django).
Concrètement, dans quel cas conseilles-tu d'utiliser le framework ? Pour développer un nouvel outil ? Proposer une interface utilisateur à un outil ou du code existant sous forme de CLI ou de lib ?
[^] # Re: oh oui, une dépêche sur Tracim
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Quelques logiciels libres pour sécuriser le travail collaboratif en ligne . Évalué à 4.
Je note :) Yen a une prévue pour la rentrée… Avec pas mal de nouveautés.
[^] # Re: Cette dépêche mélange un peu de tout ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Quelques logiciels libres pour sécuriser le travail collaboratif en ligne . Évalué à 6.
Oui tu as complètement raison :)
Pour moi c'est la notion "c'est sécurisé" qui est floue. Par exemple si tu veux déployer sur une infrastructure en laquelle tu n'as pas totalement confiance, cryptpad me semble une bonne solution. Si en revanche ton infrastructure fait partie du "périmètre de confiance", Tracim répondra et proposera un périmètre fonctionnel plus large sur des sujets qui ne sont pas adressables (ou très difficilement) avec un chiffrement de bout-en-bout. Par exemple implémenter un moteur de recherche nécessite d'indexer le contenu (donc d'y avoir accès). Avec un chiffrement de bout-en-bout c'est relativement complexe, a fortiori dans une application web.
Un autre point important pour les notions de sécurité sur une application en ligne : il y a la sécurité "by design" dans le produit (exemples : chiffrement de bout en bout, modèles de gestion des droits d'accès, méthode de développement, etc) mais également la manière dont est déployé l'outil. Et enfin - et surtout - la manière dont est utilisé l'outil.
Pour le reste, je suis d'accord avec tes réponses. Les deux points clé de mon commentaire sont vraiment la reformulation du titre (qui est très bien comme tu viens de le faire) et la notion de sécurité qui mérite d'être clarifiée sans quoi elle apporte peu.
# Cette dépêche mélange un peu de tout ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Quelques logiciels libres pour sécuriser le travail collaboratif en ligne . Évalué à 10.
Il est question de "travail collaboratif sécurisé", ce qui fondamentalement ne veut pas dire grand chose.
Du coup comme cette terminologie n'est pas explicitée, la dépêche ressemble à une liste plus ou moins cohérente de logiciels.
Par exemple on trouve libreoffice online en alternative à cryptpad alors que l'un est un éditeur de documents bureautique en ligne et l'autre une solution chiffrée de bout en bout.
Il n'est pas fait mention de Etherpad ou Ethercalc non plus. Est-ce pour des raisons de sécurité ? Si oui, pourquoi libreoffice apparaît (à ma connaissance libreoffice online ne fait pas de chiffrement) ?
Il est également évoqué NextCloud et onlyoffice groups par exemple mais pas Tracim.
Au niveau visioconférence les solutions sont elles équivalentes ? Quelles sont les possibilités de chacune d'un point de vue sécurité ? Et d'un point de vue collaboration ?
La démarche est intéressante mais finalement le manque d'objectivité qui était le reproche principal fait à MariePa est aussi présent dans cette dépêche. Idem pour le flou autour des solutions évoquées.
Je comprends qu'une telle dépêche ne puisse avoir la prétention de présenter toutes les solutions existantes, mais là on mélange 2 thématiques (la sécurité et les solutions de travail en équipe) sans expliquer la démarche, les critères pour "définir" quelles solutions sont pertinentes.
Par exemple en tant que leader de Tracim, j'aurais tendance à me dire "ah ben dommage Tracim n'apparaît pas dans cette liste, c'est contre productif pour notre logiciel". Mais en même temps Tracim n'est pas une solution orientée chiffrement de bout en bout. Mais en même temps c'est le cas de plusieurs solutions évoquées - si on parle de Libreoffice ou Onlyoffice groups, Tracim me semble pertinent. Si on parle de chiffrement de bout en bout ça ne l'est pas (cela veut il dire que Tracim n'est pas sécurisé ? Non pas nécessairement).
Il me semble que le titre est trompeur et qu'il serait plus approprié sous une forme du type : "quelques solutions libres permettant de collaborer en ligne avec un niveau de confidentialité potentiellement fort". (Je reconnais que cette formulation un peu longue;)
Enfin dernier point lié au titre, on s'attendrait potentiellement à des conseils sur comment sécuriser ces outils, mais cf n'est pas le cas non plus. Jitsi meet par exemple peut être utilisé avec différents niveaux de confidentialité, liés à la manière de l'utiliser mais également à la manière de le configurer.
[^] # Re: Pourquoi le choix GAFAM ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 3.
Cette phrase ne laisse pas présager d'une grande ouverture d'esprit, d'où mon commentaire.
Cette phrase aussi, d'ailleurs.
[^] # Re: Pourquoi le choix GAFAM ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 5.
Les personnes incapables de compromis sont souvent malheureuses. Je croise les doigts pour toi.
[^] # Re: Sans entrer dans le détail ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 2.
Pour les 249$ j'ai fait le calcul temps non facturé à court terme vs coût en mode clé en main. Mais comme tu dis j'ai l'impression que c'est une stratégie court terme car ça nous dépanne, mais je ne vois aucune offre vraiment cohérente.
Pour une intégration continue à faible volume (ce qui colle à l'offre à 70$), je vois plutôt une mini équipe de développement, et dans ce cas 70$ c'est cher.
[^] # Re: Sans entrer dans le détail ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 3.
Bon en fait c'est plus grave que prévu. On a dû passer sur l'offre à 249$ pour que ce soit fluide au quotidien. Ça a permis de comprendre aussi un peu plus que c'était une bonne idée de migrer. L'interface de gestion est médiocre, les factures générées incompréhensible…
Ça accélère notre projet de migration vers concourse. On vous en redit plus dans quelques semaines.
[^] # Re: Sans entrer dans le détail ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 4.
Non on n'a pas de trucs super complexes mais plutôt un problème de bande passante : compte-tenu des projets en cours, on a tout intérêt à dépenser 70$/mois quelques temps avant de basculer.
D'ailleurs, c'est pour ça (pb de bande passante) que j'ai publié 2 opportunités récemment sur LinuxFR :
[^] # Re: Sans entrer dans le détail ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 4.
Au passage, 10000 crédits ça n'est pas parlant pour de l'intégration continue. Il faut déjà les convertir en minutes. Et compte-tenu de l'approche jusqu'à présent, il n'était pas évident de savoir à quoi s'attendre.
Pour savoir à quoi cela correspond, cela nécessite de mener des investigations pour savoir "ce qu'on consomme", c'est pas arrivé en mode "on vous prévient d'avance pour que vous anticipiez".
Aujourd'hui on est devenu client. Travis a « gagné » - À court terme. Je mets des guillemets parce qu'on était déjà prêt à passer sur une offre payante mais qu'ils ne proposaient rien de compatible avec nos besoins.
Mais c'est une victoire à court terme car compte-tenu de la manière de faire, et malgré nos échanges avec le service commercial, on va passer sur une solution alternative dès qu'on peut.
[^] # Re: Sans entrer dans le détail ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 5.
Sans doute. Dans l'historique de notre messagerie interne on était bloqué le 23/11. Je ne sais pas précisément quand le mail a été envoyé mais je me souviens bien des discussions en interne où chacun ne comprenait pas de manière explicite / identique / limpide comment on était impactés.
Autant Travis n'est pas responsable de tout (à commencer par fournir gratuitement un service utilisé par une entreprise - si tu ne paies pas tu ne peux pas t'attendre à avoir des garanties), autant ils n'ont pas communiqué de manière claire sur le changement qui s'opérait.
[^] # Re: Ça s'entend...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 5.
Github : plus ou moins. Github te donne accès à une communauté à laquelle tu n'as pas accès autrement. Techniquement, c'est du git, on est capable + ou - facilement de se passer de leurs services si nécessaire. Le point important de Github c'est que c'est un réseau social (au sens premier du terme) et dont il est difficile de se passer dans un projet libre qui est en phase d'acquisition de notoriété / communauté.
Travis : on l'a choisi par confort : c'était intégré dans github donc pour caricaturer : "on a écrit quelques fichiers Yaml et puis voilà". Ça serait une erreur de rester sur cette plateforme aujourd'hui compte-tenu de son changement de stratégie et des alternatives possibles. On a par ailleurs des process d'intégration continue qui tournent ailleurs, par exemple la génération d'images docker qui est gérée via un Jenkins auto-hébergé.
# Sans entrer dans le détail ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 10.
Nous sommes directement concernés par l'évolution du service que présente ici Zenitram. Nous avons eu la même analyse : non, Travis CI n'est pas "gratuit pour les logiciels libres".
Qu'ils gagnent leur vie n'est pas un problème - le développement et l'exploitation d'infrastructure ont un coût même s'il s'agit de logiciel libre - mais les conditions ne sont pas claires et pas cohérentes.
On a fait les frais de cette offre qui n'est plus vraiment gratuite. Ce n'est pas fondamentalement grave dans notre cas : on est une boîte, on a de l'argent - d'ailleurs on a cherché à devenir client mais Travis CI n'avait aucune offre intéressante pour nos besoins ; mais le fait est : la démarche n'est pas claire, la condition "logiciel libre" n'est pas complète et ce n'est pas explicite. Par ailleurs - et je trouve ça plus grave, il a fallu qu'on arrive dans une situation où "notre CI ne tournait plus" pour comprendre que les conditions avaient changé de sorte que nous avions consommé notre quota et plus de CI pendant potentiellement 2 semaines.
Encore une fois, le problème n'est pas tant un problème d'argent qu'un problème de communication : en tant que dirigeant d'entreprise, je préfère payer 70$/mois quitte a prévoir une migration plutôt que de me retrouver face à une situation inattendue : vous avez brûlé tous vos crédits de CI "logiciel libre", on ne fait plus rien tourner mais à aucune moment on ne vous a prévenu clairement que ce serait le cas.
Le bon côté des choses, c'est que ça simplifie la prise de décision :)
[^] # Re: Ça s'entend...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Travis CI : aimer le libre (pour se faire connaître), mais pas/plus trop. Évalué à 10.
Je parle en tant que dirigeant d'entreprise. On développe Tracim en utilisant Github. On a mis en place historiquement l'intégration continue en s'appuyant sur Travis CI gratuitement. Au bout d'un moment, on a voulu plus de puissance pour notre CI, on a donc regardé les offres proposées. À l'époque, ça commençait autour de 200$/mois et après discussion avec l'équipe commerciale, on n'allait pas gagner en performance parce qu'on aurait moins de coeurs dispo (un coeur dédié, mais pas de parallélisation possible).
Récemment ça a changé. On s'est posé la question de passer sur leur offre payante. On a testé. Pas mieux que gratuit. Puis est arrivée la démarche évoquée par Zenitram : le gratuit qui ne le devient plus tant que ça.
Quitte à dépenser de l'argent pour la CI, la décision qu'on a prise :
L'intégration continue Github ou Gitlab, le problème c'est que ça n'est pas libre (gitlab en partie, mais dès qu'on paie, on passe sur du propriétaire, il me semble - donc on n'a pas de frontière claire). S'acoquiner avec une boîte en mode SAAS c'est une stratégie à l'encontre de la liberté et de l'indépendance.
On a évalué les solutions Travis CI, Buildbot, Concourse, Drone, Github Action, GOCD, Gitlab CI et Jenkins et au final il me semble que c'est Concourse qui est la solution retenue… Seb, Raph, Philippe ou Guénael pourront compléter s'ils passent par là…
D'ailleurs ça vaudrait peut-être le coup de partager ici le fruit de notre réflexion…
[^] # Re: ça peut aussi marcher
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 6.
Et visiblement ce n'est pas le seul
De mon côté, compte-tenu de mon expérience professionnel en tant que collaborateur de télétravailleurs, en tant que télétravailleur moi-même et désormais en tant que
dirigeant d'entrepriseanimateur d'équipe, je suis convaincu queAu final, ça dépend des gens. (réponse de Normand;)
[^] # Re: Le sujet « de l’inanité des solutions de travail in-da-cloud » est une erreur
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 4.
J'ai bien compris ; ce que j'évoque c'est le choix de ta boîte de remplacer ton poste de travail par un bureau virtuel…
Alors que comme tu le dis tes outils c'est un poste de travail avec les logiciels que tu utilises.
La différence entre le travail en présentiel et à distance c'est uniquement le "tuyau entre ton ordinateur et le lieu de stockage ; c'est ce tuyau qu'il faut adapter et c'est ce que ta boîte n'a pas fait exactement puisqu'ils ont aussi remplacé le terminal (en mettant un bureau virtuel au lieu de ton bureau "Windows").
Et c'est de là que vient le problème à mon sens, pas de l'inanité des outils dans le cloud.
# Le sujet « de l’inanité des solutions de travail in-da-cloud » est une erreur
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 5.
Le vrai problème que tu évoques n'est pas lié aux solutions de travail « dans le cloud » ; le vrai problème est de mettre en place des outils différents pour travailler en présentiel et à distance.
C'est quoi la différence ?
A priori on ne parle pas ici d'un travail d'itinérant qui n'opère pas sur les même tâches lorsqu'il est à distance mais de faire le même travail en présentiel ou en télétravail.
Il y a bien sûr des outils complémentaires nécessaires pour travailler à distance - le téléphone, la visioconférence ou la messagerie instantanée par exemple - mais les outils du quotidien
doiventdevraient rester les même. S'ils ne sont pas adaptés au travail à distance, pourquoi le seraient-ils pour travailler en présentiel ?Si la politique de l'organisation est d'avoir tout en interne, je ne vois pas d'alternative plus pertinente qu'un VPN.
[^] # Re: dans mon labo …
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal De l’inanité des solutions de travail in-da-cloud. Évalué à 7.
Euh… il n'y a pas que les logiciels propriétaires qui sont disponibles sous forme de service. C'est d'ailleurs un gros intérêt des logiciels libres : pouvoir exploiter un service clé-en-main sachant qu'il peut être internalisé à tout moment.
L'exploitation d'un service a un coût qu'il s'agisse de logiciel propriétaire ou libre ; choisir une solution "on premise" ou "hébergée" est orthogonal à la problématique de la licence.
[^] # Re: La réciproque du test de Turing ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à 6.
Ne s'agirait il pas ici d'une extraordinaire IA… pourvue d'une forme rare de buffer overflow aléatoire ?
[^] # Re: Discourse SSO ou Tracim
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Appli web forum, agenda et partage de fichiers. Évalué à 2.
Dans ce cas, je pense que Tracim est clairement adapté. Si tu pars dans cette direction, je suis preneur de tes retours sur l'utilisation de Tracim.
[^] # Re: Discourse SSO ou Tracim
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Appli web forum, agenda et partage de fichiers. Évalué à 2.
Je complète avec le lien vers la démonstration en ligne de Tracim.
[^] # Re: Discourse SSO ou Tracim
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Appli web forum, agenda et partage de fichiers. Évalué à 3.
Aujourd'hui, Tracim s'appuie principalement sur un accès authentifié aux ressources qu'il gère. On peut contourner ce mécanisme pour publier des choses publiquement, mais ce n'est pas (encore) le coeur de cible d'utilisation
Dans un contexte associatif où les membres sont les intervenants, il me semble que Tracim répond bien aux différents aspects évoqués :
La fonctionnalité "discussion" adresse a priori ce besoin. Une manière de faire serait de :
Concernant les factures, un espace confidentiel permettra de stocker les documents ; chaque facture pourra être partagée individuellement à l'aide d'un lien de partage personnalisé (on saisit l'email et un lien est généré pour l'utilisateur et un email est envoyé. Ce lien peut être protégé par mot de passe le cas échéant)
la fonctionnalité d'agenda de Tracim permet de réaliser ça. On pourra avoir un agenda par espace partagé, ce qui permet d'avoir un agenda global, un agenda par projet ou par événement. les utilisateurs pourront accéder soit à chaque agenda séparément, soit à une vue globale agrégeant tous les agendas.
Parmi les nouveautés récentes (non encore présentées dans les dépêches LinuxFR) :
Dans ce qui arrive :
Et ce dont je n'ai pas parlé mais qui fait aussi la différence : moteur de recherche qui peut indexer le contenu des documents, interface responsive, api rest intégrale, intégration libreoffice online ou collabora, galerie photo, …