OSS maintenance, what does it means?

I'm  maintaining (and developing!) a few Apache projects:

• Apache MINA: A Java NIO framework
  
• Apache LDAP API : A LDAP Java API
  
• Apache Directory Server: A LDAP server in Java
  
• Apache Directory Studio : A LDAP browser based on Eclipse
  
• Apache Mavibot : A MVCC database in Java

Those are quite old  projects (Apache Directory Server was created in 2004, and incubated in 2005). 20 years old actually!

What does it means in term of effort?

The language

All those projects are written in Java, and it was started using Java 4 (actually, the reason Alex Karasulu started to develop the LDAP server back in 2003 is that it supported NIO, which allowed an unlimited number of connections, something that was quite a limitation with Java 3 blocking IO when it comes to manage thousands of concurrent connections.

We are now supporting Java 8 to 21, which means Java 4, 5, 6 and 7 are not anymore supported.

The question is: why do we still support Java 8? Back in 2023, around 30% of Java users were running their applications based on this version. This sounds insane, but you have to keep in mind that when it works, don't even try to fix it. Also the recent Java release policy has make it so that releases are way more frequent, otherwise we would be around version 10 or 11 today.

Also there are not so many new features since Java 8 that worth the effort. I mean Java 8 already has lambda, and the added features aren't that critical, up to Java 21, which introduced Virtual Threads.

 Last, not least, Oracle has changed its policy so that it was not anymore free to use Java in production (they reverted back since then).

So we are good to go with older version of the language.

Are we?

Dependencies

When it comes with dependencies, the language version matters. For instance, if you depend on SpringFramework, then suddenly you can't migrate to the latest maintained version, 6.X. It requires java 17 :/

So now we are at a cross road, where some dependencies are evolving faster than we can cope with. What can we do?

First of all, check if the dependency is really that necessary. Regarding SpringFramework, it is used in two MINA modules, one containing some examples, the other one is based on a defunct container project (Apache Geronimo Xbean). 

The question is to keep this dependency (and being incapable of updating the dependency) or removing it from the code base (and breaking the API contract).

The thing is that some very old versions of what we maintain are still being used as of 2024. Here is a snapshot of the MINA download statistics for last month. 5% are for a 12 years old version (2.0.7, released in November, 17, 2012!).

Mina download statistics

 

So we are kind of stuck, and expecting users to upgrade to a more recent version is putting a lot of burden on them.

The other problem with dependencies is that even if we don't include them in the release packages, we may use some for tests. I'm thinking about mock libraries, for instance. Making a choice a decade ago stuck you for a very long time, unless you are willing to migrate potentially thousands of tests.

For instance, I have spent 3 months migrating all the MINA and Directory projects to Junit 5 last year. Not the best usage of my precious time :/

The very same with Log 4J which is stuck in an old version (1.X). Migrating to Log4J 2.X would require a massive effort.

What about projects versions?

We maintain more than one version of each project:

• Apache MINA is supported in three versions, 2.0.X, 2.1.X and 2.2.X
• Apache LDAP API is supported in two versions, 1.0.X and 2.1.X
  

 This requires a lot of effort, with some backportings, releases, documentation, including migration howtos.

Is it necessary?

Yes, and no. yes, because when you are committed with a given version, migrating can really be a burden. The API change, the updated dependencies, all are going into your path.

So as a maintainer, you are going to make a choice at some point: when to deprecate a version and tell the users they *must* migrate. 

OTOH, a feature addition or an API change are not that frequent in decades old projects, so switching to a new version is not that frequent either.

The development environment

Projects are getting older, developers are leaving, and you are still around and in charge. This is a volunteer organization, nobody forces you but still: you have to deal with all those external evolution.

For instance, your projects were using SVN, and it's migrating to Git. Load of effort on you side !

Your favorite IDE is also evolving, and some developers are using an IDE you don't like or you do'nt want to spend days to learn. That's also something to deal with.

What about the build tools? We migrated from Maven 1 (yuk) to Maven 2 (slightly less worse) to Maven 3. Some were pushing to switch to Gradle. Still, you have to learn how to use each of those versions, and each of those tools.

GitHub was a big revolution, and nowadays almost all the tickets are submitted through a PR, while we are still using Jira. That means we have to regularly check both environment, and move PR from GitHub to Jira for a better followup: more work!

Did I mention the web site? In the course of 20 years, we moved from a static web site, to a generated one based on Confluence, then to the (now defunct) ASF CMS system, and lastly to Hugo. Again lots of work!

Is it worth it?

Yes! Because thousands of developers around the world are using those projects. Because it's rewarding. Fixing bugs is always an immediate satisfaction.

Bottom line, maintainers are dedicated persons who like keeping a clean place. And I'm proud of being one of them!

 

L'université Française, dans toute sa splendeur...

Ok, c'est pour bosser 6 h par semaine, donc au final, c'est bien payé ! (mieux vaut en rire...)

Le nouveau ministre de l'enseignement supérieur, Thierry Mendions, a du pain sur la planche. Heureusement qu'on a un gouvernement de gauche !

Allez, voici le mail : 

----------------------------------------------------------------------------- 

*OFFRE D'EMPLOI POUR UN POSTE D'ENSEIGNANT-E CONTRACTUEL**-LE*

*Intitulé :** Anglais 11ème section*

Nombre d’heures : 192  heures équivalent TD (réparties sur toute l’année
universitaire)
Rémunération mensuelle brute sur 12 mois: 1152 euros (sans doctorat) ou
1504 euros (avec doctorat)
Affectation : Université de Cergy-Pontoise, UFR LEI, département d'Anglais
LLCE - RER Cergy-Préfecture

Le département d'anglais de l'Université de Cergy-Pontoise recrute pour
l'année 2015-2016 un-e enseignant-e contractuel-le (contrat mi-temps sur
support vacant du 2nd degré). Les candidats doivent être titulaires (au
minimum) d'un diplôme d'études anglophones de niveau Bac + 5. Les candidats
certifiés ou agrégés devront demander à être détachés de l'enseignement
secondaire.

