Discussion :

[grunt2000]

Bonjour,

En ce début 2011, un an et demi après un gros sujet ouvert sur ce forum (à l'occasion de la génération de GeoToolKit) je voulais savoir où allait le vent.

En effet, je peine à me choisir une API et à m'y tenir.

Openmap 4.6.5
Si on entre facilement dans cette API, elle aurait nettement moins de fonctionnalités que les autres. Est-ce pour autant que l'on touche ses limites rapidement?

GeoTools 2.6
La référence. Il parait qu'elle fait souffrir pas mal de gens parce qu'elle n'est plus très stable. Difficile de s'y fier, alors. Elle avance pourtant en versions... mais est-ce qu'elle se répare?

GeoToolKit 3.16
Issue d'une scission, ce serait elle la remplaçante?
Triple zéro pour la doc: en dessous de tout.
GeoToolKit fonctionne selon quels principes? Mystère. Comment l'utiliser alors?


D'autres candidats en lice, pour Java désormais?

Grunt.

[boreal]

Bonjour Grunt2000,

Je n'interviendrai que pour la partie qui me concerne à savoir Geotoolkit.

Tout d'abord concernant la documentation :
Geotoolkit est une bibliothèque de programmation, ce pourquoi nous avons avant tout, mis l'accent sur les outils permettant d'aider les développeurs au quotidien, et en premier lieu une javadoc à jour, et la plus complète possible.
Le projet Geotoolkit est scindé en deux modules, Geotoolkit et Geotoolkit-Pending de façon à permettre aux développeurs d'identifier les classes stables robustes et parfaitement documentées (Geotoolkit) des classes en cours de maturation tant du point de vue technique que de leur documentation (Geotoolkit-Pending). Tu pourras très facilement vérifier tout ça aux URL suivantes. http://javadoc.geotoolkit.org/
http://pending.geotoolkit.org/apidocs/index.html

Concernant des tutoriels et de la documentation utilisateur de plus haut niveau, ce n'est malheureusement pas notre priorité immédiate car nous préférons nous concentrer sur la robustesse de la bibliothèque en elle même et le développement de nouvelles classes. La raison en est simple, l'ensemble des développeurs qui travaillent à la réalisation de Geotoolkit vivent des travaux qu'ils réalisent à partir de cette bibliothèque et non pas du succès qu'elle rencontre auprès de la communauté des développeurs, leur priorité immédiate est donc la qualité "technique" des outils plutôt que leur documentation "grand public".
Nous sommes toutefois pleinement conscient que le succès de Geotoolkit passe aussi par sa documentation et nous cherchons à aller dans ce sens. Nous travaillons en ce moment sur la refonte des outils de documentation pour ce projet, et bientôt http://jira.geotoolkit.org devrait être associé à un wiki permettant aussi à des personnes motivées, de nous aider à constituer une documentation digne de ce nom (c'est du logiciel libre, n'hésitez pas à collaborer).

Concernant les principes de fonctionnement de Geotoolkit, tout est expliqué sur son site http://www.geotoolkit.org, le projet est sous licence LGPL2 et les sources sont disponible via un repository mercurial http://hg.geotoolkit.org, tu as là, toutes les garanties te permettant de faire tes développements en totale liberté.
Si tu souhaites participer à son élaboration, c'est comme pour tout projet libre, il faut faire preuve de tes compétences avant d'obtenir des droits de commit, avant cela, tu peux soumettre des patchs, de la doc, bref tout ce qui pourra apporter au projet en retour de ce que celui-ci t'apporte.
Je précise par ailleurs qu'il n'est pas nécessaire de signer une quelconque rétrocession de copyright à l'entreprise à l'initiative du projet, en revanche nous pensons sérieusement proposer cette rétrocession vers un organisme tel que l'OSGEO ou la FSF.

Je précise aussi que pour des questions d'ordre technique, la liste de diffusion du projet se trouve ici : http://www.geotoolkit.org/mail-lists.html (hébergée par l'OSGEO).

Voilà, j'espère avoir répondu à toutes tes questions.

A bientôt sur Geotoolkit j'espère,

Vincent Heurteaux
Geomatys

[grunt2000]

