Open-sourcer infoclimat

[frerestoque]

Bonjour à tous,

 

Je viens de m'inscrire sur infoclimat pour pouvoir accéder aux API que vous proposez (pluie/vent/température).

J'ai lu quelques articles/post sur le forum et je suis tombé notamment sur celui qui mentionne la charge de développement qui est trop élevée pour le/les quelques devs qui font ça sur leur temps libre. J'ai vu également que depuis janvier cela a bougé avec le recrutement d'un dev en interne ?

Enfin j'ai lu que vous aviez une application mobile (que je n'ai pas testé) et qui est maintenue par un prestataire externe (et donc probablement payant pour votre association).

 

Avez-vous envisagé de rendre open-source tout ou partie de vos applications afin de permettre à des développeurs de participer au projet de manière ponctuelle sans nécessairement entrer à 100% dans l'association ?

Cela n'empêche pas d'avoir une direction technique très claire et gérée en interne par infoclimat. Cela faciliterait également le suivi des bugs/améliorations des applications.

 

Est-ce que cette approche a déjà été envisagée (je n'ai pas trouvé d'information dans le forum, désolé si cela a déjà été évoqué) ?

Bravo pour l'énorme travail qui a été fait pour toutes vos applications

 

Thibaud

 

 

[Sebaas]

il y a 41 minutes, frerestoque a dit :

Avez-vous envisagé de rendre open-source tout ou partie de vos applications afin de permettre à des développeurs de participer au projet de manière ponctuelle sans nécessairement entrer à 100% dans l'association ?

 

Envisagé, oui! En faire un objectif à terme, probablement oui. C'est clairement une solution efficiente tant pour le site que pour l'asso, par ailleurs tout à fait conforme à nos valeurs d'"opend-*"  

 