Les besoins d'enseignement sont principalement dans les spécialités
suivantes:
- civilisation américaine
- traduction (thème et version)
- histoire de l'art
- préparation à l'insertion professionnelle

Les pièces demandées sont les suivantes:
•    une lettre de motivation
•    un curriculum vitae
•    une copie des diplômes universitaires
•    la copie d'une pièce d'identité

Les dossiers sont à adresser par email exclusivement aux adresses
suivantes: xxxxxx@u-cergy.fr,  yyyyyy@u-cergy.fr et
zzzzzz@u-cergy.fr
-----------------------------------------------------------------------------


Pathétique...

Projet de loi relatif au Renseignement

Dans 12 jours, le gouvernement Français, profitant de l'émotion suscité par l'assasinat lâche de journalistes, va mettre aux votes une loi scélérate.

Il est de notre devoir de faire savoir à nos députés que nous n'acceptons pas de devenir citoyens d'un état (potentiellement) totalitaire. 

Le texte de loi est disponible ici.

Vous pouvez consulter ce site pour vous informer de la façon de contacter votre député.

Voici le mail que j'ai envoyé à Mr Goasguen, député du 14ème arrondissement :


Monsieur le Député,
vous avez l'honneur de représenter le 14ème arrondissement de la ville de Paris, dans lequel je suis domicilié. A ce titre, vous me représentez également.


Je me permets donc de vous interpeller sur le projet de loi qui est amené à être voté dans deux semaines. Celui-ci comporte des risques inacceptables sur les libertés fondamentales, tels que spécifiés dans l'article 811-1.

L'article 821-1 précise que l'autorisation de mise en oeuvre du recueillement d'informations relève de sept personnes :
- le premier ministre
- et 6 personnes qui ont délégation du premier ministre

L'exercice de cette commission de contrôle, dont la composition est hautement politique, violerait le principe de séparation des pouvoirs, principe fondateur de notre république, et préambule à notre constitution. Il n'est pas envisageable que cette entité distincte du pouvoir judiciaire puisse remplir un rôle qui est du ressort du judiciaire.

Voter cette loi serait donner raison à toute forme de terrorisme, rangeant la France dans le groupe des nations disposant d'outils de surveillance dignes de systèmes totalitaires. Non, l'assassinat ignoble de journalistes ne saurait justifier la mise en place d'un tel système, que ces journalistes auraient bien évidement rejeté avec la plus grande fermeté.