GeoToolKit:
Je suis tout à fait d'accord qu'il faut faire une API de qualité. C'est essentiel.
Mais la Javadoc + l'étude de sources d'exemples (qui ne couvrent jamais l'ensemble de ce que l'on voudrait) ne peut pas suffire pour la diffuser largement.

L'absence de documentation est un argument qui pouvait être entendu aux débuts de GeoToolKit. Mais là, un an et demi a passé. Ça devient sérieux!

J'ai l'impression que GeoToolKit est réservé à un cercle de personnes qui a pratiqué GeoTools avant, et que celle-là seule est à même de comprendre comment ce dernier doit fonctionner.

Projet non documenté = même valeur qu'un projet non testé ou non deboggué.
Paresse équivalente.

Ce qui me fait réagir vivement, c'est que deux fois (cette fois-ci et dans le message datant d'un an et demi) je lis en réponse: "c'est un projet collaboratif, donc vous pouvez venir nous aider si vous voulez avoir de la doc."

Non. C'est aux développeurs sérieux de produire leur documentation bonne et utile en temps et en heure. À mes yeux, c'est votre travail prioritaire. C'est pas la peine d'éluder: personne ne veut s'y mettre. Mais il va falloir que vous vous discipliniez. Votre site fait très pâle figure: il laisse croire que votre API, vous n'y croyez tout simplement pas!


Grunt

[boreal]

Grunt,
Une entreprise, et des développeurs sur leur temps libre, font l'effort de te mettre librement a disposition le fruit de leur travail et tout ce que tu trouves à faire c'est de les traiter de paresseux indisciplinés tout ça parce que tu voudrais qu'on te fournisse tout cuit, un projet prêt a commercialiser afin que tu puisses travailler tranquillement et gratuitement dans ton coin !?!

Pour ton info Geotoolkit est utilisé par plusieurs organismes tel que le NERC, SAAB, la NOAA, l'IMR ... (pour ceux que nous connaissons), les personnes avec lesquelles nous avons été en contact se sont très bien accommodé de l'absence de documentation utilisateur même si je te l'accorde cela a constitué un frein à son adoption au départ. Nous les avons aidées à prendre en main l'outil sans contrepartie car c'est l'esprit du libre, et nous continuerons à le faire.

Maintenant, concernant le site et les aspects "Marketing", (là je prend mon bâton de chef d'entreprise), je préfère très largement satisfaire mes clients (qui indirectement financent Geotk) en mettant mes ressources sur la qualité du code et de la Javadoc, plutôt que de dépenser ces ressources financières à faire passer le projet pour ce qu'il n'est pas.

Un autre effet de bord de cette démarche, c'est que les personnes qui collaborent spontanément à ce projet effectivement moins accessible que d'autres, sont bien souvent d'un bon niveau car justement, elle ont pour réflexe de lire la javadoc et d'étudier le code. Crois mois pour l'avoir vécu par ailleurs, il est préférable d'avoir un contributeur de bonne qualité que 10 commiters médiocres.

Tout ceci n'est pas figé bien entendu. Comme je l'ai dit précédemment, nous avons l'intention de développer la documentation de ce projet, mais comme une grande partie des développements de la bibliothèque est portée par une entreprise dont les ressources ne sont pas infinies, la priorité va donc à la qualité de l'outil plutôt qu'à le rendre facilement accessible.

J'ai aussi conscience que rendre la bibliothèque plus populaire serait un atout commercial pour l'entreprise, mais tout est affaire de priorités.


Vincent

[boreal]

Je viens de réaliser que c'est le dernier troll de l'année, je suis tout triste

http://www.geotoolkit.org/images/logos/Troll.jpg
On lui cherchait un nom, je trouve que Grunt lui irait bien.

[grunt2000]

Tu n'as pas tort. Grunt vient d'un des monstres de Gauntlet, le jeu d'arcade. C'est celui qui a une masse et tape sur tout ce qui bouge.

Néanmoins, tu énonces toi-même le problème:
1) L'absence de documentation est frein au départ.
2) Les personnes qui ont utilisé GeoToolKit, vous avez du les aider à le prendre en main.

Que dire de plus?

