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.