Je vous demande de faire ce qui est en votre pouvoir pour faire rejeter cette loi liberticide. Il ne s'agit pas ici d'une position politique, mais d'une position de principe. Votre devoir est de défendre les principes fondamentaux qui font la grandeur de notre république, au delà de tout attachement partisan.

Je vous remercie par avance,

Emmanuel Lécharny
7 Square de Chatillon,
Paris 14

I have a dream...

Ce dimanche, il fait un peu gris, la choucroute mijote dans le fait-tout... Il me reste une petite demi-heure avant de passer à table, la famille est en route, j'ai le temps de me laisser aller à une petite rêverie informatique.

Mon camarade Antonio Goncalves, un des organisateurs de Devoxx.fr (pub plug) se plaint de l'incapacité de l'administration à mettre en place une informatique qui fonctionne.

Qu'en dire ? Qu'un programme comme Louvois, lancé en 1996, abandonné en 2013 après avoir foutu à la poubelle dépensé 470 M€ puisse avoir été un tel echec est la preuve que l'état est incapable de gérer son informatique. Et des faillites équivalentes, il y en a : project Chorus (500M€), Dossier Personnel Médicalisé (500M€ pour 400 000 patients...), l'Opérateur National de Paye (750M€).

J'ai également en tête l'informatisation de la DGI, où l'état avait missionné deux énormes sociétés française (sans doute pour les sauver en ces années de bulle internet...), qui facturaient entre 1000 et 2000€ la journée, et qui avaient bien sûr des sous-traîtants, qui eux même prenaient des sous-traîtants... Ceux qui ont effectués leur déclaration par internet la première année se rappellent bien de la totale incapacité du système à ternir la charge à l'époque bien faible. Le project COPERNIC a coûté 1.5G€ (cf le rapport du sénat).

Bref, on se dit qu'il y a des marges de progression. Mais dans quel cadre technique, juridique et surtout organisationel ?

C'est là que je me mets à rêver. Je lisais il y a quelques mois cet article édifiant, où était décrit l'opération commando qui 'sauva' Obamacare. Je me dis qu'il devrait être possible de faire la même chose en France.

Nous avons un vivier d'Open Sourceurs, assez large en plus. Dans des domaines variés, qui couvriraient largement le spectre de l'informatique mise en oeuvre par l'état. Ce sont nos impôts qui financent ces échecs, et ce sont également nos impôts qui (sur)payent les systèmes qui finissent par fonctionner (mal). Ne serait-il pas possible de réunir assez de compétences pour remettre en état un de ces systèmes, à coût nul pour l'état, pour un résultat fonctionnel, mais également moins onéreux en fonctionnement ?

L'idée - le rêve - serait de mettre à disposition d'un des projets en souffrance une équipe pluridisciplinaire compétente, disponible, et cela gratuitement.

La gestion de projet serait totalement collaborative, sans la contrainte temporelle et budgétaire si mortifère dans un cadre contractuel classique : à savoir que l'on se focaliserait sur les fonctionalités, les performances, l'évolutivité et les tests, au lieu de se limiter à livrer dans les temps, à l'aide de stagiaires si besoin (vécu...).

On s'épargnerait la recherche du profit - ou plus souvent la limitation des pertes dans l'espoir de se refaire grâce à de substantiels avenants que le client se voit bien obligé de signer... -, au profit de la satisfaction du 'client' - c'est à dire, le citoyen -.

Il serait possible de dire non, mais également de remettre en cause les choix initiaux, puisque l'objectif est d'aboutir à un système fonctionnel, sans craindre un clash avec le client. La relation avec ce dernier serait de même bien plus confortable, car on éviterait d'accumuler les "preuves" de malfaçons et de non respect des délais et des fonctionalités, puisqu'aucune pénalité de retard ne serait en jeu.

Bien sûr, on ne peut imaginer disposer de quelque dizaines d'informaticiens compétents pendant une période de six mois ou un an sans les payer, alors - second rêve - j'imagine un système de sponsoring, ou de crowdfunding permettant de financer cet effort.

Et pourquoi pas ?

A condition que les lobbies, puissant, des SSII, laisse faire, bien sûr : la fonction publique est une source majeure de revenu récurrents pour ces sociétés. Et que le droit administratif ne vienne pas se mettre au travers d'une telle démarche : comment éviter de passer au travers d'un appel d'offre public?