Que des développeurs s'associent en prenant sur le temps libre de réaliser quelque-chose, c'est louable. Je ne m'épargne pas moi-même pour aider notre communauté, sois en sûr. Mais ça n'empêche pas que les choses qui sont faites doivent être bien faites. Surtout quand vous mettez en exergue que vous êtes très exigeants sur la qualité des committers. Pourquoi tout le reste est en plan, alors?

Parce que le problème de fond, il est le suivant: si chaque utilisateur de votre API (moi, un autre...) doit passer 2 heures à comprendre ce qu'il aurait du intégrer en 20 minutes, alors c'est 1 h 40 de perdu par utilisateur. Multiplié par un grand nombre d'utilisateurs = temps plus grand encore que celui que vous avez consacré à développer l'ensemble. Et personne n'a à vous payer ce prix là (la perte d'1 h 40) simplement parce que vous n'avez pas fait ce que vous auriez du faire. Même si c'est gratuit!

Pour le moment, vous me donnez l'impression de vouloir faire un projet en interne, un peu en mode "club". Pour y accéder, il faut payer un tribut qui va jusqu'à étudier le code source de GeoToolKit et demander une assistance de l'un de vos membres. Comment cela peut-il être soutenu longtemps, comme manière de faire?

Il faut que tu fasses la différence entre:
- Les membres de ton projet, que tu choisis comme tu veux, et qui doivent étudier le code source et faire leurs preuves de mille façons, certes.

- Et les utilisateurs finaux de l'API, que quand même - pardon! - il faut servir au mieux. Ou bien cela n'a aucun sens. Il n'y a pas d'histoire de gens qui doivent sacrifier des heures en lecture de javadoc et de code sources pour être éligibles à l'utilisation de GeoToolKit. C'est une bêtise, ça.
Exactement parce que pour reprendre tes termes: Oui, je veux une API que je peux utiliser toute cuite. Et tout le monde veut cela. Open Source ne doit pas signifier bidouillage, bricolage et débrouille permanente. Quand ils sont ainsi, c'est qu'ils ont été publiés pas prêts.
Les projets open source modernes, doivent faire ce qu'ils doivent, mais aussi être accessibles. Pourquoi tenter de se justifier de faire quelque-chose d'inaccessible?


Je comprends qu'il y a eu un schisme entre GeoTools et GeoToolKit. C'est pour cela que le côté réalisation technique est si mis en avant. C'est n'est pas une mauvaise chose. Mais ça ne fait pas tout.

Enfin, je suis habilité comme n'importe qui à vous juger, puisque vous mettez en public votre production. Vous pouvez rester crispés. Mais ça vous avancera à quoi? À passer pour des divas?

Ce n'est pas la peine de répliquer "Ha, Grunt ignoble! Tu dis ceci, tu es cela!". Sûrement, que je le suis! Et pire encore certainement!
Mais la doc, les tutoriels, les pages de démonstrations, vous devez les faire. Vous ne pouvez pas y couper. Vous êtes obligés de vous y mettre.

C'est le propre des développeurs de ne pas aimer faire de la doc.
Mais va falloir y passer.


Grunt.

[boreal]

Bon aller après j'arrête,

Le seul truc qui me choque vraiment dans ce que tu dis c'est :

Parce que le problème de fond, il est le suivant: si chaque utilisateur de votre API (moi, un autre...) doit passer 2 heures à comprendre ce qu'il aurait du intégrer en 20 minutes, alors c'est 1 h 40 de perdu par utilisateur. Multiplié par un grand nombre d'utilisateurs = temps plus grand encore que celui que vous avez consacré à développer l'ensemble. Et personne n'a à vous payer ce prix là (la perte d'1 h 40) simplement parce que vous n'avez pas fait ce que vous auriez du faire. Même si c'est gratuit!

Mais je te rassure, personne ne nous paye ces 1h40, le temps que tu perds ne nous rapporte rien.

simplement parce que vous n'avez pas fait ce que vous auriez du faire.

Vas y, tapes du pied tant que tu y es , pourquoi tu ne devrais pas toi investir ce temps là, et la société ou les développeurs qui portent ce projet le devraient ?
C'est un projet LIBRE, tu es libre de l'utiliser (ou pas) comme bon te semble, et nous de le développer comme bon nous semble. Nous ne devons des comptes qu'aux clients qui nous payent pour effectuer des réalisations, à toi, nous offrons simplement le résultat des développements sur cette bibliothèque sans aucune garantie ni obligation concernant les livrables.