Mais pour en arriver là, le chantier technique est littéralement titanesque. Cela suppose quasiment de reprendre de 0 l'architecture technique, "clouder" ce qui peut l'être, mettre à niveau de nombreuses briques middleware, automatiser le déploiement de ce qui peut l'être en terme de code, le documenter... @Fred59_ tient à jour la liste des étapes avant d'en arriver là, et même avec le renfort inestimable que représente Jean (qui a rejoint l'équipe début juillet), il est à craindre qu'il faille quelques années pour en arriver là. 

[Fred59_]

En effet, c'est un chantier que l'on a en tête à terme, mais :

• la base de code est très importante (400.000 lignes environ), et un patchwork assez mal organisé (pas de standards ni frameworks modernes, ce qui perturbe beaucoup de développeurs habitués au "confort" de Symfony, Django, React ou Laravel). Rien d'impossible vous me direz, mais là on est à un niveau qui découragera 99% des contributeurs envisageables, d'autant que de nombreux bouts de code sont bien plus complexe qu'on ne l'imagine (comme je l'esquissais brièvement dans un thread Twitter).
• le déploiement est impossible en-dehors de notre infra existante (dépendances à des partages NFS, à des services locaux accessibles uniquement avec des IP locales), et nécessite le déploiement de nombreux "petits" services annexes mal documentés. Lancer Infoclimat sur une autre infra que celle existante (ie. sur son propre PC) est impossible actuellement, et ne le sera pas avant au moins 1 ou 2 années. Aujourd'hui par exemple, @Naej travaille sur une version de développement qui utilise une partie de codes de développement, une partie de codes de production, et la base de données de production. Le déploiement complet nécessite aussi le déploiement de nombreux systèmes annexes (systèmes de cartographie, moteurs de recherche), là aussi peu documentés, voire des logiciels scientifiques obsolètes ou difficiles à installer (NCL, librairies grib/bufr).
• la sécurité du code est probablement imparfaite ; de nombreux tokens et mots de passe sont présents dans la base de code. Bien que généralement strictement limités à des accès filtrés par IP (adresses locales uniquement), d'autres informations pourraient occasionner des fuites de données personnelles de nos 60.000 utilisateurs si elles venaient à être découvertes. Dès lors, il y a un travail en cours pour isoler ces informations sensibles et les séparer du dépôt de code, afin de pouvoir le publier en toute sérénité. Sérénité relative puisqu'il subsistera nécessairement des vulnérabilités dans le code ; c'est moins grave (la sécurité par l'obscurité, ce n'est jamais une bonne solution, et la mise en opensource permet de lever ces vulnérabilités). D'ailleurs, on a déjà lancé une campagne de bug bounty et rémunéré quelques attaquants ayant trouvé des vulnérabilités avérées.
• le code est auto-hébergé sur notre propre Gitlab, je pense que la contribution serait malheureusement plus facilitée si l'on était sur Github (l'effet "communauté"/récompense), à voir...

 

Bref, il y a encore quelques freins, mais je ne doute pas qu'un jour on puisse y arriver. Au global le manque de documentation et d'automatismes de déploiement est un gros frein ( @Naej pourrait vous faire son retour d'expérience !), et c'est le premier à lever pour éviter que je passe 100% de mon temps libre à aider des contributeurs qui "butent". Je le fais déjà avec notre salarié, mais cela devrait améliorer progressivement la situation.

Il y a bien évidemment aussi la conviction à avoir que certaines plateformes moins regardantes et "concurrentes" nous volent une partie de notre savoir-faire, mais c'est le "jeu". Je dirais que la force d'Infoclimat, c'est aussi et surtout le travail de compilation, d'archivage, de fusion et de correction manuelle des données opéré depuis des années, et ça, le code ne le livre pas tout cuit !

 

J'en parlais brièvement ici :

https://framablog.org/2022/01/25/infoclimat-un-commun-meteorologique-et-climatologique-a-preserver/

https://www.nextinpact.com/article/49607/open-data-infoclimat-association-qui-lutte-pour-ouverture-donnees-meteorologiques 

 

PS : nous sommes ouverts aux propositions de sociétés privées souhaitant œuvrer dans une action de mécénat pour nous aider dans ces actions, d'autant plus si elle se sert de nos données et outils ;o)

[frerestoque]

Merci pour vos réponses Sebaas et Fred !

 

Je comprends totalement la situation avec un si gros projet mais je pense qu'il ne faut pas se créer trop de bloquages et qu'il ne faut pas vouloir "tout bien nettoyer" avant de le partager à une communauté plus large.

 

Je me permet de reprendre tes points @Fred59_ :

• Base de code importante et mal organisée : Ce n'est pas vraiment un blocage pour l'open-source, c'est un blocage pour l'onboarding. Et ça peut être un sujet long terme de refacto pour passer doucement certaines parties sur un framework au fil de l'eau.

• Complexité élevée : Pas un problème pour ouvrir le code. Il y a surement pleins de sujets non complexes à traiter pour que ça vous dégage du temps pour traiter ceux qui le sont vraiment  

• Déploiement impossible en dehors de l'infra (deps locales, ..) : Ce n'est pas non plus un problème pour l'open-source. La communauté peut très bien prendre une problématique (ex: dockeriser un service), et avancer progressivement sans avoir pour autant l'ensemble de la vision du projet. Vous ne pensez pas qu'avoir d'autres devs, ne serait-ce que pour en discuter, ne pourrait pas vous aider à considérablement réduire ce délai ? 

• Sécurité : Les secrets sont effectivement un blocage pour ouvrir le code. Mais ce n'est pas le travail de refacto le plus long. Les failles du code peuvent aussi être un souci au départ.

• Gitlab : Pour ma part je trouve ça très bien GitLab  

A court terme il est clair que vous pouvez pas juste ouvrir le code, mais pourquoi ne pas :

- Garder votre code privé

- Permettre l'accès à votre code source à des développeurs qui en ferait la demande (contre quelques informations personnelles pour vous protéger + signer un NDA + CLA). Cela permet de réduire les risques si le code contient des failles, vous pourriez avoir des avis, et vous seriez peut être même surpris par certaines participations !

- Quand le projet sera prêt, l'ouvrir à tous (dans longtemps effectivement)

 

Attendre des années pour espérer avoir un peu d'aide de la communauté car le projet est 'trop complexe' je trouve ça dommage alors que vous n'êtes pas si loin d'avancer sur le sujet (on parle de retirer les secrets) !

En tous cas, même si mon appel du pied tombe à l'eau pour le moment, c'est super que vous soyez un peu sur le sujet et que vous espérez l'atteindre un jour !

 

 

[_sb]

il y a une heure, Fred59_ a dit :

Il y a bien évidemment aussi la conviction à avoir que certaines plateformes moins regardantes et "concurrentes" nous volent une partie de notre savoir-faire, mais c'est le "jeu". Je dirais que la force d'Infoclimat, c'est aussi et surtout le travail de compilation, d'archivage, de fusion et de correction manuelle des données opéré depuis des années, et ça, le code ne le livre pas tout cuit !

 

Il y a plus de 20 ans, le langage a été ouvert, nous n'avions plus de financements et nous voulions continuer à le voir vivre. Quelques boîtes concurrentes ont profité pour créer des projets concurrents avec, développer quelques bibliothèques supplémentaires obfusquées puis s'en sont écartées et ont utilisé les premiers « frameworks » basés sur d'autres langages modernes (et oubliés depuis). Le code source n'était pas des plus propres, il datait du courant des années 90, l'évolution était très rapide. Finalement, nous nous sommes retrouvés entre nous pour le perpétuer.

L'ouverture, nous avions eu débat entre une licence BSD-like et une GPL (la 2). La BSD a remporté la majorité. Je souhaitais la GPL. Avec le recul, je ne suis pas certain que cela aurait changé beaucoup de choses. Ça envoie quand même une ligne philosophique sur les auteurs du projet...

J'ai stoppé le développement depuis 6 ou 7 ans pour tout autre chose. Je continue à être simple spectateur pour quelques projets ouverts ou libres. J'ai cité ce vieil exemple parce qu'il me semble que les choses n'ont pas fondamentalement changé aujourd'hui.

Il y a des projets phares mais la plupart restent obscurs : le ou les  devs initiaux s'ils sont encore présents, deux ou trois contributeurs occasionnels durant un, deux ans. Réinventer la roue, c'est parfois mieux ou disons, plus facile : quasiment tout passe par des frameworks désormais, qui évoluent très vite et le code antérieur d'un projet devient obsolète si non mis à jour.

Le code d'IC est de la vieille école, celle du sur-mesure, à l'opposé de l'industriel. Se plonger dedans devient rapidement fastidieux, déjà que ce n'est pas une sinécure de se plonger dans un code écrit par un autre... Les devs du sur-mesure deviennent rares. Certains pans pourraient sans doute être contrôlés par des frameworks. Vu l'assemblage, il faudrait interfacer l'ensemble (différents frameworks + sur-mesure restant) pour le rendre cohérent et stable.

En filigrane, il y a l'histoire d'IC qui joue probablement. C'est dans la fondation d'IC. Durant près de 20 ans, utilisant le Do It Yourself avant l'heure, des pierres individuelles ont construit l'édifice actuel, avec un état d'esprit privilégiant cet aspect. Ce n'est pas aisé d'y enfoncer un coin, en prenant des briques de l'extérieur, plus ou moins généralistes.

Perso, la libération de l'entièreté du code, je suis pour à 100%. Ne serait-ce que pour le perpétuer, au cas où l'asso IC venait à disparaître. La question principale serait : dans quel(s) objectif(s) ?

Autant il est facile de libérer un code source dès le départ, autant il est difficile de le libérer ensuite. Et que dire après 2 décennies !

Le plus chiant, pour l'avoir vécu, est de devoir maintenir les contributions (géniales parfois là n'est pas le problème) de contributeurs actifs et qui ont disparu ensuite. C'est vite décourageant. Fidéliser une communauté de contributeurs et contributrices, même si c'est sur un module précis, est une des clés d'une ouverture réussie. IC en sera peut-être capable. Faut ouvrir pour le savoir !