Dernier point : pourquoi ne pas profiter de ce cadre pour former ? Au lieu d'envoyer des stagiaires achever des projets comme on achève les chevaux, on les enverrait se faire former dans un cadre plus souple, et surtout par des personnes compétentes, et disponibles. Ce serait aussi l'intérêt des SSII de 'sponsoriser' un projet donné, par délégation de personnel : après tout, il n'est pas si fréquent de pouvoir se confronter à des problématiques complexes dans un cadre réel, sans les contraintes habituelles. Un lieu magique où la recherche de solution serait possible, un projet Manhattan à la Française en quelque sorte...

Et pour 50 personnes, payées - soyons généreux - 100 000 € par an, plus 2 M€ de frais de fonctionnement (ordinateurs, locaux, télécom, frais divers), soit 7M€ par an, allez, 10M€ en intégrant les charges sociales, je serai surpris qu'on n'arrive pas à produire quelque chose qui fonctionne, à comparer aux coûts délirants des projets nommés ci-avant...

On pourrait même imaginer les faire tourner dans un cloud Français ! (Ok, là,  je parle d'un vrai cloud, pas d'une sorte de FranceStein du cloud financé par vos impôt, hein !)

Ok, je rêve... Mais après tout ?

Et vous, il vous arrive de rêver aussi ?

Allez, la choucroute m'attend...

About Perfection and OSS

From time to time I feel like we all have our own Moby Dick, and when it comes to OSS, it's name is 'perfection'.

Those shiny moments of pure joy, this warm feeling that surround you, when you can say 'mission accomplished' are rare and vanishing periods when you work on a never ending project. Its more or less when you get a big bug fixed, or when you read some enthusiast review on the project you are working on.

Fixing a bug is probably the best way to get this reward, as you know that you have made some progress.

It's forever shadowed by the constant pain of knowing that there are other bugs, and that in order to get a release done, you had to make some choices, leaving problems behind.

Is it a sad story about being a developer? No. It's not sad. It's tough, it's long, it's an endless job. Would I prefer doing something else? Certainly not ! At least, I know what I'm chasing, and even if I rarely foresee this fading perfection, sometime, I can almost touch it. Not something you can experience when you work in a company, as you don't have the opportunity to polish the project as much as you want, due to time constraints.

Last, not least, you are not alone. When you think that you are turning in circles, you know that the community you are part of will help you. Use it : they have the clues you don't have.

An Arabic proverb says "It's not that the way is painful, it's just that the pain is the way". So you better deal with it.

Free ADSL, où comment ne pas avoir d'ADSL pendant plus d'un mois...

Ne plus avoir d'électricité pendant 2 jours, sauf en cas de tempête, est juste inconcevable en France. Pour une connexion ADSL, vous pouvez rester coupé pendant plus d'un mois sans que cela ne semble soucier votre provider, en l'occurence Free.

On ne parle pas d'un village au fond d'une vallée reculée du haut morvan, là. C'est à Puteaux, dans la proche banlieue parisienne.

Tout commence par une intervention sur une ligne par l'opérateur historique, le 24 septembre 2014. Résultat, une ligne ADSL dont le débit chute brutalement à 500Kbits (54db) au lieu de 10Mbits (42db). Typique d'une ligne abimée, ou d'un signal affaibli par une interaction magnétique ou un cable de mauvaise qualité.

Et là, la boucle infernale commence : ouverture de ticket d'incident chez Free, une semaine de délai avant vérification des équipements (et oui, c'est toujours chez vous que le problème se situe, par défaut !), puis suite à la vérification du bon fonctionnement de l'équipement, on bascule chez l'opérateur historique (entendez FT), par le biais de ce qui s'appelle un GAMOT. C'est encore une semaine d'attente...

Suite à quoi, généralement, FT ne détecte bien sûr aucun problème, et ferme le GAMOT. Vous venez de perdre 2 semaines...

Voilà, vous devez réouvrir un ticket chez FREE, qui va cette fois devoir aller plus loin que de constater que votre matériel fonctionne bien et rouvrir un second GAMOT. Puisque qu'aucun des deux opérateurs ne reconnaît un problème chez lui, c'est qu'il doit y avoir un problème entre les deux...

(Entre temps, votre voisin, qui est abonné chez FT, lui, a été rétabli dans les 2 jours...)