Je comprends tout à fait ton point de vue et je le partage, IL FAUT DE LA DOC !
Et tu as entièrement raison, l'assistance sur les forums ou les listes à effectivement ses limites et une bonne documentation diminue les sollicitations auprès des développeurs du projet. Le fait est que la liste Geotk n'est pour l'instant pas une grosse source de dérangement, il n'y a donc pas péril en la demeure.
Nous allons tout faire pour que Geotoolkit ait une documentation digne de ce nom. Il faut simplement comprendre que nous ne mobiliserons des ressources dessus que lorsque ce sera possible pour nous. Ce n'est pas une question d'élitisme, juste de raison et de pragmatisme.

Vincent

[eclesia]

Je ne vais pas contredire aucun des avis ci dessus, étant ou ayant été developeur sur geotools et geotoolkit.

J'ai deja beaucoup donné en ce qui me concerne, et aujourdhui encore j'ai au moins 2 à 3 étudiants/stagiaire différent chaque mois qui me posent des questions sur Java+SIG. Auxquels j'envois des applications completes, des exemples ou des pistes.

Quand j'etais encore étudiant j'ai commencé le projet AlterSIG, puis j'ai joins geotools en developpeur benevol et fini par atterrir chez geomatys.

Durant toute cette periode : environ 5 ans. combien de nouveau developpeurs benevol on joint Geotools ou Geotoolkit ? pas un, pas un seul ! les équipes de developpement des deux projet n'ont quasiment pas changé depuis. se sont les memes developpeurs qui travail a la fois sur les librairies (geoapi/geotoolkit/geotools) que les applications finales (mdweb/constellation/geoserver/...).

Je le vois bien avec le projet Puzzle-GIS. faire le site web, la doc, le code etc... sur son temps libre, c'est dure. Il y a beau eu avoir des encouragements et des felicitations sur AlterSIG, combien sont venu mettre une brique a l'edifice ? personne.

J'ai moi aussi cru que la communauté apporterai quelque chose, mais j'ai baissé les bras. La communauté n'est jamais contente tant que ca ne marche pas parfaitement bien et qu'elle n'arrive pas a l'utiliser sans lire la doc.
La communauté remarque vite les petits defauts d'une application et les multiplient par 100. Alors que si tu mets du "eye-candys" qui ne sert techniquement a rien, la communauté s'émerveille.

Ceux qui fait vraiment progresser un projet c'est les rares passionnés qui se cache dans cette communauté, il n'y en a qu'une poignée. Ajoute a cela qu'ils doivent s'y connaitre un minimum en Java et soi pret a s'invertir un peu et il n'en restera quasiment aucun.

Alors il ne reste qu'une solution : faire les choses soi meme, ce que j'ai fait.
Et le plus fort c'est que certain de la communauté trouve le temps de critiquer directement ou indirectement mes efforts, belle communauté.

[Jérôme_C]

Ceux qui fait vraiment progresser un projet c'est les rares passionnés qui se cache dans cette communauté

À force d'entendre ce genre de discours, et d'une manière générale qu'un projet libre avance sur le temps libre de développeurs passionnés, j'ai longtemps cru qu'un projet libre c'était avant tout une assemblée virtuelle de geeks cloitrés dans leur cave où seul le PC brille dans la nuit, vous savez, le genre à lire la matrice en hexadécimal la nuit, et à être un banal employé de bureau le jour

La raison en est simple, l'ensemble des développeurs qui travaillent à la réalisation de Geotoolkit vivent des travaux qu'ils réalisent à partir de cette bibliothèque

Or j'ai découvert depuis peu ce genre d'arguments Un projet libre, ce ne serait que le produit commun de ce qu'a commandé une série de clients. Et donc un projet libre se construit plutôt le jour que la nuit !

C'est beaucoup moins punk comme idéologie, mais j'ai beaucoup plus envie de croire ce type de discours : le libre, ce ne sont que des entreprises qui investissent et ont un retour financier autre que la rente d'un patrimoine, des clients qui ne réclament pas la propriété exclusive du travail demandé.

