L’association IndieHosters héberge, installe, maintient et met à disposition des ressources numériques libres et open‑source depuis 2015, et fait partie des membres cofondateurs du collectif CHATONS.
En mars 2020, alors que toute la France s’est retrouvée confinée à cause de l’épidémie de Covid‑19, les membres du collectif se sont demandés ce qu’ils pouvaient faire pour contribuer à atténuer la crise inévitable pour les tissus coopératifs et associatifs, constatant par ailleurs que les particuliers comme les entreprises se sont mis massivement à recourir à des solutions leur permettant de travailler en ligne.
C’est comme ça qu’est né le projet Liiibre, qui propose un espace sécurisé (via un SSO) donnant accès à un ensemble d’outils libres pour collaborer en ligne dans une seule interface unifiée : stockage de données, agendas partagés (Nextcloud), édition de documents (OnlyOffice*), messagerie instantanée (RocketChat) et visioconférence (Jitsi Meet).
L’objectif principal est de proposer une solution professionnelle et fiable aux entreprises et associations : Liiibre est donc destiné aux organisations allant d’une trentaine à plusieurs centaines de personnes qui ne souhaitent pas héberger elles‑mêmes leurs outils. C’est pourquoi le collectif a choisi Kubernetes, une infrastructure technique qui permet de passer à l’échelle et de déployer rapidement de nouveaux espaces de travail pour de grands groupes. Mais comme IndieHosters reste fidèle à ses engagements d’origine, il reste possible de bénéficier d’une solution mutualisée pour les groupes plus petits.
Plus qu’un simple accès aux outils, Liiibre permet également de bénéficier d’un accompagnement sur mesure, de la simple prise en main à la sensibilisation aux pratiques collaboratives.
Et enfin, le modèle économique de Liiibre est basé sur celui des communs : il n’y a ni client, ni prestataire, ni produit, mais des ressources dont la communauté prend soin collectivement et qui sont accessibles aux contributeurs et aux contributrices s’attachant à les rendre pérennes. Les contributions monétaires ne sont donc pas la seule façon de pouvoir soutenir et utiliser Liiibre, il est également possible de signer un contrat de réciprocité pour contribuer autrement (rédiger de la documentation, s’investir dans l’équipe technique, faire de l’accompagnement, etc.).
Alors si ça vous dit d’essayer, ou si vous avez des questions, n’hésitez pas…
(*) Une question au fond de la classe : « Pourquoi OnlyOffice et pas Collabora ? »
Excellente question ! Les deux ont leurs avantages et inconvénients. Nous avons tranché pour OnlyOffice dans la version publique mais Collabora peut être installé à la place sur demande. Sur le principe nous préférons Collabora (libre), mais chez OnlyOffice (open‑source) la performance et l’interface utilisateur nous semblent bien meilleures pour le moment. Ça pourra évoluer dans le temps.
Aller plus loin
- Site officiel (766 clics)
- Article de Framasoft (107 clics)
# "destiné aux organisations allant d’une trentaine"
Posté par Jona . Évalué à 4.
Chouette projet !
Pourquoi est-ce destiné aux organisations à partir d'une trentaine de personnes ?
Qu'est-ce qui est recommandé alors pour une organisation plus petite ?
Merci !
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par Maïa Dereva (site web personnel) . Évalué à 3.
Merci Jona pour ce retour :)
Compte-tenu de l'infrastructure technique choisie, ça ne serait pas très écologique de déployer un espace complet pour chaque petit groupe. Mais comme indiqué dans l'article, une instance mutualisée a été mise en place pour répondre aux demandes de groupes plus petits. Du point de vue utilisateur, ça ne change pas grand chose, à part l'identité visuelle/le nom de domaine qui ne peuvent pas être personnalisés du coup.
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par Maïa Dereva (site web personnel) . Évalué à 2.
J'ajoute que rien n'empêche un petit groupe d'opter quand même pour sa propre instance de Liiibre, mais sur le plan économique ça devient moins intéressant, le tarif "plancher" étant celui à 30 utilisateurs pour que le modèle économique soit pérenne. La limite n'est donc pas technique, c'est un choix fait par l'équipe (notamment pour rester cohérent sur le plan écologique), et qui pourra être rediscuté collectivement en fonction des retours des contributeurs.
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par vaceletm (site web personnel) . Évalué à 2.
Pourriez vous préciser les calculs que vous avez fait pour le critère de cohérence écologique ?
Déjà que dans un écosystème de container, la projection budgétaire/économique est complexe à faire (combien de nodes dans mon cluster pour combien de container pour quelle charge), vous avez du encore + vous casser la tête pour mesurer l'empreinte écologique de la solution (notamment sur la justification de la HA pour 30 utilisateurs). Je suis curieux de comprendre la démarche.
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par pierreozoux . Évalué à 10.
Je peux répondre un peu plus techniquement.
Du coup, et il faut que j'écrive dessus, nous avons développé une infra, avec comme variable à optimiser le stress des admins :)
Nous avons donc fait le choix tout en haute dispo.
Et donc, quand on déploie une plateforme Liiibre pour une organisation, Il y a au moins un Nextcloud et un RocketChat.
Le onlyOffice, le jitsi, et le SSO sont mutualisés (à part si vous êtes plusieurs milliers, on peut discuter).
Mais juste Nextcloud et RocketChat:
- Postgres (1 Leader/1 Follower)
- Redis (3 redis, 3 sentinels)
- MongoDB (3 replicas)
- php pour Nextcloud (2)
- web pour Nextcloud (Nginx) (2)
- nodejs pour RocketChat (2)
Pour que tout soit en haute dispo, selon les services, il faut 3 replicas pour MongoDB par exemple, et 2 replicas au moins pour le reste.
Du coup, pour un Liiibre de base, on a 17 containers déjà.
Pour 5 personnes, cela ferait plus de 3 containers par personnes, pas très économe ;)
Voila la raison plus technique :)
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par mornik . Évalué à 4.
Bonsoir,
La partie envoie des notifications aux mobiles de RocketChat, n'est pas libre et passe obligatoirement par leur serveur
A++
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Merci pour cette info !
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par pierreozoux . Évalué à 2.
Cette partie est nouvelle, et on a pas encore statués officiellement de comment on allait faire.
Pour le moment, chaque organisation décide elle même si elle envoie les notifications aux serveurs Rocket ou non. Du coup, les organisations sont libres de choisir.
Après le problème est plus complexe.
Perso, je n'ai pas de notifications sur mon mobile et dans un soucis d'écologie de l'attention, c'est ce que je recommande, j'ai même pas l'appli installé de toute façon, je travaille que devant mon ordi.
Après je peux comprendre que les gens veulent avoir des notifications mobiles.
Dans tous les cas, les notification ordiphones, passent nécessairement par les serveurs google et apple, et le code n'est pas libre. (de ce que je connais, android et apple, qui doit représenter plus de 95% du "marché" de la notification)
Donc la notion même de notification sur mobile n'est pas libre, c'est pas spécialement propre à RocketChat.
RocketChat travaille aussi à chiffrer les notifications e2e.
Et enfin, d'autres part, on envisage de compiler nous même les applications mobiles, et du coup, on s'affranchirait des serveurs RocketChat, mais pas google ni apple.
Bref, c'est un sujet assez nouveau dans la communauté RocketChat, et on a pas encore de décisions claires à ce sujet.
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par Yth (Mastodon) . Évalué à 3. Dernière modification le 02 octobre 2020 à 22:00.
Si j'ai bien suivi, il s'agit d'avoir un pop/bip/weez/floup quand on reçoit un mail sur son mobile ?
C'est parfaitement faisable en dehors de Google (LineageOS sans Gapps d'aucune sorte, même fake), avec de l'IMAP.
En tout cas ÇaMarcheChezMoi(c)(r)tm.
Avec K9-Mail en IMAP, il faut activer l'option super-cachée de non-optimisation de la batterie (paramètres, applis et notifications, options avancées, accès spécifiques des applications, optimisation de la batterie, menu : toutes les applis, chercher K9-Mail, et là, enfin, choisir de ne pas optimiser !).
Et ensuite K9-Mail conserve une connexion IDLE qui va poper une notification directement dès qu'un nouveau mail sera disponible.
Si l'option d'optimisation de la batterie est activée (cas général), les applis sont mise en veille bien plus rapidement et la connexion IDLE est rapidement coupée, K9-mail ne fait même plus sa mise à jour programmée toutes les 30 minutes (par exemple), et il ne se réveillera que quand on lancera l'appli.
De ce côté là, il faut comprendre comment LineageOS fonctionne, mais c'est nettement moins agressif que de l'Android classique avec du Google de partout !
Et on a nos notifications temps réel de nouveaux mails sans passer par Google.
K9-mail a aussi une option bien pratique qui consiste à lui dire de ne rechercher de nouveaux mails que quand la synchro est activée en global dans Android, ce qui n'a grosso modo aucun autre effet quand on n'a pas les Google Apps, avec la synchro Google en arrière-plan, donc on peut très facilement le laisser s'endormir pour ne pas être dérangé quand on ne veut pas être dérangé.
PS: Ça a l'air compliqué mais en fait il n'y a vraiment qu'une seule opération à faire, et c'est utile de savoir où trouver cette option pour, dans l'autre sens, la désactiver si une appli nous casse trop les bonbons et qu'on veut la laisser se rendormir…
PPS: Oui, j'ai conscience que je suis dans une situation pas commune et que non, on ne va pas demander aux gens d'installer LineageOS, mais LineageOS c'est un Android. Et donc avec un truc bloaté par Google, Samsung et Orange à la fois, ça va fonctionner aussi, l'option existe au même endroit et K9-mail va se comporter de la même manière : avoir du push sans utiliser les Google Apps !
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par claudex . Évalué à 3.
Oui, ça marche mais ça consomme beaucoup plus de batterie que les notifications Google et toutes les applications ne permettent pas de s'en passer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par barmic 🦦 . Évalué à 2.
Ça demande à laisser l'appli tourner en arrière plan, ça demande que chaque appli restent activent et maintiennent une connexion,… Côté serveur tu dois maintenir une connexion par client sur ton serveur et potentiellement selon le protocole la migration de serveur doit être bien prévue.
Et ce sont les premiers exemples que je vois rapidement. Donc si tu as veux recevoir tes mails ça va peut être, si tu veux aussi avoir les IM, des notifications météo, ton réseau social favori, etc ça va moins bien se passer. Utiliser un broker c'est clairement une bonne idée quelque soit ce que l'on pense des services apns, firebase et huawei message service.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par Yth (Mastodon) . Évalué à 2.
Ah oui, si tu veux être spammé de notifications, c'est une mauvaise solution, ça va pomper ton réseau donc ta batterie et c'est inefficace.
Encore une fois je suis dans une situation très rare, mais les seules notifications relativement temps réel qui m'intéressent sont les SMS et les mails, et pour ça, avoir une connexion IMAP ouverte quand je le demande (option synchro activée), et de manière générale toutes les applis qui se font flinguer dès qu'elles dorment un peu, ça me convient très bien et c'est plus efficace au bout du compte.
Mais évidemment, si j'avais envie d'avoir sept réseaux sociaux et quatre messageries de chat à la slack, la météo de new-york et tokyo, et mes douze comptes mails exchange, franchement, autant tout laisser aller chez Google, ça y est probablement déjà, et ça sera plus efficace en terme de réseau et de décharge de la batterie. Et le problème de mail IMAP classique passe dans le lot et basta.
Ici je répondais juste sur la possibilité d'avoir les notifications email en temps réel, sans passer par les Gapps.
Yth.
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par barmic 🦦 . Évalué à 3.
Pas vraiment tu réponds à la possibilité d'avoir des notifications dans un contexte où tu ne veux qu'avoir des notifications mails et que tu es prêt à configurer ton téléphone (pour k9mail et pour le laisser tourner en arrière plan). Ton cas d'usage (basique et demandant certaines configurations) ne représentent pas du tout cas le général.
C'est comme si je disais qu'on peut aller au boulot à pied puisque mon boulot est à 5 minutes à pied de chez moi (c'est un exemple fictif), tu serais content de me savoir mais ça n'apporterait pas grand chose à ton contexte à toi.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par barmic 🦦 . Évalué à 2.
En particulier ça ne permet pas de dire aux gens qui utilisent d'autres moyens de transport qu'ils devraient ou pourraient faire autrement. Comme tu semble le faire (dire qu'il n'y a pas besoin des gapps puisque pour ton usage tu n'en a pas besoin).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: "destiné aux organisations allant d’une trentaine"
Posté par Yth (Mastodon) . Évalué à 2.
Je répondais à ça, précisément.
En disant que ça peut fonctionner autrement.
Et je suis certes dans une situation très particulière, mais c'est un paramétrage accessible à tout le monde, et pour toutes les applis pour peu qu'elles aient un fallback en cas d Gapps inaccessibles (par exemple d'autres clients mails que K9 le permettent, comme BlueMail pour faire de l'Exchange, ou encore des applis nettement moins sympa pour un libriste comme Whatsapp ou Slack, j'ai essaimé un ou deux LineageOs autour de moi, avec des usages variés) :
Il y a des inconvénients discutés par ailleurs et indéniables et qui justifient l'existence des API Google et Apple pour gérer et centraliser les notifications push.
Mais désolé, j'indique que ce n'est pas la seule est exclusive possibilité et que si on souhaite uniquement un type de notification (mon cas : uniquement les mails), l'alternative est assez simple (si on arrive à trouver cette foutue option planquée), et valable et termes de performance et d'utilisation de la batterie (une connexion active versus une connexion active, c'est globalement assez similaire).
Et valable pour tout le monde sous Android.
Avec ou sans Gapps.
Dis-moi où je me trompe ?
# Partenariats / contributions à OnlyOffice, RocketChat, NextCloud, Jitsi ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
OnlyOffice et RocketChat sont des logiciels open-core. Les versions que vous intégrez dans Liiibre sont-elles les versions libres ou les versions propriétaire ? Avec un contrat de partenariat/distributeur ?
[^] # Re: Partenariats / contributions à OnlyOffice, RocketChat, NextCloud, Jitsi ?
Posté par unteem . Évalué à 2.
Bonjour,
On intègre bien les versions libres, nous n'hébergeons aucun logiciel propriétaire.
Selon les besoins nous recompilons OnlyOffice qui est sous licence AGPLv3 sans limitations (cela nous nous empêchera pas de payer le support si nous le jugeons nécessaire et d'ainsi contribuer au maintien du projet).
Pour RocketChat les fonctionalités propriétaires sont plus à la marge et nous ne nous les utilisons pas, comme ça c'est réglé :)
Le modèle open-core est clairement un modèle qui peut nous poser des difficultés… On en discutait là: https://forum.chatons.org/t/comment-beneficier-des-fonctionnalites-entreprises-sous-licences-non-libres-tout-en-respectant-la-charte-chatons/1469
# Libre vs OpenSource ?
Posté par freejeff . Évalué à 3.
Où là, c'est glissant. OnlyOffice Community edition est totalement libre, ils utilisent la licence AGPLV3, qui est libre.
Le principal point de clivage est la représentation interne du modèle de document qui est faite avec Office Open XML, ce qui leur assure une très bonne compatibilité avec les documents offices, mais dégrade la compatibilité avec les documents odf.
Ils ont choisi cette représentation, ça leur permet d'aller chercher un autre segment que celui visé par Collabora en permettant de se focaliser sur le passage de MS office vers cloud. Bon microsoft ayant sortie son offre cloud, ils ont aussi de la concurrence, mais pas en Libre, justement.
Après, il est possible que je rate quelque chose dans la distinction que tu as voulu faire, n'hésite pas à préciser en ce cas !
[^] # Re: Libre vs OpenSource ?
Posté par pierreozoux . Évalué à 5.
Alors, libre vs open source, vaste débat.
Selon moi, il y a, disons, 4 dimensions:
- la license
- la philosophie
- l'intention
- la gouvernance
Du point de vue de la license, selon moi, il s'agit de la liberté ultime que celle ci permet.
La liberté ultime pour l'open source, est la liberté d'une entreprise de fermer le code.
Pour le libre, la liberté ultime est pour l'utilisateur que personne n'ait le droit de fermer le code.
En terme de philosophie, encore une fois selon moi, le libre a une portée humaniste, les droits de l'homme et de la femme appliquée au logiciel, alors que l'open source est un moyen efficace de produite du logiciel.
Quand je parle d'intention, je me réfère à debian, qui respecte toujours l'intention de l'auteur.e. Ainsi même si la license est libre, mais que l'intention ne l'est pas, alors debian préfère ne pas inclure le logiciel.
Pour une entreprise capitaliste, l'intention est avant tout le profit.
Pour un individuel comme moi, je sais pas, j'ai pas fait d'analyse encore ;) mais surement un mélange de faire bouger le monde dans le "bon" sens, parce que c'est la "bonne" chose à faire, une partie d'ego je pense aussi, pour le CV peut-être, parce que sur le long terme, c'est plus efficace, ou enfin pour la réputation et la reconnaissance d'IndieHosters.
Et enfin, un truc que je me suis rendu compte dernierement, la gouvernance est aussi très importante, sinon le plus important.
Donc, maintenant, on peut comparer collabora/libreoffice online (lool) et onlyOffice (oo).
Déjà, il y a le format de fichier, et le choix d'odf est plus libre, c'est indéniable.
Ensuite, les 2 ont une anti fonctionnalité (comme windows NT, ironique, non?) qui limite le nombre de connexion, et ça c'est plus open source on peut dire.
OnlyOffice a enlevé une fonctionnalité dans sa version communauté (édition de doc dans l'application mobile), et ça c'est clairement plus open source ;)
En terme de gouvernance, onlyOffice est une entreprise et libre office a une fondation derrière, mais cette fondation est gouvernée par les entreprises comme collabora.
Du coup, lool est un peu plus libre je pense mais pas de beaucoup.
Et enfin, oo utilise agpl pour faire du duo licensing. Si tu payes, et on a demandé, tu obtiens une version propriétaire. Ils pensent que c'est une fonctionnalité. On a demandé de payer et d'avoir quand même la version agpl, c'est pas possible, dommage.. du coup, l'intention derrière agpl est clairement open source.
(Dans le cas de lool, je pense que c'est pas possible de faire du duo licensing, je ne suis pas un avocat hein, mais je ne pense pas.)
Du coup, à ce stade, on peut dire que lool est un peu plus libre que oo, mais c'est pas non plus flagrant.
En terme de fonctionnalité et d'architecture, lool est en fait une sorte de mélange démoniaque entre VNC et OpenStreetMap, oui, ce que vous voyez sont des tiles de screenshot pris côté serveur.. du coup, en terme de perf, c'est pas terrible et en terme d'accessibilité non plus.
Oo fonctionne en js dans le navigateur, du coup, c'est plus fluide.
Du coup, on pari sur oo, et on pense que la communauté est assez grande (cryptpad (tikiwiki) et twake (linagora) utilisent oo par example) pour que si l'entreprise ferme trop, il puisse y avoir fork.
Voila, ce que je viens de dire n'est pas forcément une vérité absolue, j'ai pas trop sourcé (sur mon tel), mais c'est l'état de notre réflexion aujourd'hui.
[^] # Re: Libre vs OpenSource ?
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 04 octobre 2020 à 14:49.
Je ne sais pas 4 dimensions de quoi en tout cas le libre ne concerne que le premier.
Des évangélistes cherchent à amalgamer tout et n'importe quoi avec du libre, mais c'est vraiment au forceps et il serait amha préférable de formaliser ses idées plutôt que de tenter de faire des constructions assez bancales et donc fragiles.
Ta dernière dimension par exemple parle plus de gouvernance partagée voir communautaire que libre. C'est bien plus clair. Ce n'est pas de l'intuition, mais des faits.
C'est faux. Debian a sa propre définition du logiciel libre, elle est très claire et tout logiciel qui correspond à cette définition peut être inclus (petit bémol avec l'équipe de diversité qui peu mettre son grain de sel). Mais Debian ne s'intéresse pas particulièrement l'intention du ou des auteurs. Ils se permettent tout à fait de modifier les logiciels inclus des fois aux grands dam des auteurs. On a aussi vu des dark patterns apparaître pour tenter d'empêcher de Debian de distribuer un logiciel quand ce dernier est considéré trop vieux par le développeur. Debian et l'intention des développeurs, je ne suis pas sûr qu'on puisse dire que c'est la paix.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Libre vs OpenSource ?
Posté par pierreozoux . Évalué à 0.
Oui, désolé sur debian, la phrase que tu cites manque cruellement de modestie épistémique :)
Je me réfère à cet échange en particulier. Mais cela ne reflète pas forcément tout debian. Pour être honnête, je ne connais pas trop debian, alors je te fais confiance sur ce point là.
Et pour la question du libre, j'ai l'impression que c'est plus compliqué que juste une license.
Et en fait, j'ai oublié un detail, de dire ce qui compte pour nous quand nous choisissons de travailler avec un projet. Il faut qu'il soit libre ou open source, au sens de la fsf, ou de debian, c'est sur. Mais surtout, nous avons besoin que ce projet reste libre dans le temps.
Par exemple, on utilise kubedb depuis quelques années et la license vient de changer, mauvais choix, du coup, on ne peut mettre à jour, et nous sommes en train de travailler pour migrer vers une autre solution.
Donc oui, pour etre libre, peut-être que seul la license compte, mais pour évaluer la pérennité je pense qu'il faut regarder les 3 autres dimensions.
[^] # Re: Libre vs OpenSource ?
Posté par barmic 🦦 . Évalué à 3.
Note que je ne remet pas en cause l'intérêt des dimensions. Je trouve juste que de tenter de coller ces caractéristiques à du libre n'est pas pertinent.
Et il y a d'autres écoles. Si tu regarde la fondation Apache, il y a un cahier des charges pour qu'un projet y participe. Le libre (pour être précis : utiliser la licence Apache) n'est qu'un des points.
Tout un chacun peut avoir ses critères personnel. C'est juste qu'affirmer que ces critères sont la définition du libre c'est dommage voit non pertinent.
Ça pourrait être intéressant pour vous d'établir une liste de caractéristiques importantes pour vous (libre avec copyleft, copyright partagé, une certaine quantité de contributions,…). Il n'y a pas besoin d'en appeler au libre pour ça. Ça permet de clair avec vous utilisateurs aussi.
Pas d'offense cette question de ce que l'on met derrière libre ou non est une vraie question. Beaucoup de gens tentent d'y placer leurs idées politiques (au sens général sur l'organisation et ce qu'ils aimeraient y voir), c'est une forme d'entrisme qui me gêne (sans jugement pour l'idée en elle même).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Nextcloud Hub
Posté par nathanaelh . Évalué à 2.
Bonjour, merci pour cette présentation. Je trouve très intéressant le choix technique, et j'ai lu avec grand intérêt les précisions dans les commentaires.
J'ai ce pendant une question, comment se sont fait les choix pour le chat de Rocket Chat et pour la visio de Jitsi ? Avez-vous envisagé la solution tout en un de Nextcloud avec Nextcloud Talk et le module "high performance back-end" ?
Je ne prétends as qu'une solution soit meilleure qu'une autre. Je suis simplement intéressé par la réflexion que vous avez probablement eu.
[^] # Re: Nextcloud Hub
Posté par pierreozoux . Évalué à 2.
Bonjour, merci pour votre commentaire.
On utilise RocketChat depuis 2015 (on a créé l'image docker officielle ;) ), et on les connait un peu, on s'est rencontrés au fosdem.
Du coup, en tant qu'alternatives a Slack, il n'y a pas beaucoup d'options:
- mattermost
- element (matrix)
- Nextcloud talk
- et RocketChat
Matrix n'est pas encore utilisable par un utilisateur non geek, même moi je galère ;) Et à héberger, il parait que c'est l'horreur. Nos collègues de chez disroot ont arrêté par exemple.
Nextcloud talk est développé par 2/3 devs depuis 2/3 ans. J'ai pas les chiffres exactes et c'est surement une caricature, mais du coup, c'est assez pauvre en fonctionnalités.
Mattermost, je ne connais pas trop. Je pense que c'est équivalent à RocketChat en fonctionnalités et UI/UX (je prefere RC mais bon, les gouts et le couleurs..).
En terme d'entreprise derriere, on est sur de l'open core plus affiché et plus franc que RocketChat. Par exemple pour le SSO, il faut recompiler le frontend..
Apres, c'est du go et du postgres et ça nous faciliterait bien la vie :)
Aussi j'aime pas la fonctionnalité MultiTenant (mais bon pas obligé de l'utiliser)
Enfin RocketChat, est pour moi le meilleur. Il y a plus de 30 personnes depuis plus de 5ans, dont des designers UX, UI qui travaillent sur ce projet.
Il y a toute les fonctionnalités pour gérer des communautés de plusieurs milliers de personnes (pas comme Nc talk).
Enfin, on peut fédérer des instances de RocketChat, c'est encore beta, mais j'ai de l'espoir :)
Une fois RocketChat choisi, il a fallu choisir l'intégration pour la visio.
BigBlueButton ou jitsi.
L'intégration bbb ne permet pas le partage d'écran, on a donc choisit jitsi.
Enfin, le challenge par rappory à Hub, c'est la collaboration sur un doc partagé avec la visio.. c'est plus complexe à mettre en place.
Et aussi, on est fan de la unix philosophie, on préférerait que Nc se concentre sur le cloud et collabora plus avec RocketChat, mais bon..
[^] # Re: Nextcloud Hub
Posté par Nico7as . Évalué à 1.
Bonjour,
Merci d'oeuvrer pour la diffusion d'outils libres ou open-source.
Je me posais la même question. NextCloud me semble évoluer très vite, la version 20 vient de sortir, et ça semble être une solution de plus en plus populaire, y compris dans de grosses structures (universités, etc…)
Je ne connais pas le niveau de fonctionnalité de Talk par rapport à Jitsi, ou BigBlueButton, mais il a, me semble-t-il, l'avantage de profiter d'une intégration avancée dans NextCloud.
Et il me semble que le code back-end de Talk a été "Open-Sourced" il y a quelques mois.
Et il existe un App pour iOS et Android.
Peut-être qu'un échange avec l'équipe de Zaclys vous permettrait de comparer.
[^] # Re: Nextcloud Hub
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Ca m'intéresse… aurais-tu des liens vers des articles de blog, fils de discussion ou autre qui évoque ce sujet ? On est justement en train d'envisager de passer de mattermost à Matrix/Element…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.