Que se passe-t-il lors de cette "procédure d'expertise" ? Et bien les deux sociétés font intervenir deux techniciens pour tester la connection de bout en bout. Généralement, ils découvrent à cette occasion un mauvais branchement, et le rétablissement a lieu - si tout va bien ! -.

En pratique, il faut compter un bon mois, parfois moins, parfois plus.

Et ce n'est pas normal.

Dans le meilleur des cas, on parlera d'incompétence, mais reste à savoir chez qui. En pratique, la question de la procédure mise en place chez les deux sociétés (et on peut imaginer qu'il en est de même avec d'autres opérateurs tiers) a pour résultat une distortion claire des règles du jeu : si vous êtes chez l'opérateur historique de bout en bout, vous êtes rétabli en 2 jours. Dans le cas contraire, chacun se renvoit la balle pendant un bon mois...

Free n'ouvre un GAMOT qu'après avoir vérifié l'équipement, très certainement à cause des coûts facturés par l'opérateur pour le traitement du GAMOT, dans les cas où le problème viendrait du matériel ou d'un problème de connection au domicile. Pourquoi pas, sauf qu'il faut compter une bonne semaine pour avoir un rendez-vous avec un technicien...
L'opérateur historique va de son côté faire le minimum, à savoir tester la synchro,  puisque généralement cela suffit pour détecter un pb de connection, bien évidemment sans régler votre problème de débit !

La question qui se pose à ce point, c'est de savoir s'il n'y a pas dans ce protocole d'intervention une volonté active ou passive de favoriser les clients de l'operateur historique ? On ne parle pas évidemment de l'incapacité de l'opérateur alternatif à fournir un service après-vente digne de se nom, faute de disposer du personnel suffisant...

A ce point, après un mois sans service, il convient de se poser la question du recours en justice, éventuellement dans le cadre d'une "action de groupe" - puisque c'est aujourd'hui chose possible en France - pour sortir de ces parties de ping-pong infernales ! Mais sauf à condamner lourdement les opérateurs, pour les forcer à réduire ces délais inaceptable, je ne vois pas comment les choses pourraient évoluer.

Mais ne rêvez pas, même dans cette hypothèse, la procédure prendra des années... Il faudra d'abord s'adresser à une société de défense des consommateurs agréée (il y en a 17), et espérer qu'elles acceptent de lancer la procédure. Cela ne préjuge en rien des délais d'obtention d'un jugement - sans compter qu'il peut être rendu en faveur des opérateurs -, sachant que ces derniers peuvent évidemment faire appel, se pourvoir en cassation...

Cela dit, il y a un moment où l'inaction vaut acceptation...

Building castles in the sand...

Now that the fury about OpenSSL is gone, and that we realize first it was not that critical (only 7% of the web sites seemed to be at risk, not two third), and second that it could have been used for two years, but we don't know if it has been (we are waiting for a new Snowden), we can think about what the lessons we can get from this tragic episod.

There are a few, IMHO.

1) OpenSSL is a group of 17 persons, all volunteers. I'm not sure that all of them are active. This is a small bunch of people, for a software that is used at wild. Do people realize that most of the components they are using daily, that they *trust*, are written by such a few developpers?

What if the group decides it's enough ? That family is more important than spending hours on debugging some code, on testing it, and on documenting it ? All of that for the simple feeling of writing good, useful code ?

2) It took 2 years, 2 freaking years, before a company called Google was able to find the issue. What does that mean ? Simply that companies like Yahoo!, which were one of the big IT companies being hit hard by the HeartBleed bug, just didn't do their due diligence.

It's insane to think that those companies are spending BILLIONS of $ buying crappy other companies, trying to improve their load of turd^H^H^H social tools, when they are too cheap to spend a few hundred of thousands dollars to get some expert looking at the code they are using.

Shame on them.

3) Low level components are just left alone. Those days, it's all about the big frameworks, nobody cares about the bricks that are at the very base of our IT.

And that scares the shit out of me, as it should scare any one of you.

We are all expecting that the bricks we are using every day are safe. We are ignoring the risks we are taking, just because we can't check everything. But again, when you look at the commits, you realize you are depending on very few people...


Bottom line : we are building castles in the sand. And I don't even know how we could do any better...