Il faut que tu fasses la différence entre:
- Les membres de ton projet, que tu choisis comme tu veux, et qui doivent étudier le code source et faire leurs preuves de mille façons, certes.

- Et les utilisateurs finaux de l'API, que quand même - pardon! - il faut servir au mieux. Ou bien cela n'a aucun sens. Il n'y a pas d'histoire de gens qui doivent sacrifier des heures en lecture de javadoc et de code sources pour être éligibles à l'utilisation de GeoToolKit. C'est une bêtise, ça.
Exactement parce que pour reprendre tes termes: Oui, je veux une API que je peux utiliser toute cuite. Et tout le monde veut cela. Open Source ne doit pas signifier bidouillage, bricolage et débrouille permanente. Quand ils sont ainsi, c'est qu'ils ont été publiés pas prêts.
Les projets open source modernes, doivent faire ce qu'ils doivent, mais aussi être accessibles. Pourquoi tenter de se justifier de faire quelque-chose d'inaccessible?

On parle de quoi ici ? De projets vendus ou de projets libres ? Qu'est-ce que la modernité vient foutre ici ?

Après avoir acheté chez ESRI une application propriétaire fournissant une API, j'ai essayé de l'utiliser, et là au niveau documentation, je n'ai absolument pas été déçu ! J'ai payé et j'ai utilisé avec bonheur une API !

Avec un projet OpenSource mon réflexe lorsque je vois une documentation défaillante, des fonctions manquantes, c'est d'espérer que j'aurais le temps de m'investir dans mon projet dont m'a chargé l'entreprise dans laquelle je travaille, de telle façon à ce que je puisse changer cela.

Certes ma première réaction est de pester sur ces conn**** de développeurs qui ne pensent qu'aux fonctionnalités, utilisés par ceux qui ont déjà assimilé le projet. Mais finalement le développeur on le paye pour certaines choses et pas d'autres. Si le client ne veut pas de documentation, juste quelque chose qui fonctionne, qui doit-on blâmer ? Le chef de projet qui n'a pas su mettre en avant la nécessité de consacrer un budget à la doc, ou le client qui n'a pas voulu donner plus et réclamer une documentation ?

Au final on est tous un peu fautif. Et si on perd 1h30 pour assimiler l'API alors qu'en 15 minutes avec une doc ça aurait été mieux, alors on l'a fait soi-même cette doc, et comme ça cette heure et demi de perdue se transforme en investissement au service de la communauté du projet. Parce qu'un membre du projet finalement, ce n'est pas forcément un committer. Si c'est un utilisateur final qui fait des tutoriels et de la documentation bien faite, c'est tout aussi bien !


Un joli sujet troll de fin d'année, on répète beaucoup de choses, mais es fois j'ai l'impression que certaines choses ne sont pas assez répétées

[grunt2000]

Le minimum est que je poste quand même le message pour vous souhaiter la bonne année!

[eclesia]

À force d'entendre ce genre de discours, et d'une manière générale qu'un projet libre avance sur le temps libre de développeurs passionnés, j'ai longtemps cru qu'un projet libre c'était avant tout une assemblée virtuelle de geeks cloitrés dans leur cave où seul le PC brille dans la nuit, vous savez, le genre à lire la matrice en hexadécimal la nuit, et à être un banal employé de bureau le jour.

J'ai envi de dire que oui, (si on exclu la caricature ). Seulement dans mon cas je fais le meme travail au boulot que chez moi . La difference c'est que coté boulot on doit prendre une vision a court/moyen terme bien plus souvent qu'a long terme, raison economique oblige.

Meme la je suis en vacances et je n'arrete pas de penser a comment resoudre proprement un certain probleme, ce qu'il serait tout simplement impossible si je me limitais au simple temp de travail. Quelqu'un qui se moquerai de son boulot (un banal employé de bureau) ne trouve pas la motivation pour faire ca.
Ce que je vais dire un sans doute polemique, mais il y a encore cette idée profondément ancré dans les esprits francais que "Travailler c'est fatigant" et "l'ecole ca fait c..." . Sans cité personne, mais le resultat est logique : ca donne des developpeurs sans conscience professionnelle.

J'ai cent fois plus de plaisir a travailler avec les 3 autres passionnés de ma boite qu'avec tout les autres.