Comme il est dit dans [1], OpenOffice.org manque de développeurs (seulement 4 issus de la communauté). C'est vrai que 10 000 000 de lignes de C++ ça a de quoi freiner les ardeurs !
L'idée qui m'est venue à ce sujet est la suivante : on a d'un côté 4 mecs qui ont investi du temps pour comprendre comment fonctionne OOo, son architecture, ses principaux composants etc. Par contre ils sont complètement débordés. De l'autre, une masse de développeurs qui n'ont pas cette connaissance, ni forcément le temps ou l'énergie à consacrer à son acquisition, mais qui pourraient "contribuer occasionnellement".
Serait-il possible que les "gourous" d'OOo, plutôt que de développer, fassent un travail de préparation des tâches à accomplir, comprenant :
- isoler une tâche élémentaire (rôle, résultats attendus, interface au sens POO)
- présenter brièvement le contexte de développement
- identifier quelques "ressources" utiles (classes/méthodes déjà faites...)
- etc.
Une fois la tâche saucissonnée et emballée, un développeur motivé prend la réalisation en charge. Il n'a pas à priori besoin de connaître autre chose que ce que le gourou a préparé (enfin, si, le C++, tout ça...). Il réalise un développement unitaire correspondant au besoin, et le soumet au gourou.
On peu imaginer un certain nombre d'itérations avant d'arriver au résultat impec (vu que le développeur ne testerait pas forcément son boulot avec le reste du code d'OOo). En prime le gentil développeur pourrait documenter son bout de code (interfaces, algos de haut niveau, etc.). En plus avec le temps il en saurait de plus en plus sur le code d'OOo, et il finira peut-être par devenir gourou à son tour...
Voilà, en résumé ceux qui ont la connaissance globale s'occuperaient de gérer ça à un niveau global, et "laisseraient" le développement à une autre équipe...
Je n'ai jamais bossé sur un projet de l'envergure d'OOo, donc je peux très bien être en train de raconter plein de conneries, c'est peut-être irréaliste, mais dans le cas contraire... Wow !
A votre avis, ce genre d'organisation a une chance ?
[1] http://linuxfr.org/2005/04/21/18781.html(...)
Journal idée (à la noix?) pour OOo
21
avr.
2005
# l'idée parait satifaisante.....
Posté par cosmocat . Évalué à 2.
1. pour une correction de bogue (là où est le problème actuellement), ça prends peut-être plus de temps d'identifier le probleme, de tout documenter comme tu le dit que de le résoudre soit même.
2. pour le developpement de fonctionnalités, la connaissance peut être trop vaste pour pouvoir faire tout le travail de préparation que tu demande.
par contre:
1. ça permettrait de mettre le fil à la patte à de nouveaux developpeurs en les aidant à s'integrer.
2. KDE, il me semble à un système similaire où des taches de programmation simple sont identifiées et laissée pour les nouveaux contributeurs donc ça doit être faisable.
Faut voir!
PS : je connais pas plus le contexte que toi, j'imagine.
# mouaif
Posté par patrick_g (site web personnel) . Évalué à 6.
Moi je penche surtout pour un arrêt du travail sur OOo.
Si on se tourne vers Koffice ou Abiword/Gnumeric on évite tous les problèmes (vieux code difficilement maintenable, copyright donné à Sun, intégration forcée de Java, API spécifique).
[^] # Re: mouaif
Posté par Ph Husson (site web personnel) . Évalué à 7.
Et de faire les programmes par dessus après
Il parait que les auteurs de kspread et gnumeric pouraient déjà faire ca
[^] # Re: mouaif
Posté par plagiats . Évalué à 3.
Tu veux dire ... ?
c'est techniquement faisable mais ils ne le font pas
la rumeur veut qu'ils seraient en train de le faire
Sinon pour l'auteur du journal: mmmmh, le gros problème de ton système c'est que les 4 gourous sont avant tout des développeurs, et les développeurs ca développe. Alors si tu demandes aux quatre gourous "stop, arretez tout et documentez le code" je ne suis pas sûr qu'ils acceptent. Par contre pour régler un problème donné ca peut être pertinent de faire appel à la communauté, mais c'est un peu le principe de bugzilla non?
[^] # Re: mouaif
Posté par Ph Husson (site web personnel) . Évalué à 3.
s/pouraient/seraient entrain de/
[^] # Re: mouaif
Posté par Bruce Le Nain (site web personnel) . Évalué à 3.
Ceci d'autant plus qu'il me semble avoir lu quelque part que les dev de Gimp s'orientent vers une séparation de la couche de traitement d'image et de la gestion de l'affichage des fenêtres et icônes. Si c'était le cas, le logiciel pourrait aussi bien être intégré dans KDE, Gnome que Ouine ou MacOS, pour n'en citer que quatre.
# Loi de Brooks
Posté par Julien MOROT (site web personnel) . Évalué à 3.
Pour rappel, cette loi énonce que rajouter des développeurs à un projet en retard ne fait qu'accentuer le retard du fait que les impératifs de communications venant accentuer ce retard.
http://www.linux-france.org/prj/jargonf/B/Brooks_Frederick_P.html(...)
[^] # Re: Loi de Brooks
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Bref, c'est le même soucis que la programmation de cluster de calcul :)
"La première sécurité est la liberté"
[^] # Re: Loi de Brooks
Posté par BAud (site web personnel) . Évalué à 2.
Franchement, plutôt qu'expliquer 10 fois ou 100 fois la même chose autant l'écrire une fois (ça prend du temps) et ensuite la mettre à jour régulièrement ça coûte toujours moins cher que d'expliquer toujours la même chose... et surtout ça permet de refourguer la doc' à ceux qui ont envie d'en faire (d'un point de vue de développeur qui ne voudrait que développer).
[^] # Re: Loi de Brooks
Posté par Julien MOROT (site web personnel) . Évalué à 0.
Ici, les fonctionnalités sont plus ou moins terminées et OOo est plutôt entré en cours de débuggage.
Sachant qu'OOo est déjà en retard, la documentation n'ajoutera que du retard. Ce n'est pas comme si le projet en était à son début et qu'un nouveau contributeur X souhaite ajouter une fonctionnalité non prévue ou pas encore codée et donc il ne ralenti pas (moins?) les autres développeurs à travailler en parallèle.
[^] # Re: Loi de Brooks
Posté par Gniarf . Évalué à 3.
# Ingénierie système
Posté par Trick . Évalué à 3.
Avec des méthodes de modélisation comme Merise/UML (étape après les specs) elle crée les boites qui vont bien.
Ces descriptions de boites sont données aux différents groupes de développeurs. Ils ont ce que doit faire la boite, les données qu'ils doivent manipuler ainsi que les méthodes qui leurs sont accessibles...et rouler jeunesse.
Bon, ça c'est un travail en amont dans un monde idéal.
Pour OOo, une société comme SUN, carré/procédurier à l'américaine, doit avoir ce modèle de fonctionnement. Et sans doute l'est-ce pour StarOffice?
Sinon partir d'un gros système déjà réalisé et lui appliqué une modélisation est possible mais c'est long. On représente le système existant tel qu'il est découpé et ensuite on tente de le modifier pour le rendre plus modulaire.C'est rarement simple sauf si le système a été bien pensé au départ...
[^] # Re: Ingénierie système
Posté par Yaourt . Évalué à 1.
Tu veux donc donc "l'architecte", un peu comme dans "J2EE Lead Architect" (bises à toi mon Pierrot Tramo :-) )
Pour moi un ingé système c'est plus proche d'un admin système, d'un unix warrior, m'enfin, passons ... comme on dit ici : on en a rien à caguer !
> Bon, ça c'est un travail en amont dans un monde idéal.
Oui, c'est bien çà, on est d'accord sur le fond du problème ...
> société comme SUN, carré/procédurier à l'américaine, doit avoir ce modèle de fonctionnement
perso je ne vois pas le rapport "carré/procédurier" <=> "à l'américaine"
à la rigueur pragmatique et américain comme cartésien et francais mais pour moi ca reste capilo-tracté comme association d'idée ...
c'est par où déjà la [ ] ?
[^] # Re: Ingénierie système
Posté par Trick . Évalué à 2.
Je ne sais pas ce que c'est un lead architect dans J2EE.
L'architecte système crée son schéma sans se prévaloir des technos qui seront utilisés. Le système (en essayant de rester simple) est une composition d'éléments (avec certaines proriétés) en intéraction entre eux.
Ici le système est une suite bureautique. Pour le chimiste c'est un mélange de solutions. Pour le garagiste c'est un moteur...
Des fois il faut en caguer comme ça on sait qu'on parle de la même chose.
>> Bon, ça c'est un travail en amont dans un monde idéal.
>Oui, c'est bien çà, on est d'accord sur le fond du problème ...
Il existe quand même des sociétés qui s'en rapprochent.
Certaines suivent tellement ces règles de qualité qu'elles ne font rien d'autre...
>perso je ne vois pas le rapport "carré/procédurier" <=> "à l'américaine"
Sisi procédurier.
Les américains sont très règlement.
Et ce que j'ai vu jusqu'à maintenant il y a un employé par tâche "élémentaire" (et il ne fait rien d'autre). En France nous sommes généralement multifonctions.
# Proposition comme ça...
Posté par revponpuneq . Évalué à 1.
J'ai proposé à Chantal Bernard Putz de contribuer à un topic sur la méthodologie du libre lors de RMLL. Mais on pourrait aussi y faire une espèce de "Topic développement OOo", sans forcément avoir un horaire à la clé.
Après tout, les RMLL, c'est aussi fait pour ça..
Par exemple, je propose d'essayer d'apporter des réponses à ceux qui n'osent pas, ou veulent en savoir plus...le tout est de s'organiser.
On pourrait alterner les confs et les ateliers.
Des idées d'ateliers :
- comment fonctionne le projet OpenOffice.org (les projets)
- description de l'arborescence (diagramme des dépendances) : ce qu'il y a dans les sources, comment ça compile...
- les outils pour la compilation
- comment retrouver une issue, comment entrer un issue
- comment communiquer, à qui demander
- les patches
- le code (styles...etc)
- comment commiter (je pourrai même illustrer )
C'est peut-être un peu maladroit/incomplet, mais l'idée est là
Bien sur, étant moi-même asse au courant des points énooncés plus haut, je me porte déjà volontaire pour participer, mais j'espère que d'autres seront intéressés.
Enfin, c'était juste une proposition, comme ça...
--
eric bachard
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.