![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Bonjour
J'avoue que j'ai un peu du mal à bien suivre les choses...
Il est où ce débat sur l'avenir de la suite ?
On fait tous en fonction de notre disponibilités mais j'ai l'impression d'avoir manqué l'info.
Merci par avance
Claire
Bonjour Claire,
Bonjour
J'avoue que j'ai un peu du mal à bien suivre les choses...
Il est où ce débat sur l'avenir de la suite ?On fait tous en fonction de notre disponibilités mais j'ai l'impression d'avoir manqué l'info.
Tu peux lire sur l'archive de la liste du Board, un résumé avec des
liens ici:
https://listarchives.documentfoundation.org/www/board-discuss/2020/msg00226.html
l'origine/nal ici:
https://listarchives.documentfoundation.org/www/board-discuss/2020/msg00162.html
Nous avons aussi eu une réunion de la communauté FR sur jitsi ou Italo
est venu en parler en juillet.
Pour le moment le plan est en révision et devra s'appliquer à la 7.1
À bientôt
Sophie
Bonjour
merci pour ta réponse. J'ajoute la liste discuss, j'aurais dû y penser
hier.J'ai repris les "minutes" de William et n'ai pas trouvé d'autre
retour de la réunion du 18/07. Soyons honnêtes, ce n'est pas la
meilleure période (mi-juillet) pour y trouver une disponibilité
(j'ajoute à ça que même si je regarde les retours de ces réunions qui
paraissent intéressantes, je ne trouve pas la dispo suffisante pour y
participer).Je vois les éléments de débats repris par William mais pas
l'exposé des motifs qui suscite le débat. J'ai vu l'issue sur bugzilla,
mais je ne suis absolument pas "fluent" en anglais. C'est peut-être
pour ça qu'il est difficile pour les francophones de s'approprier le
débat (même si je devine qu'il a une importance non négligeable pour
l'avenir).
Ce que je comprends :La contribution de CIB ou Collabora est vraiment
trés importante, et il apparait naturel de leur permettre un "retour
sur investissement".Dans Bugzilla j'ai surtout vu un débat sur comment
formuler le nom de l'édition LibreOffice installée (dans A propos de,
ou dans le "splash" de lancement ? Je ne sais pas !).Je vois que
globalement entre personal edition et community edition, il semble se
dégager un consensus pour dire que Community Edition ce serait mieux
que Personal (je confirmes !)Et à coté de ça essaie de se dégager une
version "entreprise" proposée par les éditeurs "contributeurs"...
généralement appelée "Entreprises"... Si c'est ça, le terme Pro me
parait mieux.
Ma réflexion des bribes que j'ai comprises (mais si on a déjà quelques
lignes en français sur ce plan marketing 20/25, je prends !) :La marque
LibreOffice est connue (même si persiste encore une confusion avec
OOo). TDF ne l'est absolument pas. C'est regrettable. Dans une DSI,
quand on parle de Mozilla (je sais, l'éco-système n'est pas exactement
le même mais...) on comprend de quoi on parle. Quand on parle de The
Document Foundation, systématiquement la question est "hein ? Quoi ?
C'est quoi ça ?!"
Il me semble que TDF devrait être beaucoup plus connue, et qu'un effort
devrait être fait en ce sens. On sait que soffice.exe, c'est
l'exécutable de LibreOffice. Tous les utilisateurs ont compris ça. The
Document Foundation ? Absolument pas. Il me semble que pour faire
comprendre l'investissement, et tout le travail, tous les gens qui sont
derrière TDF, et TDF, et la communuaté devraient être plus mis en
valeurs.
Sur la question de CIB, Collabora... Les logiciels libres qui changent
leur modèle de licence à destination des pros (oui je préfère vraiment
pro à Entreprise), c'est monnaie courante en ce moment. J'ai bien en
tête la logique de Contributopia lancé par Framasoft il y a.. 2-3 ans
et de Pyg qui explique à quel point les logiciels libres sont vraiment
fragilisés par le faible nombre des développeurs existant par projet.
Et qu'il y a tellement de moyens pour contribuer, mais si on a plein de
documentaristes, assistants, communicants, si l'on n'a pas de
développeurs, c'est casse-g... La preuve, les dernieres plaintes sur
les bugs..Encourager les prestas de supports par des personnes, des
entités, qualifiées, certifiées, c'est vraiment bien. Reste à avoir des
contacts affichés pour la France. Il y a 3 ans nous avons voulu lancer
une presta sur des formations et avons cherché des gens connaisseurs de
LibreOffice. Sur le site web, les références en France était trop
réduites ou inexistantes. Au final, le projet a littéralement
capoté.Par ailleurs, il ne faut pas mélanger cause et conséquence.
L'administration française a bien un prestataire de support aux
logiciels libres, particulièrement LibreOffice. Le presta en question,
n'est pas nécessairement CIB ou Collabora, il faut là aussi penser, que
l'administration a certaines contraintes pour choisir son presta.
Forcer une version pour les "pro" ne va pas forcément résoudre le
problème. C'est quand même une question de marché public. Ceci-dit le
nouveau marché est pour dans quelques semaines....
Soyons pragmatiques et honnetes. S'il y a des vrais convaincus pour les
logiciels libres dans l'administratin. En majorité, ceux qui le sont,
n'ont pas compris, que ne pas payer une licence, ne signifie pas cout
zéro. Par exemple, j'ai beaucoup de mal à faire entrer dans les têtes
que "logiciel à licence" ne veut rien dire, car tout logiciel à une
licence. Passer à "logiciels propriétaires" ou "logiciels à licence
payante" est trés difficile.Je n'ai pas l'impression que ce soit ce qui
est prévu, mais s'il s'agissait de restreindre l'utilisation de
LibreOffice (la version habituelle dispo sur le site) à une
"utilisation perso", il n'en faudrait pas plus pour que tous les
efforts menés conduisent à revenir à MS Office dans toutes les
administrations (oui l'opposant, n'est pas tendre !). Les
administrations où seul LibreOffice est proposé sont extrêmement
rare.Nous avons des logiciels métiers, open source. Lorsque le modèle
de licence évolue, vers "utilisation personnelle", "à des fins de
recherches", ou surtout qu'une licence doit être payée, le logiciel est
progressivement abandonné... Je ne dis pas que c'est bien. Je dis que
c'est ce qui est.
Bref, dès lors comment valoriser CIB ou Collabora, pour s'assurer de
leur contribution si précieuse ?Ce qui se passe sur la version On Line
est peut être inspirant, du moins en partie. Car sur la version OnLine,
il y a l'aspect technique de déploiement serveur, docker...Pour un
support pro de LibreOffice OnLine, on va plutôt prendre CODE par
exemple (mais il y a les limites que j'ai mentionnées plus haut). Que
l'on sache que Collabora ou CIB peuvent avoir une version pro, qui
intègre plus vite des correctifs et permette d'accéder à un support pro
me paraitrait vraiment positif. Avec un impératif malgré tout, que ces
versions suivent quand même les Release Plan LibreOffice (quitte à
intégrer leur propres modifs). Il faut qu'il puisse y avoir reversement
auprès de la communauté... Cela me fait penser au système existant sur
RedHat vs Fedora (un peu inversé malgré tout).
Une dernière contrainte que j'imagine : c'est un trés bon argument de
pouvoir dire le logiciel que tu as au boulot, tu peux aussi librement
l'installer chez toi pour tes propres besoins. C'est un vrai facteur
pour que l'habitude pro, contribue au changement de l'habitude
perso...
Voilà, en espérant ne pas avoir tout mal compris. Mon avis est
totalement subjectif, car je vois comment ça fonctionne en milieu pro
(même si je le déplore !) et je comprendrais tout à fait, que des
contraintes soient posées, pour mieux affirmer LibreOffice et sa
logique de contribution.
Claire
Bonjour
je reprends le message de Thierry dans ce fil...
Bonjour à tous,
Pour rebondir sur un sujet d'actualité, je m'interroge sur le
bienfondé de fournir régulièrement des versions de LibreOffice qui
apportent finalement peu de fonctionnalités réellement indispensables
alors que les bases de la suite semblent se fragiliser à chacune
d'entre elles.
Ne serait-il pas préférable de s'arrêter, de constater les dégâts et
de corriger l'interminable liste de bugs ?
j'ai l'impression qu'on arrive à une liste de demande de consommateurs
par rapport à leur fournisseur de service. ça me gène un peu pour un
logiciel libre...
le rythme de changement de version ne me choque pas du tout. Je
distingue 3 niveaux (majeur =7, mineure=7.0 et correctifs = tout ce qui
suit...)Il y a en plus 2 versions maintenues en parallèle. Si ça va
trop vite, qu'on veut quelque chose de stabilisé, alors on s'attarde
sur la 6.4. C'est aussi un moyen pour laisser le temps qu'un certain
nombre de correctifs passent sur la 7.0.Il me semble bvien que le
discours est assez clair sur le fait qu'avant le 4e correctif, la
version n'est pas "déployable en entreprise". J'en déduis, que coté
perso, pour un fonctionnement stabilisé, c'est valable aussi.
j'aimerais une migration finalisée à une version défendable du
système de gestion de base de données proposé, un comportement stable
et compréhensible de l'ensemble des modules, une gestion parfaite des
formats de documents déclarés supportés.
je me rappelle de tes messages sur le passage de Firebird à HSQLDB pour
une version précédente. Je comprends que sur cette fonctionnalité ça
n'a pas avancé (ou pas autant qu'il aurait fallu), mais en réalité, là
encore c'est un peu la logique du libre, de l'open source.Pour apporter
les améliorations nécessaires, stabiliser, il faut que les développeurs
soient dispo. Sur des éditeurs pro, que ceux ci soient payés pour, sur
des volontaires, sur des fonctions qui les intéressent et qu'ils sont à
même de traiter...De fait, il y a des modules dans LibreOffice qui
bénéficient d'une plus grande réactivité d'un point de vue évolution
(Calc, Writer). J'ai tendance à y voir une logique de demande plus
forte !Quand à la gestion parfaite des formats de documents... Non
quand même... Comment on fait pour atteindre la perfection pour des
formats qui ne sont pas publics ? Comment on fait pour gérer les
formats multiples pour une même extension ? Parce malgré tout, avec
LibreOffice on arrive à proposer un format OOXML strict et un format
MSO, avec la même extension, comme le fait MSO. Je trouve que déjà,
c'est un exploit. Se contenter de l'ooxml strict ne me choquerait pas
Un effort sérieux de documentation, surtout en ce qui concerne
l'utilisation de LibreOffice comme plateforme de gestion, serait
également un sacré avantage lorsqu'il s'agira de la présenter en
compétition avec MS.
Tu as une idée précise pour la présentation en compétition avec MSO
? Mon avis perso c'est que MSO, logiciel propriétaire peut faire du
global payant en incluant la gestion de BDD dans sa suite bureautique
via Access. Du coup, il perturbe les repères. Non gérer une base de
données, ce n'est pas "bureautique".Par ailleurs si on passe son temps
à construire LibreOffice en comparaison avec MS Office, c'est plus que
dommage. Je pense, que depuis toujours de Star Office à aujourd'hui, la
suite a su développer ses spécificités, et qu'il faut qu'elle les
garde, les développe.
Là où je trouve qu'il peut y avoir un manque, c'est quand une nouvelle
fonctionnalité n'est pas documentée (comme la validation de données
"personnalisée" dont on a parlé ces derniers jours, sauf qu'après les
tests effectués, il y a désormais de quoi documenter) et c'est rageant,
car du coup, comment l'utiliser et en profiter ?Y'a un boulot énorme
fait sur les guides, et quand on débarque sur la suite, c'est hyper
important de les trouver. En même temps, après un peu d'habitude, ce
n'est pas cette doc qu'on consulte le plus, mais l'aide. Il y a eu une
réunion sur le travail documentaire réalisé au début de l'été je crois.
Avec mon petit bout de lorgnette, je me dis que contribuer à la doc en
ligne est peut être moins lourd que contribuer à la traduction des
guides. Et cela permettrait de documenter les nouvelles fonctions...
Encore faut-il contribuer.
Ceci dit, je n'ai aucun moyen de contribuer à atteindre cet idéal, à
part ronchonner un peu dans mon coin lorsque je vois tout à coup
disparaître Firebird de la liste des bases proposées alors que dans
la version précédente j'étais enfin parvenu à une migration
présentable...
ben oui, on sent bien que du coup, t'es plutôt coincé... Reste que dans
la logique actuelle de LibreOffice, il faut réussir à mettre la main à
la patte. Moi même, j'y arrive pas. ça me calme sérieusement sur mes
critiques de ceux qui font... Et sur qui on se repose gentiment.
Pour le reste, je n'ai JAMAIS perdu le contenu d'un document, depuis
StarOffice. Ca commence à dater. Alors que sur le même intervalle,
j'en perdais environ un par mois avec la suite ennemie. Ce serait
dommage que LibreOffice rejoigne aussi Microsoft sur ce point.
pour rejoidnre MSO lç dessus, il faudrait un format fermé, un code
applicatif fermé... J'ai l'impression que ce n'est pas vraiment le
chemin pris.
En espérant que vous restez prudents, belle journée à tous, merci aux
contributeurs directs,Thierry
Bonne fin de journée à toi !
Claire
Bonjour Claire,
Je ne vais pas reprendre point par point.
J'utilise avec bonheur xxxOffice depuis la première version disponible de StarOffice. Ca commence donc à faire quelques années. C'est mon outil bureautique d'élection, c'est mon outil de bureautique privée, celui que je conseille à mes amis et relations. Par contre j'ai dû dans mon environnement professionnel utiliser MSO. Je peux donc comparer réellement les deux logiciels.
Lorsque tu dis que gérer une base de données n'est pas de la bureautique, tu te trompes. Si on inclut des outils permettant de le faire dans une "suite bureautique", c'est... pour que ce soit fait. La bureautique est une notion large, qui inclut la gestion documentaire, de modèles, voire des contacts, etc. Pourquoi limiter l'imagination des gens ?
Au fil du temps j'ai vu ce que des utilisateurs débrouillards étaient capables de faire avec MSO lorsqu'ils avaient une idée claire de leur domaine d'activité, et j'ai parfois contribué à faire aboutir leurs projets. On obtient assez facilement de véritables logiciels de gestion spécialisée, efficaces et professionnels. J'ai observé à ces occasions les facilités de rédaction et de documentation de code qu'offr(ait ?) MS et qui me semblent cruellement absentes de LibreOffice/OpenOffice.
J'ai d'autant plus ressenti cette absence lorsque j'ai entrepris de tricoter sur mesure une petite application de gestion pour des amis ayant une activité indépendante. Leurs besoins étaient atypiques, il fallait d'une part pouvoir gérer un minimum l'information, mais surtout pouvoir retoucher à l'envi les documents produits. Quoi de mieux qu'une suite bureautique pour cela, et quoi de mieux qu'une base de données pour stocker des données et une pile de macros (BASIC, restons simples) pour les exploiter ?
Pour aboutir, j'ai d'abord buté sur le modèle objets de LibreOffice, puis sur la manière de l'attaquer, puis de s'en passer. Grâce aux documentations de Jean-François Nifenecker j'ai fini par en venir à bout et à apprécier la puissance des outils fournis. Mais ça aurait pu être plus facile. Et sans lui, macache.
Actuellement, je pense que LibreOffice couvre 99% des besoins d'une vie de n'importe quel individu. Personnellement, je l'ai utilisée pour rédiger un bouquin (traduction) comptant plus de 2'000 renvois et notes, d'innombrables courriers, tenir ma comptabilité, confectionner quelques publications illustrées et même quelques pages WEB. Mais tout ça n'a pas été fait avec la version 7, ça date de bien des années : L'application de mes amis a été faite en version 5.x et il n'est pas question de la migrer, le bouquin a été finalisé en 2006. Et déjà bien auparavant, la suite était très utilisable, agréable et de fonctionnement sûr.
Je n'ai donc personnellement aucun besoin d'évolution de LibreOffice, l'essentiel y est et fort bien depuis fort longtemps.
Ma remarque venait de la coïncidence entre une cascade de plaintes de personnes (enseignants ?) relevant des anomalies persistantes dans les modules de présentation, par exemple, qui perdurent de version majeure en version majeure. Personnellement, peu m'en chaut, je n'utilise quasiment pas ce module.
Par contre ces remarques ont éveillé en écho chez moi le sujet de la base de données. HSQLDB est bloqué à une version antédiluvienne, ce qui est rarement bon signe - et sans doute dommage. On nous promet le passage à Firebird. Mais lorsqu'on passe à Firebird, on perd à la conversion d'une base HSQLDB toute la partie relationnelle. Pourquoi ? Parce qu'une ligne est fausse dans le kit d'installation, et si on n'intervient pas manuellement avant toute chose, on se retrouve dans le bain. Quelle correction a été apportée à ce souci ? On retire la possibilité d'utiliser Firebird ! Franchement...
La disproportion entre ce bug ridicule et sa "solution", et les efforts fournis pour publier des versions qui à mon avis n'apportent vraiment pas grand chose de neuf est telle que ça m'a agacé.
D'où ma proposition : Que les développeurs s'accordent une période de grâce, sans release majeure. Qu'ils travaillent sur les fondamentaux et assurent un fonctionnement lisse de ce qui est livré. Ensuite il sera temps d'évaluer ce que les utilisateurs demandent *vraiment*. Mais a priori, si on veut que LibreOffice vive, il faut qu'elle ait des utilisateurs. Et pour cela, il faut que les utilisateurs en soient SATISFAITS et en parlent, en bien. Je veux bien croire au développeur enfermé dans son box se nourrissant de pizzas et buvant du Cola, mais je n'en ai jamais rencontré, un peu comme le Yéti, quoi. Par contre, ceux que je connais et fréquente sont souvent curieux de fournir le *truc* qui fera Tilt chez l'utilisateur, qui déclenchera l'effet OuaOuh. Les autres sont juste des salariés, je ne les vois pas actifs dans le domaine de l'OpenSource.
Concrètement, pourquoi ne pas définir une version 8. qui sera LA plateforme de référence pour les développements futurs, qui n'apporterait AUCUNE *nouvelle fonctionnalité* mais corrigerait 80% des bugs, à commencer par 100% de ceux qui trainent depuis plus d'une version majeure ? Ceci dit à la louche, sans avoir regardé.
Il me semble que le modèle actuel de développement a été calqué sur le modèle d'agitation stochastique de MS, à savoir qu'il faut produire des versions pour remplir le tiroir caisse, quelles que soient les raisons poussant à de nouveaux développement. Mais le tiroir caisse de LibreOffice est bien modeste comparé à celui de MS, et, surtout, il ne dépend pas de l'appréciation du marché boursier. Alors à qui profite le crime ?? Je comprends bien que du moment que des équipes sont payées pour développer un produit, il est nécessaire de les faire travailler, ne serait-ce que pour qu'elles ne s'ennuient pas. Mais corriger des bugs, c'est aussi un sacré boulot.
Lorsque je disais que je ne peux pas intervenir moi-même, c'est parce que je ne souhaite pas entrer maintenant dans un projet de cette ampleur dont je ne connais quasiment rien au plan technique - et pas grand chose au plan administratif. Je tiens à préserver mes quelques cheveux blancs résiduels.
Par contre je peux relire de la documentation, au moins au plan syntaxique / orthographique, si je trouve où cela se passe et comprends le circuit à adopter. Et j'arriverais même à installer une version particulière dans une VM pour vérifier des trucs techniques, si, si.
Sur ce, bonne journée, à bientôt,
Thierry
Bonjour Claire,
Je ne vais pas reprendre point par point.
J'utilise avec bonheur xxxOffice depuis la première version disponible de StarOffice. Ca commence donc à faire quelques années. C'est mon outil bureautique d'élection, c'est mon outil de bureautique privée, celui que je conseille à mes amis et relations. Par contre j'ai dû dans mon environnement professionnel utiliser MSO. Je peux donc comparer réellement les deux logiciels.
Lorsque tu dis que gérer une base de données n'est pas de la bureautique, tu te trompes. Si on inclut des outils permettant de le faire dans une "suite bureautique", c'est... pour que ce soit fait. La bureautique est une notion large, qui inclut la gestion documentaire, de modèles, voire des contacts, etc. Pourquoi limiter l'imagination des gens ?
Au fil du temps j'ai vu ce que des utilisateurs débrouillards étaient capables de faire avec MSO lorsqu'ils avaient une idée claire de leur domaine d'activité, et j'ai parfois contribué à faire aboutir leurs projets. On obtient assez facilement de véritables logiciels de gestion spécialisée, efficaces et professionnels. J'ai observé à ces occasions les facilités de rédaction et de documentation de code qu'offr(ait ?) MS et qui me semblent cruellement absentes de LibreOffice/OpenOffice.
J'ai d'autant plus ressenti cette absence lorsque j'ai entrepris de tricoter sur mesure une petite application de gestion pour des amis ayant une activité indépendante. Leurs besoins étaient atypiques, il fallait d'une part pouvoir gérer un minimum l'information, mais surtout pouvoir retoucher à l'envi les documents produits. Quoi de mieux qu'une suite bureautique pour cela, et quoi de mieux qu'une base de données pour stocker des données et une pile de macros (BASIC, restons simples) pour les exploiter ?
Pour aboutir, j'ai d'abord buté sur le modèle objets de LibreOffice, puis sur la manière de l'attaquer, puis de s'en passer. Grâce aux documentations de Jean-François Nifenecker j'ai fini par en venir à bout et à apprécier la puissance des outils fournis. Mais ça aurait pu être plus facile. Et sans lui, macache.
Actuellement, je pense que LibreOffice couvre 99% des besoins d'une vie de n'importe quel individu. Personnellement, je l'ai utilisée pour rédiger un bouquin (traduction) comptant plus de 2'000 renvois et notes, d'innombrables courriers, tenir ma comptabilité, confectionner quelques publications illustrées et même quelques pages WEB. Mais tout ça n'a pas été fait avec la version 7, ça date de bien des années : L'application de mes amis a été faite en version 5.x et il n'est pas question de la migrer, le bouquin a été finalisé en 2006. Et déjà bien auparavant, la suite était très utilisable, agréable et de fonctionnement sûr.
Je n'ai donc personnellement aucun besoin d'évolution de LibreOffice, l'essentiel y est et fort bien depuis fort longtemps.
Ma remarque venait de la coïncidence entre une cascade de plaintes de personnes (enseignants ?) relevant des anomalies persistantes dans les modules de présentation, par exemple, qui perdurent de version majeure en version majeure. Personnellement, peu m'en chaut, je n'utilise quasiment pas ce module.
Par contre ces remarques ont éveillé en écho chez moi le sujet de la base de données. HSQLDB est bloqué à une version antédiluvienne, ce qui est rarement bon signe - et sans doute dommage. On nous promet le passage à Firebird. Mais lorsqu'on passe à Firebird, on perd à la conversion d'une base HSQLDB toute la partie relationnelle. Pourquoi ? Parce qu'une ligne est fausse dans le kit d'installation, et si on n'intervient pas manuellement avant toute chose, on se retrouve dans le bain. Quelle correction a été apportée à ce souci ? On retire la possibilité d'utiliser Firebird ! Franchement...
La disproportion entre ce bug ridicule et sa "solution", et les efforts fournis pour publier des versions qui à mon avis n'apportent vraiment pas grand chose de neuf est telle que ça m'a agacé.
D'où ma proposition : Que les développeurs s'accordent une période de grâce, sans release majeure. Qu'ils travaillent sur les fondamentaux et assurent un fonctionnement lisse de ce qui est livré. Ensuite il sera temps d'évaluer ce que les utilisateurs demandent *vraiment*. Mais a priori, si on veut que LibreOffice vive, il faut qu'elle ait des utilisateurs. Et pour cela, il faut que les utilisateurs en soient SATISFAITS et en parlent, en bien. Je veux bien croire au développeur enfermé dans son box se nourrissant de pizzas et buvant du Cola, mais je n'en ai jamais rencontré, un peu comme le Yéti, quoi. Par contre, ceux que je connais et fréquente sont souvent curieux de fournir le *truc* qui fera Tilt chez l'utilisateur, qui déclenchera l'effet OuaOuh. Les autres sont juste des salariés, je ne les vois pas actifs dans le domaine de l'OpenSource.
Concrètement, pourquoi ne pas définir une version 8. qui sera LA plateforme de référence pour les développements futurs, qui n'apporterait AUCUNE *nouvelle fonctionnalité* mais corrigerait 80% des bugs, à commencer par 100% de ceux qui trainent depuis plus d'une version majeure ? Ceci dit à la louche, sans avoir regardé.
Il me semble que le modèle actuel de développement a été calqué sur le modèle d'agitation stochastique de MS, à savoir qu'il faut produire des versions pour remplir le tiroir caisse, quelles que soient les raisons poussant à de nouveaux développement. Mais le tiroir caisse de LibreOffice est bien modeste comparé à celui de MS, et, surtout, il ne dépend pas de l'appréciation du marché boursier. Alors à qui profite le crime ?? Je comprends bien que du moment que des équipes sont payées pour développer un produit, il est nécessaire de les faire travailler, ne serait-ce que pour qu'elles ne s'ennuient pas. Mais corriger des bugs, c'est aussi un sacré boulot.
Lorsque je disais que je ne peux pas intervenir moi-même, c'est parce que je ne souhaite pas entrer maintenant dans un projet de cette ampleur dont je ne connais quasiment rien au plan technique - et pas grand chose au plan administratif. Je tiens à préserver mes quelques cheveux blancs résiduels.
*D'accord à 100% avec tout ces propos !*
Par contre je peux relire de la documentation, au moins au plan syntaxique / orthographique, si je trouve où cela se passe et comprends le circuit à adopter. Et j'arriverais même à installer une version particulière dans une VM pour vérifier des trucs techniques, si, si.
C'est aussi comme ça que je fonctionne pour la traduction, puisque je refais (et traduis) tous les exemples, pour être sûr de faire une doc utilisable....La machine virtuelle pour les tests, un bonheur
Bonne journée,
Il y a moyen de publier le contenu de cette intervention à réaliser ?
A plus
Bonjour Thierry,
Bonjour Claire,
Je ne vais pas reprendre point par point.
Moi non plus, je saute donc au modèle économique :
D'où ma proposition : Que les développeurs s'accordent une période de
grâce, sans release majeure. Qu'ils travaillent sur les fondamentaux et
assurent un fonctionnement lisse de ce qui est livré. Ensuite il sera
temps d'évaluer ce que les utilisateurs demandent *vraiment*. Mais a
priori, si on veut que LibreOffice vive, il faut qu'elle ait des
utilisateurs. Et pour cela, il faut que les utilisateurs en soient
SATISFAITS et en parlent, en bien. Je veux bien croire au développeur
enfermé dans son box se nourrissant de pizzas et buvant du Cola, mais je
n'en ai jamais rencontré, un peu comme le Yéti, quoi. Par contre, ceux
que je connais et fréquente sont souvent curieux de fournir le *truc*
qui fera Tilt chez l'utilisateur, qui déclenchera l'effet OuaOuh. Les
autres sont juste des salariés, je ne les vois pas actifs dans le
domaine de l'OpenSource.Concrètement, pourquoi ne pas définir une version 8. qui sera LA
plateforme de référence pour les développements futurs, qui
n'apporterait AUCUNE *nouvelle fonctionnalité* mais corrigerait 80% des
bugs, à commencer par 100% de ceux qui trainent depuis plus d'une
version majeure ? Ceci dit à la louche, sans avoir regardé.
Comment les entreprise de l'écosystème vont réaliser ces développements
sans nouvelle version et sans être financées par leurs clients ?
Pourquoi les clients paieraient pour la correction de bugs/régressions
qu'ils ne rencontrent pas ?
Il me semble que le modèle actuel de développement a été calqué sur le
modèle d'agitation stochastique de MS, à savoir qu'il faut produire des
versions pour remplir le tiroir caisse, quelles que soient les raisons
poussant à de nouveaux développement. Mais le tiroir caisse de
LibreOffice est bien modeste comparé à celui de MS, et, surtout, il ne
dépend pas de l'appréciation du marché boursier. Alors à qui profite le
crime ?? Je comprends bien que du moment que des équipes sont payées
pour développer un produit, il est nécessaire de les faire travailler,
ne serait-ce que pour qu'elles ne s'ennuient pas. Mais corriger des
bugs, c'est aussi un sacré boulot.
Sauf qu'ici on ne parle pas du tiroir caisse de TDF mais de celui de
ceux qui écrivent le code de LibreOffice. Quelle solution pour obliger
ces entreprises à travailler pour TDF/LibreOffice plutôt que pour leurs
clients ?
À bientôt
Sophie
Bonjour
Bonjour Thierry,Le 08/09/2020 à 10:28, Thierry Jeanneret a écrit :
> Bonjour Claire,
> Je ne vais pas reprendre point par point.Moi non plus, je saute donc au modèle économique :
Merci de revenir à ce point.
Justement, je n'arrive pas à voir ce qu'implique concrètement
d'accorder une licence d'utilisation de la marque pour les entreprises
de l'écosystème ?
Cela signifie-t-il que le code restant ouvert, pour republier en tant
que LibreOffice, il faut une licence d'utilisation ? Est-ce raccord
avec les licences actuelles de LibreOffice ?
Cela ne favoriserait-il pas le développement de fork (bien/pas bien ?)
pour ceux qui n'ont pas cette licence d'utilisation ?
Comment les entreprise de l'écosystème vont réaliser ces
développementssans nouvelle version et sans être financées par leurs
clients ?Pourquoi les clients paieraient pour la correction de
bugs/régressionsqu'ils ne rencontrent pas ?
Cela me fait penser à la question du support étendu (ou LTS).
Aujourd'hui c'est bien la 6.4 qui peut être déployée en entreprise,
mais on est en revanche quasi au bout des mises à jour correctives pour
la 6.4.
L'intérêt du support étendu que ces entreprises pourraient assurer
(grâce à la licence d'utilisation ?) serait que leurs clients
pourraient bénéficier de correctifs sur une 6.4 pendant plus longtemps
(correctifs demandés par les dits clients).
Il me semble nécessaire de définir la durée max de ce support étendu
(n'est-ce pas déjà le cas, d'ailleurs ?)
Cela devrait aussi impliquer (via la licence d'utilisation de la marque
?) que ces correctifs, soient également portés dans les versions plus
récentes s'ils ne le sont pas déjà. Dans ce cas, les travaux pour les
clients des entreprises parties prenantes LibreOffice, bénéficieraient
à tous, dans la logique de l'open source.
Enfin, quand un client demanderait un ajout de fonctionnalité, cela
pourrait être en revanche conditionné à la mise en place sur une
version récente (par exemple aujourd'hui la 7).
Cela éviterait de cantonner les entreprises de l'écosystème à une
maintenance de vieille version, et donnerait de l'intérêt à tous.
Cela pourrait aussi aider sur la prise en charge de vieilles anomalies
pas prise en charge car il y a un différentiel entre la version
déployable en entreprise et celle qui fait l'objet de la majorité des
développements à un moment t.
Autant les changements de versions correctives doivent être assez
"simple" à déployer en entreprise, autant un changement de version
demande un peu plus de vigilance, il doit donc être moins fréquent.
Sauf qu'ici on ne parle pas du tiroir caisse de TDF mais de celui
deceux qui écrivent le code de LibreOffice. Quelle solution pour
obligerces entreprises à travailler pour TDF/LibreOffice plutôt que
pour leursclients ?
Il y a l'idéal et la réalité, mais tu sous entend qu'on arrive à la
situation ou le développement est quasi exclusivement porté par ces
entreprises (et donc qu'il faut les "obliger" à travailler pour
LibreOffice) ?
Même si je l'ai lu attentivement le doc en question que tu as fourni il
y a quelques jours, je suis restée sceptique, sur cette nouvelle entité
"TDC". J'ai du mal avec le commercial à but non lucratif, le
reversement, et les interactions décrites...
Pourquoi faut-il une entité distincte pour gérer les applicatifs TDF
(visionneuse Impress, Applis smartphone...) ?
Comment se place DLP(Liberation Project...) là dessus ? Car c'est un
projet moins connu, mais travailler sur l'interopérabilité, ce n'est
pas rien, et les entreprises et particulièrement les administrations
clientes pourraient justement avoir un intérêt sérieux sur le sujet....
Bonne fin de journée
Claire
Bonjour Claire et tous,
Bonjour
Bonjour Thierry,Le 08/09/2020 à 10:28, Thierry Jeanneret a écrit :
Bonjour Claire,
Je ne vais pas reprendre point par point.Moi non plus, je saute donc au modèle économique :
Merci de revenir à ce point.
Justement, je n'arrive pas à voir ce qu'implique concrètement
d'accorder une licence d'utilisation de la marque pour les entreprises
de l'écosystème ?
Cela signifie-t-il que le code restant ouvert, pour republier en tant
que LibreOffice, il faut une licence d'utilisation ? Est-ce raccord
avec les licences actuelles de LibreOffice ?
Il faut distinguer la marque du code. Pour essayer d'expliquer
simplement : La marque LibreOffice est déposée et appartient donc à TDF.
Le code de LibreOffice est sous les licences MPL/LGPL et est donc ouvert
et réutilisable sous les conditions de ces licences, mais la compilation
de ce code fournie par TDF ne peut pas s'appeler LibreOffice s'il est
compilé ou modifié par une autre entreprise.
L'exception c'est lorsqu'il y a un agrément d'utilisation du nom de la
marque entre TDF et l'entreprise. Comme c'est le cas pour CIB et Collabora.
Cela ne favoriserait-il pas le développement de fork (bien/pas bien ?)
pour ceux qui n'ont pas cette licence d'utilisation ?
S'il n'y a pas d'agrément d'utilisation de la marque entre TDF et
l'entreprise qui fournit une suite LibreOffice, alors c'est un autre
produit qui doit porter un autre nom. Cela ne pause pas de problèmes si
c'est un fork assumé (chacun vit sa vie de son côté) c'est plus un
problème quand on utilise la notoriété de LibreOffice alors que la
version fournie n'a pas la même couverture fonctionnelle ou la même
vigilance sur la sécurité.
Comment les entreprise de l'écosystème vont réaliser ces
développementssans nouvelle version et sans être financées par leurs
clients ?Pourquoi les clients paieraient pour la correction de
bugs/régressionsqu'ils ne rencontrent pas ?Cela me fait penser à la question du support étendu (ou LTS).
Aujourd'hui c'est bien la 6.4 qui peut être déployée en entreprise,
mais on est en revanche quasi au bout des mises à jour correctives pour
la 6.4.
L'intérêt du support étendu que ces entreprises pourraient assurer
(grâce à la licence d'utilisation ?) serait que leurs clients
pourraient bénéficier de correctifs sur une 6.4 pendant plus longtemps
(correctifs demandés par les dits clients).
Il me semble nécessaire de définir la durée max de ce support étendu
(n'est-ce pas déjà le cas, d'ailleurs ?)
Cela devrait aussi impliquer (via la licence d'utilisation de la marque
?) que ces correctifs, soient également portés dans les versions plus
récentes s'ils ne le sont pas déjà. Dans ce cas, les travaux pour les
clients des entreprises parties prenantes LibreOffice, bénéficieraient
à tous, dans la logique de l'open source.
Enfin, quand un client demanderait un ajout de fonctionnalité, cela
pourrait être en revanche conditionné à la mise en place sur une
version récente (par exemple aujourd'hui la 7).
Pour répondre à toutes ces questions, c'est effectivement ce qui se
passe si l'on prend l'exemple de Collabora. Ils fournissent un support
LTS sur 3 ans qui peut être étendu à 5 ans. Les corrections apportées
sont reversées au tronc commun (TDF/LibreOffice). Les nouvelles
fonctionnalités (telles que le caviardage par exemple) ne peuvent être
implémentées que sur une version majeure (7.0 par exemple, la branche
6.4.x n'acceptant pas de nouvelles fonctionnalités, que des patchs
correctifs).
Cela éviterait de cantonner les entreprises de l'écosystème à une
maintenance de vieille version, et donnerait de l'intérêt à tous.
Cela pourrait aussi aider sur la prise en charge de vieilles anomalies
pas prise en charge car il y a un différentiel entre la version
déployable en entreprise et celle qui fait l'objet de la majorité des
développements à un moment t.
Sauf que cela ne fonctionne pas parce qu'il n'y a pas assez
d'entreprises autour de LibreOffice qui participent comme Collabora. Et
donc le support se fait sur ce dont a besoin leur client et cela laisse
toute une cargaison de bugs et de régressions de côté. Les entreprises
qui corrigent des bugs uniquement pour leurs clients, sans reverser au
tronc commun rendent leur client, TDF et l'écosystème perdants.
Les utilisateurs donnent à la Fondation et pas suffisemment aux
entreprises de l'écosystème.
C'est la réflexion qui est menée actuellement via le plan marketing. Et
les questions que j'ai posées à Thierry sont pour appeler de vraies
réponses. Ce modèle que nous avons construits depuis 10 ans montre des
dysfonctionnements. La communauté ne va pas les laisser ainsi, nous
tenons tous à la fondation et à ses valeurs.
Mais il faut partir de la réalité de la fondation et de ses statuts, de
LibreOffice et de l'environnement économique qui est autour. Tout en
continuant de développer la communauté, en laissant assez de liberté aux
contributeurs tout en les accompagnant, etc.
Autant les changements de versions correctives doivent être assez
"simple" à déployer en entreprise, autant un changement de version
demande un peu plus de vigilance, il doit donc être moins fréquent.Sauf qu'ici on ne parle pas du tiroir caisse de TDF mais de celui
deceux qui écrivent le code de LibreOffice. Quelle solution pour
obligerces entreprises à travailler pour TDF/LibreOffice plutôt que
pour leursclients ?Il y a l'idéal et la réalité, mais tu sous entend qu'on arrive à la
situation ou le développement est quasi exclusivement porté par ces
entreprises (et donc qu'il faut les "obliger" à travailler pour
LibreOffice) ?
Oui, environ 80% du développement est fait par Collabora et CIB. Les 20%
restant étant d'autres entreprises, des bénévoles ou Google Summer of
Code. Il n'y a pas de code écrit par TDF (ou très peu et pas directement
dans le coeur de LibreOffice comme les unit tests par exemple).
Même si je l'ai lu attentivement le doc en question que tu as fourni il
y a quelques jours, je suis restée sceptique, sur cette nouvelle entité
"TDC". J'ai du mal avec le commercial à but non lucratif, le
reversement, et les interactions décrites...
Pourquoi faut-il une entité distincte pour gérer les applicatifs TDF
(visionneuse Impress, Applis smartphone...) ?
Il y a plusieurs raisons à cela. TDF a de l'argent (voir les détails
dans le rapport d'activité
https://nextcloud.documentfoundation.org/s/LEat3j6nepdggNk#pdfviewer).
TDF a l'obligation de dépenser dans les deux ans l'argent qui entre.
L'une des raisons déjà évoquée est la difficulté à mener des appels
d'offres par TDF : difficulté techniques de formulation, difficulté
parce que conflits d'intérêts, difficulté d'évaluation finale, etc.
Une autre est la structure légale même des stores qui vient en conflit
avec les statuts (je n'ai pas tous les détails en tête) et qui empêche
de publier.
TDF a déjà une société attachée pour certaines opérations commerciales,
mais elle ne suffit pas. D'où le besoin de trouver une structure
indépendante de la fondation, qui soit quand même sous le contrôle de la
fondation. La structure juridique de cette société n'est pas encore
décidée. Ce ne sera visiblement pas une coopérative, d'autres statuts
sont à l'étude comme cette Société à Impact Sociétal au Luxembourg.
Comment se place DLP(Liberation Project...) là dessus ? Car c'est un
projet moins connu, mais travailler sur l'interopérabilité, ce n'est
pas rien, et les entreprises et particulièrement les administrations
clientes pourraient justement avoir un intérêt sérieux sur le sujet....
Document Liberation Project est un projet de TDF tout comme l'est
LibreOffice. La différence c'est que ce sont des bibliothèques qui sont
produites et non des binaires. L'intérêt est surtout pour les autres
communauté open source afin d'intégrer les bibliothèques à leur produit,
les utilisateurs directs sont très peu concernés.
En espérant avoir apporté quelques éclaircissements sur le
fonctionnement de TDF et du projet LibreOffice ainsi que son avenir.
À bientôt
Sophie
Bonjour,
C'est bien ce qui me chagrine, aucune structure qui aurait un impact direct
emploi en France. C'est un constat,
pas une critique, la proposition serait de voir par langue/pays comment
faire.
Il me paraît évident que LO exige un effort de fond, de la recherche et
développement au sens entreprise, on voit
les projets abordés en GSOC, qui ne seraient pour la plupart pas
directement demandés par une entreprise mais qui participent
au rayonnement du logiciel, à sa finition, à l'effet "wahouuu" qui parfois
fait vendre.
On a des structures en France d'utilité sociale, je ne suis pas
spécialiste, donc je ne vais pas m'avancer plus, mais il me semble
qu'on a quelques leviers, je travaille ou suis bénévole dans l'économie
sociale et solidaire, on a arrive à avoir quelques budgets. Le problème est
que trouver
l'argent, c'est un métier de faire des dossier. Il faut répondre à des
appels à projet nationaux ou régionaux, convaincre une région que c'est
innovant et que ça mérite un support
financier. Mais c'est possible.
Bref, une démarche à initier.
Après ce qui semble se vendre, c'est la démarche "plateforme", une suite
d'outils dont la bureautique n'est qu'un élément.
Cdt
Régis Perdreau
Bonjour,
J'ai toujours du mal avec les discussions sur ce sujet. d'un côté, on voit bien l'engagement des bénévoles, qui force le respect.
De l'autre on a l'impression, parfois, qu'on nous demande de nous taire parce que cela démotive les bénévoles de dire que des choses ne vont.
D’ailleurs, on caricature parfois les critiques, pour ne pas avoir à y répondre, ou alors, on répond à la caricature ce qui revient au même.
On part parfois dans de drôle de sophismes.
Il y a u problème, ce problème n'a pas de solution, donc on dira qu'il n'y a pas de problème.
TDF communique beaucoup, globalement, on communique beaucoup autour de LO.
Mais qu'en est-il de la situation de LO, auprès des entreprises, du public ? Comment ça évolue ?
Que pensent les utilisateurs en entreprise et les utilisateurs lambda comme moi de l'évolution de la suite ?
Quelle est la place d'Apache OpenOffice ?
Quoi qu'on en dise, OpenOffice reste une suite, et surtout un nom. Lorsqu’un pékin lambda (pléonasme) recherche un outil de bureautique libre, il tape OpenOffice.
Aujourd'hui, il y a encore des gars, qui arrivent pour faire du développement sur leur temps libre sur OpenOffice
On me répète à chaque fois que TDF ne peut pas intervenir sur le code, pourtant TDF finance des actions sur le code :
https://blog.documentfoundation.org/tenders/
Pourquoi TDF ne pourrait pas financer de la même façon des actions pour des résolutions de bugs qui en sont pas pris en compte par les entreprises mais qui gêne les utilisateurs lambda
On peut imaginer un système de votes proportionnel à la somme donnée à TDF, en piochant uniquement sur les régressions pourrait aussi donner de l'argent, mais sans indiquer de correction de régression, on peut aussi imaginer un tri en amont, pour éviter de se perdre dans plus de 1300 régressions ? on peut imaginer une demande de correction sur un OS particulier. Bref, cela permettrait d'impliquer les utilisateurs lambda.
Je ne suis pas radin, je ne sais plus combien j'ai donné à Grammalecte, mais c'est bien plus que le prix d'Antidote par exemple, j'ai aussi donné à Wikipédia ou Xnview par exemple.
Par contre, je crois n'avoir fait qu'une fois un don à TDF, lorsqu'une version était sortie avec moins de régression que la précédente
Ce pourrait d’ailleurs être un indicateur. Sortie de la version n tant de régressions, sortie de la version n+1 , il y en a tant en moins (youpi !) ou tant en plus (dommage)
Bref, cela part d'un constat :
Est-ce que le nombre de régression est un problème (1300 trucs qui fonctionnaient mais qui ne fonctionnent plus) ?
Et là, on évite de répondre que tout va bien puisqu'on ne peut pas y remédier.
Si oui, comment on fait pour s'y attaquer ?
Et, s'il faut modifier les status de TDF pour y arriver, pourquoi se l'interdire ?
Enfin, je n'ai pas eu de réponse sur l'abandon de Firebird, je n'ai pas vu ou cela avait été discuté, j'ai juste remarqué qu'on en parlait plus à l'ESC. c'est comme pour OpenCL, dont on ne sait pas trop ce que c'est devenu.
Il y avait pourtant sur ces deux sujets des annonces dithyrambiques, et TDF a financé le script de transition de HSQLDB vers FireBird si je ne me trompe
Pierre
Bonjour,
Je cite in-extenso Patrick Auclair qui m'a donné la solution au début de l'année. J'ai essayé d'éditer content.xml, mais je ne suis pas parvenu à recréer l'archive ensuite.
Je suis donc passé par la macro, ça a marché. Encore merci à Patrick,
Thierry
Bonjour
Et si on lançait simplement un financement participatif pour résoudre les régressions ?
Chaque participant vote et le poids de son vote est proportionnel à son don. On verra après ce qu'on peut faire avec l'argent récolté.
À qui on confierait le boulot ? Quelle garantie a-t-on que la mise à
jour suivante ne va pas tout péter à nouveau ? Comment s'assurer de la
qualité de travail ?
Bonjour,
Bonjour
Et si on lançait simplement un financement participatif pour résoudre
les régressions ?Chaque participant vote et le poids de son vote est proportionnel à son
don. On verra après ce qu'on peut faire avec l'argent récolté.À qui on confierait le boulot ?
À quelqu'un qui a déjà le droit de commit sur le code source, ce qui assure qu'il est reconnu comme compétent et fiable par la communauté des développeurs de LibreOffice.
Quelle garantie a-t-on que la mise à jour suivante ne va pas tout
péter à nouveau ?
"Tout péter" ? Tu n'en fais pas un peu trop là ? 
Comment s'assurer de la qualité de travail ?
Chaque correctif de bug est censé être accompagné d'un test de non-régression de façon à détecter automatiquement toute résurgence ultérieure du même bug. Ce genre de test est difficile à mettre en œuvre pour le bug sur l'interface, mais pour tout le reste c'est en principe une condition sine-qua-non pour accepter un correctif. Bien entendu un test est d'autant plus aisé à écrire que le bug corrigé dispose d'un scénario de reproduction détaillé et d'un critère de validité sans ambigüité.
Ces tests de non-régression ne garantissent pas que le correctif ne va pas casser quelque chose ailleurs. Normalement le système d'intégration continue qui compile LibreOffice avec chaque nouveau correctif proposé sur toutes les plateformes supportées par LibreOffice, permet de détecter pas mal de problèmes (en particulier ce qui ne compile pas sur une plateforme donnée, ce qui casse un test parmi les centaines existant). Ensuite il faut des utilisateurs avancés pour tester en situation réelle et trouver les bugs résiduels.
Après, comme pour tout travail de commande, il faut établir un cahier de recette qui permet de définir ce qu'on entend par qualité du travail et comment on décide que le travail est réalisé.
Bonne journée
JBF
Je laisserai la tache à TDF. Je lui fais entièrement confiance.
Sinon, je reviens sur le problème d'avenir de la suite suite à la soutenance de stage de fin d'étude de ma fille. Elle a fait son diaporama avec la dernière version stable de LO. mais, elle a souvent travaillé avec PowerPoint. Il y a certains points cruciaux qui manquent selon elles.
Par exemple, pouvoir facilement récupérer des tableaux de calc, les copier dans Impress et après, les mettre aux couleurs de la boite (une couleur par ligne). Il paraîtrait que cette manipulation est automatique sous powerpoint et sous Impress c'était la merde... En effet :
1) ce n'est pas automatique
2) quand elle changeait les couleurs d'une ligne, ça changeait le format des caractères.
je n'ai pas eu le temps de poster un SOS ici car je l'ai su la veille au soir...
Mettre un tableau sous Impress est tout simplement suicidaire.
Ce n'est pas stable, on perd les formats, les polices sans trop savoir pourquoi. Au final, je fais des copies d'écran et je colle des images...
Pierre
Pour les COPIER/COLLER, toujours essayer avec les touches [CTRL]+[V], pour un tableau Calc, il est possible de choisir parmi les options suivantes :
* Classeur LibreOffice 7.0 ► objet Calc (donc éditable sur double clic)
* Métafichier Graphics Device Interface ► une image mais vectorielle,
dont toujours lisible
* Image Bitmap (BMP) ► Une image de base (lourde en mémoire)
* HyperText Markup Language (HTML) ► Utiliser HTML pour conserver les
caractéristiques... généralement pas une bonne idée.
* Texte non formaté ► supprime toutes les mises en formes (très
pratique pour garder la mise en forme de Writer)
* Rich Text Formatting (RTF) ► C'est le format par défaut, mais
effectivement décevant
Donc en clair, CTRL+V et choisir Classeur LO ou Métafichier pour conserver le tableau.
Vous avez aussi le menu Insertion > Objet > Objet OLE (soit nouveau, soit à partir d'un fichier existant)
Cordialement,
David ROUMANET
Elle n'a pas voulue faire cette manip que j'avais conseillée.
C'est un bug reconnu ou il faut le poser.