Besides, I would add that even for dependencies that are active, or dormant but responsive, users might still be at risk if everything depends on a single maintainer, who could go missing at any time. This is a common risk in open source software, close to the famous “bus factor” problem, which I tried to quantify more than 6 years ago,¹ using data that were already coming at the time from Andrew Nesbitt.

We keep reminding users that open source software comes with no guarantee, and in particular no guarantee of future maintenance, so they have no right to complain if they don’t support the project, financially or otherwise. But that does not mean that all open source dependencies carry the same risks. Some of them are effectively “dead” or insufficiently maintained to be safe to use, but others, on the contrary, are well maintained, and perfectly safe to use. So it would be nice if there was a way for projects to signal their maintenance status.

Of course, it is not as easy as declaring “this project is maintained”, as this could very well be true when the declaration is committed to the repository, but it might no longer be true two years later when a problem arises and requires attention.

So here is my proposal, inspired by several sources, including the recent work on adding an x-maintenance-intent field to opam (the OCaml package manager) metadata, as well as the ongoing work of my postdoc Antonin Delpeuch on helping projects make their governance explicit through a GOVERNANCE.md file.

A MAINTENANCE.md file

This would be a file that could be added to the root of a repository (like the current practice for standard files such as README.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, GOVERNANCE.md, SECURITY.md, etc.)² that would contain information about the maintenance intent and status of the project. Here are the sections that I would expect to find in such a file (and we could “normalize” them so that tools can consume them³ and display them in package registries, for instance):

• Maintenance intent: what types of maintenance activities the project intends to perform (e.g., “the project is actively developed and new features are regularly added”, “the project is in maintenance mode and only bug fixes and security patches are provided”, “the project is mostly dormant but the maintainers will respond to vulnerability reports and critical bug fixes”, or “the project was developed as a fun hobby project and there is no intent to support users or any commitment to fix security issues”).

• Active versions: which versions of the project are actively maintained (e.g., “only the latest major version is maintained”, “versions 2 and 3 are maintained, but 2 only receives security patches”).

• Maintenance team: who is responsible for maintenance activities. In particular, who has commit rights, who currently handles the releases, who else has rights to publish new versions to the package registry and could step in if the main maintainer goes missing, etc.

• Maintenance team check-in: as part of the above section, a statement about how often each maintainer is expected to check in to show that they are still active and reachable. This could be done by committing to the repository, or even by committing to the MAINTENANCE.md file itself if no other activity was needed. The commit to the MAINTENANCE.md file could also be used to record the last time the team member checked that they still had access to the package registry. We could also invent a new badge that would show when this author last committed to the repository. This information is particularly important because it would allow us to distinguish between “dormant but responsive” and “dead” dependencies (that Andrew Nesbitt had to classify as “unknown” in his analysis).

• How to help: if the project accepts help, for instance, in the form of funding (and what kind of additional maintenance activities this may guarantee), or in the form of engineering effort (including looking for new maintainers). Of course, after the event-stream and xz incidents, one might be wary of accepting new maintainers and some could argue that explicitly asking for help can even make projects a target of social engineering attacks, but on the other hand, it may be better to be transparent about this need and look for new maintainers early, rather than wait for maintainers to burn out and have to appoint new ones in a hurry. In particular, this declaration does not mean that the project has to appoint anyone who proposes to help.

Note that the goal of this new file is not to repeat or replace the information that can already be found in other files, such as GOVERNANCE.md for how new maintainers are appointed, or SECURITY.md for how to report security vulnerabilities. Any information that is already present elsewhere can be simply linked from the MAINTENANCE.md file.

All in all, the file could look like this:

# Maintenance intent

Project X is currently in maintenance mode, and only bug fixes and security
patches are provided.

## Active versions

The latest major version (3.x) receives regular bug fixes and security 
patches. Version 2.x only receives security patches, and version 1.x is no
longer maintained.

## Maintenance team

- Alice (@alice):
  - Commit rights, release manager, has access to the package registry.
  - Checks in at least once every 3 months.
  - Last check-in to `MAINTENANCE.md`: 2026-05-01 (confirmed access to the package registry).
  - Last commit to the repository: \
    ![check-in badge](https://img.shields.io/badge/does-not-exists-yet?project=X&who=alice&freq=3m)
- Bob (@bob):
  - Commit rights, has access to the package registry.
  - Checks in at least once every 6 months.
  - Last check-in to `MAINTENANCE.md`: 2026-01-15 (confirmed access to the package registry).
  - Last commit to the repository: \
    ![check-in badge](https://img.shields.io/badge/does-not-exists-yet?project=X&who=bob&freq=6m)
- Carol (@carol):
  - Commit rights.
  - Checks in at least once every 6 months.
  - Last check-in to `MAINTENANCE.md`: 2024-09-23.
  - Last commit to the repository: \
    ![check-in badge](https://img.shields.io/badge/does-not-exists-yet?project=X&who=carol&freq=6m)

## How to help

Maintainers are not currently accepting financial support and do not have
the bandwidth to review new feature proposals. Getting new maintainers on
board could help make the project more active and accept new features again.

In the example above, Carol has not checked in to the MAINTENANCE.md file for more than 6 months, but the badge could still show that her last commit to the repository was within the last six months.

What do you think?

My goal with this proposal is to come up with a methodology that would be lightweight for maintainers to implement, but would also help with transparency toward users about a project’s status and automatically signal when there is an issue with maintainers’ availability. I am particularly interested in hearing from maintainers whether this is something they would be willing to adopt.

In particular, I believe that we should stop reasoning that, just because an open source package happens to have many dependents, the author should have a particular responsibility toward its users. If there are good mechanisms to communicate maintenance intent and status, then users can make informed decisions about which dependencies to use, and maintainers can also explain under what conditions they are willing to provide support. Authors who created packages as just a hobby can be transparent about not wanting to support users, and users are free to fork the project and maintain it themselves if they are not satisfied with the level of maintenance provided by the original author.

La nouvelle a déjà été reprise par de nombreux articles du CNRS, de l’INS2I, de l’Université de Paris, de l’Université Paris-Saclay, etc. Si je reviens dessus aujourd’hui, c’est, d’une part car les vidéos de la conférence, et en particulier de la cérémonie, sont désormais disponibles, et d’autre part, pour présenter le contenu de la candidature que nous avions soumise pour l’obtention de ce prix.

La vidéo de la cérémonie se trouve ici et la partie consacrée à Coq commence à 11:51 et dure jusqu’à 16:30.

Si vous ne souhaitez pas la regarder, en voici des extraits :

• Daniel Le Berre, président du jury :

  C’est un de nos plus vieux candidats puisqu’il a débuté dans les années 80, mais ce qui est intéressant c’est qu’on a une nouvelle génération de chercheurs qui le font évoluer, et ce qui a touché le jury c’est que ce logiciel, c’est un logiciel phare de la science française, mais cette nouvelle équipe, elle a une nouvelle façon de travailler, plus ouverte, plus “génie logiciel” que par le passé, et ils avaient écrit dans leur candidature qu’ils candidataient pour que cette approche soit validée et le jury a été touché par ça.

• Mon intervention, en tant que représentant de l’équipe Coq :

  Moi je n’étais pas né quand le logiciel a été créé, mais je représente aujourd’hui l’équipe de développement de l’assistant de preuve Coq, qui est un logiciel qui a toujours été développé avec une vision ouverte, car ça correspond à la manière dont la science se construit, et qui est distribué depuis plus de 20 ans sous une licence libre, mais en revanche ce qu’on soulignait tout à l’heure, c’est qu’au-delà de la licence libre, nous avons fait le choix depuis plus de 7 ans de chercher à ouvrir réellement le développement du logiciel pour impliquer davantage une communauté, qui est aujourd’hui une communauté mondiale. Le fait que l’équipe ait fait ce choix et ait organisé, par exemple, des journées lors desquelles l’équipe introduisait la base de code à des nouveaux contributeurs, et travaillé sur la documentation, à la fois la documentation technique mais aussi la documentation des processus de contribution, a fait qu’on a pu finalement augmenter très largement le nombre de personnes qui pouvaient contribuer à l’amélioration et à l’évolution de ce système, ce qui fait qu’on a aujourd’hui un nombre de contributeurs qui a très largement augmenté, disons pour vous donner une idée, qui a été multiplié par 4 dans les 5 dernières années, et on a aussi beaucoup plus de personnes qui sont impliquées dans la maintenance au jour le jour.

Puisque Daniel Le Berre mentionnait que le jury avait été touché par notre dossier de candidature, en voici le contenu ci-dessous, à commencer par la motivation de la candidature, dans laquelle nous expliquons ce que ce prix représente pour nous :

Motivation de la candidature

Coq est un logiciel de recherche développé depuis plus de 35 ans. Déjà récipiendaire du prix ACM Software System Award en 2013, sa réputation n’est plus à faire. Cependant, beaucoup d’efforts ont été effectués ces dernières années pour améliorer et ouvrir ses pratiques de développement. Les changements effectués entre 2015 et 2019 (passage à GitHub pour les pull requests puis les issues, adoption d’intégration continue et test avec des dépendances inverses, introduction d’un guide de contribution, documentation systématique des fonctionnalités introduites ou modifiées, extension de l’équipe des mainteneurs participants à l’intégration des changements, passage à des cycles de version plus courts, amélioration de la maintenance des paquets au niveau de l’écosystème) sont décrits en détail dans la thèse de Théo Zimmermann. D’autres changements ont été encore conduits depuis, comme la restructuration du manuel de référence et l’amélioration de son contenu, ou encore l’introduction de la Plateforme Coq, permettant de faciliter l’installation de Coq et de paquets standard de son écosystème, et de nouvelles plateformes de discussion telles que Zulip. Alors que le prix ACM Software System Award avait récompensé les développeurs initiaux de Coq, l’obtention du prix Science Ouverte du Logiciel de Recherche récompenserait les efforts de la nouvelle génération de développeurs et mainteneurs de Coq qui ont contribué à véritablement ouvrir ce logiciel et à développer sa communauté et son écosystème.

Diffusion

Les nouvelles versions de Coq sont publiées sur le dépôt GitHub, sous forme de code source. Elles sont ensuite rendues disponibles dans de nombreux systèmes de paquets (opam, Nix, Homebrew, distributions Linux). Voir : https://repology.org/project/coq/versions.

Désormais, la Plateforme Coq est la méthode recommandée d’installation de Coq, car elle permet de plus facilement avoir accès à Coq ainsi qu’à un ensemble de paquets standard de l’écosystème. Elle comporte un mode “débutant” basé sur des installateurs binaires pour Windows, macOS et Linux (Snap) et un mode “avancé” basé sur un script interactif faisant appel à opam de manière sous-jacente.

Éléments scientifiques et techniques

Dimension scientifique

L’assistant de preuve Coq s’appuie sur des décennies de recherche active dans diverses équipes, en France et à travers le monde. La page https://coq.inria.fr/refman/history.html contient une description détaillée des racines de ces recherches. Aujourd’hui, Coq est à la fois un objet d’étude (nouveaux développements théoriques permettant des évolutions) et un support à la recherche en mathématiques formalisées et vérification de logiciel. Le survey “QED at Large” décrit les nombreuses avancées scientifiques ayant eu lieu pour permettre la vérification de logiciel à l’aide d’assistants de preuve tels que Coq.

Le nombre d’articles de recherche publiés s’appuyant sur Coq est trop grand pour en faire une liste exhaustive. Pour donner un ordre de grandeur, la recherche de “Coq proof” sur Google Scholar conduit à l’obtention de plus de 30 000 résultats (en vérifiant les 10 premières pages, on constate que tous les résultats sont pertinents). Des requêtes similaires sur d’autres bases de données (Scopus, ACM DL, Inspec) donnent chacune plusieurs milliers de résultats. Le Coq’Art, le tout premier livre sur Coq, a été cité plus de 2500 fois.

Par ailleurs, Coq a été une source d’inspiration pour plusieurs autres assistants de preuve, notamment Lego, Matita et Lean, tous basés sur le Calcul des Constructions Inductives, théorie sous-jacente au logiciel Coq.

Dimension technique

Le développement de Coq a posé de nombreux défis techniques, au-delà des fondements scientifiques et théoriques sur lesquels le logiciel repose, notamment car il ne se limite pas à son noyau, composant logique permettant de vérifier les preuves. La partie “assistant” du logiciel représente une partie essentielle de la complexité du système. Un enjeu technique majeur actuel est de permettre de continuer à faire évoluer le logiciel tout en assurant les besoins en termes de stabilité des utilisateurs majeurs. Pour permettre de mieux évaluer en pratique l’impact d’un changement en termes de compatibilité, des tests avec des projets externes dépendants de Coq sont effectués de manière systématique. Lorsqu’un changement casse la compatibilité mais est jugé nécessaire, les développeurs de Coq réparent les projets externes inclus dans les tests afin de pouvoir continuer à les utiliser dans les futurs tests de compatibilité. Dans le même temps, de nombreux efforts ont été effectués pour retirer de la dette technique, accumulée au cours du temps par l’ajout de fonctionnalités expérimentales, dues à la nature de logiciel de recherche de Coq. Ces efforts permettent d’envisager les évolutions futures du logiciel de manière plus sereine.

Dimension génie logiciel

L’architecture de Coq est découpée en de nombreux composants qui dépendent les uns des autres, à commencer par un noyau, bien délimité, qui a pour tâche de vérifier les preuves. Grâce à cette architecture, classique parmi les assistants de preuve modernes, tout bug en dehors du noyau n’est pas en mesure d’affecter la confiance que les utilisateurs peuvent accorder au système. Coq dispose par ailleurs d’un système de plugins permettant d’étendre le système (sans perte de confiance) et un certain nombre de composants cœur se présentent d’ailleurs sous cette forme.

Comme précisé dans les motivations de la candidature, le développement de Coq a beaucoup évolué au cours des six dernières années. Développé depuis 1999 dans un dépôt SVN, git et GitHub ont été adoptés, d’abord pour permettre de faciliter les contributions extérieures. À partir de 2016, les pull requests ont été également adoptées au sein de l’équipe cœur pour permettre la revue de code. Par la suite, les issues de GitHub ont également été adoptées, ce qui a donné lieu a une publication évaluant l’impact d’un tel changement. Le passage à l’utilisation systématique de pull requests a permis de systématiser la mise à jour de la documentation et le test. Ce dernier repose sur un système d’intégration continue incluant des tests de régression et des tests de compatibilité avec des projets dépendant de Coq (plusieurs millions de lignes de code sont ainsi testées pour chaque changement). Le processus de sortie de nouvelles versions a également évolué pour permettre de produire de nouvelles versions de manière plus rapide. Les branches stables sont maintenues par des “release managers”, qui “backportent” les correctifs, aidés par un système semi-automatique. Un bot interagit avec les développeurs pour les aider dans leurs tâches répétitives. Tous ces changements sont décrits en détails dans la thèse de Théo Zimmermann.

Documentation

Qualité de la documentation pour les utilisateurs

Un frein au développement de l’utilisation de Coq a longtemps été le manque de documentation, les utilisateurs devant apprendre à utiliser le logiciel au contact d’autres utilisateurs ou de développeurs. Ce problème a été levé à partir de la publication en 2004 du premier livre sur Coq, le Coq’Art (édité par Springer en anglais mais également disponible gratuitement en version française, et depuis 2009 en chinois). Par la suite, de nombreux autres livres ont été écrits sur Coq (la page de documentation de Coq en référence près d’une dizaine), notamment le très célèbre Software Foundations de Benjamin Pierce et al., aujourd’hui largement utilisé par les nouveaux utilisateurs, et qui a également été traduit en chinois. Il existe également un livre sur Coq écrit en japonais (par Manabu Hagiwara et Reynald Affeldt).

L’équipe de développement de Coq maintient quant à elle le manuel de référence et la documentation de la bibliothèque standard. Un accent particulier a été mis ces dernières années sur l’amélioration de la qualité (exhaustivité, exactitude, accessibilité) du manuel de référence. Tout d’abord, celui-ci a été converti de LaTeX vers Sphinx (étendu pour les besoins de Coq) grâce à un effort collaboratif de la communauté. Le manuel contient de nombreux exemples de code, qui sont exécutés et qui font échouer la compilation s’ils déclenchent des avertissements ou message d’erreurs inattendus. Le langage de Coq ayant une grammaire très étendue (la plupart des commandes et des tactiques sont accessibles sous forme de syntaxe), un outil a été développé pour mettre en relation la grammaire telle que définie dans le parser et telle que documentée dans le manuel de référence. Une restructuration majeure du manuel de référence a également été entreprise pour organiser le matériel qui y avait été ajouté de manière organique.

Qualité de la documentation pour les développeurs et contributeurs

La documentation interne du code de Coq s’est longtemps limitée à quelques commentaires décrivant les fonctions exportées dans les fichiers sources. Cette documentation a été complétée par des documents décrivant l’implémentation de certaines parties du logiciel, des introductions à l’architecture de Coq, présentées sous forme de diaporamas lors d’évènements (Coq Users and Developers Workshops) destinés depuis 2015 à faciliter les contributions d’utilisateurs au code de Coq. Un tutoriel pour les auteurs de plugin a également été créé à cette occasion et est maintenu dans le dépôt de Coq. Enfin, un guide de contribution très complet a été rédigé pour permettre d’intégrer et de former de nouveaux contributeurs en leur exposant une progression à travers différents types de contributions, à commencer par des contributions à l’écosystème, à la gestion des tickets, pour continuer avec des contributions de code et de la maintenance. Ce guide de contribution a également pour but de servir de documentation de référence des processus établis dans l’équipe de développement de Coq, et sert par conséquent également aux contributeurs déjà bien établis.

Communauté

Quels sont les utilisateurs actuels du logiciel ?

Coq est utilisé par une très large communauté, dont la taille est difficile à évaluer du fait que ni le logiciel, ni le site web n’incluent de traceurs pour en mesurer l’audience. Il est en revanche incontestable que Coq est aujourd’hui l’un des logiciels de référence dans son domaine (les assistants de preuve), domaine qui est lui-même en forte croissance. Bien que peu fiable comme mesure de popularité, le nombre d’étoiles attribué à Coq sur GitHub (qui s’élève à 3 500) en fait l’assistant de preuve le plus populaire sur GitHub, ainsi que le logiciel le plus populaire listé sur code.gouv.fr (d’une courte tête devant OCaml, le langage dans lequel Coq est écrit). Coq est utilisé avant tout par des chercheurs pour des projets de taille de plus en plus impressionnante (le compilateur certifié C CompCert, le projet DeepSpec financé à auteur de 30 millions de dollars par la NSF) mais aussi par des industriels de plus en plus nombreux. Les utilisateurs industriels incluent de nombreuses start-ups de blockchain, à commencer par la française Nomadic Labs, qui développe la blockchain Tezos, d’autres types de start-ups comme l’espagnole Formal Vindications, qui vérifie des logiciels légaux, des entreprises américaines de conseil telles que Galois et Bedrock Systems, mais aussi de plus grosses entreprises telles qu’Amazon, Apple, Google, IBM. La page https://github.com/ligurio/practical-fm liste près d’une vingtaine d’entreprises qui utiliseraient Coq. La publication en 2020 par l’ANSSI d’un guide sur l’utilisation de Coq dans le contexte de certifications Critères Communs atteste de l’importance de ce logiciel pour le secteur industriel.

Animation de la communauté des utilisateurs et des contributeurs

Coq dispose de nombreux canaux de communication pour les utilisateurs (https://coq.inria.fr/community) : une liste de diffusion historique encore très active, récemment complétée par un forum Discourse, un système de messagerie instantanée Zulip avec plus d’un millier d’inscrits (un canal IRC non-officiel existe également sur Libera.Chat), un compte Twitter. Deux workshops annuels sont organisés à l’occasion de conférences majeures en informatique (CoqPL, associé à POPL, et le workshop Coq, associé à ITP / IJCAR / FLOC). Des workshops spécifiques destinés à des sous-communautés de l’écosystème Coq, ainsi que des écoles, sont également régulièrement organisés (https://coq.inria.fr/community).

Les canaux précédemment mentionnés sont également utilisés pour les contributeurs, complétés par le dépôt GitHub et un workshop annuel (Coq Users and Developers Workshop) destiné à aider les utilisateurs à devenir des contributeurs. Les développeurs se réunissent en vidéo-conférence une fois par semaine, et cette réunion est ouverte à tous. Les noms des contributeurs et des mainteneurs sont mis en avant dans les notes de nouvelles versions. L’utilisation d’équipes de mainteneurs combinée avec le système de CODEOWNERS de GitHub a permis d’élargir le nombre de mainteneurs participant à l’intégration des modifications à une trentaine de contributeurs réguliers (contre moins d’une dizaine de développeurs de l’équipe cœur auparavant), ce qui permet de traiter plus efficacement le nombre important de pull requests (créées par plus de 200 contributeurs, d’après le décompte de GitHub). Un système de Coq Enhancement Proposals permet de discuter certaines propositions de changements majeurs avant leur implémentation.

Écosystème

Coq dispose d’un écosystème très riche de paquets qui en étendent les capacités : plugins qui se connectent à l’API OCaml de Coq pour proposer des extensions de fonctionnalités, bibliothèques Coq réutilisables qui développent des applications particulières. Historiquement, ces “contributions” étaient distribuées avec Coq, par l’équipe de développement. À partir de 2013, des utilisateurs et développeurs de Coq ont étudié la possibilité de distribuer ces contributions à travers un index et un gestionnaire de paquets. Il a été décidé de réutiliser opam, qui avait été développé pour le langage OCaml, et l’index des paquets Coq existe depuis fin 2014. Depuis quelques années, de plus en plus de ces paquets Coq sont également disponibles à travers le gestionnaire de paquets générique Nix. Enfin, depuis 2018, une organisation communautaire destinée à assurer la maintenance à long terme des paquets importants de l’écosystème a été formée. Cette organisation permet la maintenance de plus de 50 paquets par plus de 30 mainteneurs, mais aussi la création d’outils pour l’aide à la maintenance, et la diffusion de bonnes pratiques (dans tout l’écosystème Coq). Cette organisation est basée sur un modèle qui a émergé dans plusieurs autres écosystèmes logiciels et qui fait actuellement l’objet de recherches. La plupart des paquets Coq sont disponibles sous licence libre. L’organisation coq-community n’accueille que du logiciel libre.

This problem is often unavoidable because the available manpower to fix bugs and limitations rarely scales as fast as the manpower to report them. Therefore, the number of open bugs in the issue tracker of popular projects can end up growing and growing until a point where it becomes hard to manage.¹

The stale bot approach

To alleviate this problem, many open source projects are nowadays choosing to rely on “stale bots”, bots that automatically act on inactive issues (and pull requests), generally to close them. Wessel et al.² have done a preliminary study of projects that use the most well-known stale bot: https://github.com/apps/stale.

However, everyone that has spent time writing a careful bug report, only to see that it got no reply, but the one of the bot that closed it for being stale, can testify that this doesn’t feel like a great experience and doesn’t give much incentive to report the next bug you encounter. Open source maintainers are often aware of this: to illustrate, see this long discussion of nixpkgs maintainers and contributors about the introduction of a stale bot, or this blog post of the Gradle project to justify their use of a stale bot (which they link to in every message posted by the bot).

I think that there are many research opportunities to study stale bots usage beyond what Wessel et al.² did. Some research questions that come to mind:

1. In which context are stale bots introduced by project maintainers?
2. Are project maintainers satisfied with the stale bot solution?
3. How do issue reporters perceive the use of the stale bot?
4. What consequences does it have on the behavior of issue reporters? (Do they refrain from reporting new bugs they discover?)

To be addressed, these research questions would probably require a combination of quantitative and qualitative methods: mining software repositories, coding public discussions and blog posts, interviewing maintainers and issue reporters, econometrics methods to derive causality from quasi-experiments.

In the meantime, and without this evidence-based knowledge, as an open source maintainer, I am personally reluctant to introduce a stale bot to close our huge issue backlog in the Coq repository. Instead, I wish to explore alternative triaging approaches that scale.

Documenting known issues

Releasing software with known issues happens all the time. Some known issues are left unfixed because of lack of manpower to fix them and because they are not of top priority. Some known issues are left unfixed because fixing them is hard and designing a proper solution will take time. In both cases, it is perfectly acceptable to release software, but acknowledging and documenting known issues is always a good idea.

First, documenting known issues can avoid users spending time on things which do not work and getting frustrated. When there are known workarounds, documenting them will help users figure out how to proceed instead.

Second, keeping a list of known issues can also avoid getting duplicate reports when users encounter these issues. And when duplicate reports are created nonetheless, they can help maintainers figure out that this is really a duplicate and where the canonical issue is to be found.

For users to easily find out about known issues, they should be documented close to the feature they are a limitation of. And when they are introduced in a new release, they should appear in the release notes.

For issue reporters and maintainers to quickly find a known issue, an index of known issue can be a useful thing to have. But it is not a strict requirement if they can easily locate the documentation of the corresponding feature (and the known issues are easy to spot from there).

If documented known issues provide a link to the canonical discussion, this can also help potential contributors become active participants in the resolution.

Keeping the list of open issues focused

Accumulating a long list of open issues that are not actively worked on can be legitimately viewed as inefficient.

While closing issues which are not actively worked on with a stale bot risks burying them and leading to duplicate reports, closing inactive but documented known issues should not create such problems. Because they are documented, known issues are not just forgotten about. Ideally, the documentation even comes with a test case (within or separate from the documentation) that will help discover when they are accidentally closed or become irrelevant. Furthermore, if at any point, anyone wants to contribute to the discussion of the known issue, it is easy for them to do so if a link from the documentation to the canonical discussion is available.

Therefore, it seems reasonable to refine the stale bot approach into a novel stale known issue approach. This approach would roughly work in the following way:

1. When a bug or a limitation is reported, it should be confirmed (reproduced).
2. A confirmed bug or limitation which does not look like it will be fixed by the time of the next release should be documented as a known issue.
3. A documented known issue which is not receiving activity should be closed.
4. Any known issue receiving new activity (a new comment or a contributor self-assigning the issue) should be reopened (and reclosed if it becomes stale again).

The contributing documentation should direct potential contributors to the list of known issues, in addition to the list of open ones.

A bot and a clever use of labels or GitHub new projects can serve to implement and automate the above process.

Introducing this approach in a project with a big backlog

If we want to adopt this approach in the Coq project, the first thing we need to do is to handle the backlog of known, but undocumented issues.

Developers have expressed the need to document known issues several times in the past, so this objective is shared.³ What I’m not sure will be shared is the scope of known issues needing to be documented, but we can start with the ones that are consensual and work our way from there.

In PR #15102, I am introducing a special directive so that we can document (and highlight) known issues in the Coq reference manual. I am also experimenting with using a GitHub project to manage the list of known issues, those that need documentation and those that are documented. The project also provides a custom field to add a link from the issue to its documentation. In the future, we could add a column/status for the known issues that are documented and stale, and thus that could be (temporarily) closed.

À noter que vous pourrez également retrouver la notice sur la Publication en Libre Accès (Open Access), par Pablo Rauzy, sur le site de ce dernier.

Crowdsourcing

Voir aussi : Concours d’innovation, Crowdfunding ou financement participatif, Économie collaborative, Innovation ouverte, Plateforme collaborative, Production de pair à pair, Wikipédia

Définition de la notion

Le crowdsourcing (ou externalisation ouverte) est une pratique apparue avec le Web, dit 2.0, par laquelle un problème est confié à une communauté d’internautes dont le travail consolidé permet d’y apporter une solution.

Le terme crowdsourcing est d’apparition récente mais est aussi très utilisé, ce qui peut expliquer qu’il possède une définition assez changeante, selon les sources. Estellés-Arolas et González-Ladrón-de-Guevara (2012) proposent d’intégrer les différentes définitions qu’on peut trouver dans les publications académiques en identifiant les caractéristiques essentielles du crowdsourcing :

• c’est un « appel » plus ou moins ouvert,
• à une « foule »,
• qui se fait par le biais d’un processus participatif,
• utilisant Internet.
• Il sert à résoudre une tâche bien définie,
• proposée par un individu, une organisation ou une entreprise,
• qui tire parti du processus le plus souvent en recevant la solution à son problème.
• La foule aussi reçoit une récompense ou tire parti de son travail.

Le néologisme est attribué à Jeff Howe et Mark Robinson, rédacteurs à Wired magazine, qui l’ont construit sur la base de outsourcing. Ainsi, dans son acception première, il exprime une forme d’externalisation. Il aurait été inventé en 2005 et publié pour la première fois en juin 2006. L’observation des courbes d’intérêt pour la recherche de ce mot sur Google, à l’aide de Google Trends, montre bien une apparition à cette date et une augmentation croissante depuis. De manière intéressante, le terme crowdfunding qui n’est finalement qu’un avatar bien particulier de crowdsourcing, n’apparaît qu’en juillet 2010 mais prend une toute autre ampleur en supplantant, dès mars 2012, le crowdsourcing dans les recherches des internautes et en continuant à s’envoler depuis (à ce sujet, voir la rubrique sur le financement participatif).

Exemples de mise en application de la notion

De nombreuses applications ont été qualifiées de crowdsourcing. Si on accepte les différentes caractéristiques qu’on vient de lister, certains de ces exemples doivent néanmoins être disqualifiés.

L’encyclopédie collaborative Wikipédia, en particulier, ne tient pas dans les limites restrictives du crowdsourcing. En effet, personne en particulier n’est à l’origine de l’appel à la foule. Quant à la tâche, bien définie, de construire une encyclopédie, elle est sans fin.

À l’inverse, le service Amazon Mechanical Turk, réunit toutes ces caractéristiques et est d’ailleurs régulièrement cité comme l’exemple paroxystique de crowdsourcing. Ce service propose à n’importe qui de donner des tâches à des « travailleurs du web » en échange de « micro-paiements ». Avec ce service, la personne à l’origine de l’appel à la foule se charge de fusionner les données obtenues de la manière pertinente.

InnoCentive est une plate-forme d’innovation ouverte, étudiée entre autres par Isabelle Liotard et Véronique Revest (2015). Bien que répondant à la définition du crowdsourcing, elle présente la caractéristique particulière que seule la meilleure solution proposée par la foule est retenue.

Le site Duolingo était à l’origine un exemple de crowdsourcing où la foule reçoit une récompense autre que monétaire, en l’occurrence un service d’apprentissage de langues étrangères gratuit. Un des exercices proposés aux apprenants avancés, appelé « immersion », consistait à traduire des textes complets (de la langue apprise vers la langue maternelle). Le travail collaboratif des apprenants permettait d’obtenir des traductions de documents fournis par les clients de l’entreprise, que Duolingo estimait de qualité professionnelle.²

Par ailleurs, il existe de nombreuses plateformes de crowdscience (plus souvent désignée sous les termes « sciences participatives » ou « sciences citoyennes »), sur lesquelles les internautes jouent et contribuent en même temps à l’avancement de la recherche (l’exemple le plus connu est FoldIt http://fold.it mais on peut aussi citer Phylo DNA Puzzles http://phylo.cs.mcgill.ca/, Galaxy Zoo http://www.galaxyzoo.org…).

Enfin, reCaptcha est un service de crowdsourcing « forcé » (ou crowdsourcing implicite). Le service, possédé depuis 2009 par Google, permet de vérifier que les internautes ne sont pas des robots lors de l’inscription à divers sites (il s’agit de la requête faite à chaque utilisateur de retranscrire des lettres ou des chiffres qui apparaissent de façon tordue³), tout en fournissant à l’entreprise des données utiles à la reconnaissance de caractères ou d’images. Une pratique proche, de la part de certaines entreprises ayant un très grand nombre d’utilisateurs telles que Facebook, consiste à se servir des données récoltées sur le comportement des utilisateurs pour conduire des études et éventuellement en tirer des bénéfices. Cette pratique a été qualifiée de piggyback crowdsourcing par Doan et al. (2011) mais elle ne respecte pas la définition du crowdsourcing présentée ici.

Régime juridique du crowdsourcing

Chaque forme de crowdsourcing fonctionnant autour d’une plateforme (voir la rubrique sur les plateformes collaboratives), c’est l’entreprise ou l’organisation qui la possède qui fixe les règles, étant entendu que le choix de ces règles participe au succès ou à l’échec de la plateforme. Selon les types de tâches, les considérations juridiques peuvent d’ailleurs varier grandement.

D’une part, certains systèmes visent à récolter de la connaissance pure ou des données brutes, que la personne à l’origine de l’appel à la foule peut alors utiliser à sa guise, sans prendre la peine de les protéger, car elle sera seule à les posséder toutes (les contributeurs ne voient la plupart du temps que leurs propres contributions). Ce sera le cas de systèmes comme reCaptcha ou de ceux visant à recueillir les préférences de consommateurs.

D’autre part, la foule peut être co-créatrice de procédés brevetables ou de réalisations protégées par le droit d’auteur, comme dans les cas d’InnoCentive ou de Duolingo. La plate-forme se protège alors par des conditions générales d’utilisation précisant les conditions dans lesquelles les contributeurs lui cèdent leurs droits. Dans le cas d’InnoCentive, cela va même plus loin puisque ceux qui répondent à un appel signent aussi, bien souvent, des accords de confidentialité.

Enfin, certaines plateformes, se situant nettement dans le domaine des communs, rendent à la foule sa création, que ce soit par l’utilisation de licences libres (comme sur Wikipédia), ou par le partage des connaissances obtenues (comme dans le cas des sciences citoyennes).

Modèle économique du crowdsourcing

Le crowdsourcing peut être vu comme une forme d’économie collaborative. Comme souvent dans ce type d’économie, il met en jeu trois types d’acteurs : les demandeurs de service, les fournisseurs de service qui sont en grand nombre (la foule) et une plateforme d’intermédiation. La particularité du crowdsourcing comparé à d’autres formes d’économie collaborative est que les demandeurs sont bien moins nombreux que les fournisseurs de service. Les mêmes questions éthiques, juridiques et sociales se posent néanmoins sur les conditions de travail des contributeurs (considérés comme indépendants) et le niveau de leur rémunération. Elles sont extrêmement pertinentes pour les plateformes comme Amazon Mechanical Turk, où les travailleurs sont rémunérés mais très faiblement. Elles se posent moins lorsque les contributeurs participent gratuitement et volontairement (comme sur Duolingo) ou que l’appel à la foule prend la forme d’un concours dont le vainqueur seul est très bien récompensé (cas d’InnoCentive).

La faiblesse du coût du travail dans ce type d’économie explique que le crowdsourcing soit souvent présenté dans le monde des affaires comme une technique d’externalisation très rentable. Elle dépend cependant du succès très incertain de l’appel à la foule. L’intermédiaire fournit parfois alors une forte valeur ajoutée. Par conséquent, le coût d’utilisation de la plateforme peut représenter une part plus importante que le coût de la main d’œuvre. Ce sera évidemment le cas avec l’intermédiaire Duolingo, rémunéré par ses clients et ne reversant rien directement à ses utilisateurs, mais dont le service d’apprentissage des langues, très sophistiqué, permet d’attirer un nombre d’utilisateurs important et représente un coût d’investissement élevé pour l’entreprise.

Considérations techniques sur le crowdsourcing

Du point de vue technique, le crowdsourcing est une forme de calcul distribué où les éléments du réseau vers qui on distribue des tâches sont humains au lieu d’être des machines. Cependant, les mêmes considérations s’appliquent : comment décomposer la tâche ? Comment répartir les sous-tâches obtenues ? Et comment combiner les réponses in fine ? Certains types de tâches se décomposent puis se recomposent très bien (et ces deux étapes peuvent alors être gérées automatiquement par une machine). Ce sera notamment le cas de la production de données, par exemple l’annotation de corpus destinés à entraîner des algorithmes d’intelligence artificielle. Dans ce cas, les contributeurs travaillent de manière complètement indépendante les uns des autres. Globalement, on assiste à un type de collaboration homme-machine où, à l’inverse du modèle traditionnel, l’homme se charge de tâches que la machine lui a déléguées.

D’autres tâches, plus dures à décomposer et recomposer, nécessitent une communication entre les membres de la foule (qui finalement se charge aussi des étapes de décomposition et recomposition) : soit chacun propose sa propre solution mais en s’inspirant de ce que font les autres, soit tout le monde travaille sur une solution commune. Ce sera notamment le cas avec Duolingo et Wikipédia.

Distinction avec les notions voisines

La notion de crowdsourcing est à distinguer principalement de celle de production de pair-à-pair. Les deux sont rendues faciles grâce à internet et les deux proposent des formes de collaboration. Cependant, alors que la production pair-à-pair, souvent décentralisée, met l’accent sur le reversement du résultat obtenu dans les communs (les contributeurs sont récompensés de leur travail par le résultat obtenu de manière collaborative), le crowdsourcing est centralisé et asymétrique : les trois acteurs précédemment mentionnés jouent des rôles spécifiques et tirent des avantages distincts de leur interaction. Wikipédia et les logiciels libres sont donc des exemples de production pair-à-pair et non de crowdsourcing.

Bien que nous n’en parlions que très succinctement dans cette notice, le crowdsourcing n’est à distinguer du crowdfunding (ou plutôt financement participatif) qu’en ce que le deuxième est une espèce très particulière du premier. En effet, on retrouve dans le financement participatif les trois types d’acteurs et toutes les caractéristiques précédemment cités. Mais plutôt que de contribuer avec son intelligence, la foule contribue avec son argent. Cela implique des considérations bien différentes qui sont spécifiquement traitées dans la rubrique sur le sujet.

Pertinence comme modèle de communs

Le crowdsourcing est un processus participatif. En cela, il partage de nombreux traits avec d’autres processus à l’origine de nouveaux communs informationnels : une certaine ouverture, l’usage d’Internet et d’une communauté de contributeurs. Par conséquent, certains auteurs assimilent volontiers ces processus au terme, à la mode, de crowdsourcing, entretenant par là une certaine confusion et laissant croire que le crowdsourcing appartient systématiquement au domaine des communs.

En fait, cela dépend grandement de la politique choisie par la plate-forme de crowdsourcing. Dans le cas d’Amazon Mechanical Turk ou d’InnoCentive, la personne à l’origine de l’appel à la foule et payant le service récupère tous les droits sur les résultats. Souvent ces résultats ne seront même pas rendus publics. Cette privatisation du travail collectif se justifie juridiquement et moralement par le fait que les contributeurs sont rémunérés.

Au contraire, dans le cas de reCaptcha, les contributeurs ne sont ni volontaires, ni rémunérés. Si le but initial de reCaptcha (aider à la numérisation du patrimoine littéraire de l’humanité) allait effectivement dans le sens des communs, le service a ensuite servi à améliorer Google Street Maps et à entraîner divers algorithmes d’intelligence artificielle de Google. Ces deux derniers bénéfices ne seront pas reversés dans les communs mais profiteront aux contributeurs seulement s’ils utilisent les services de Google.

Similairement, Duolingo se situait, avec son service de traduction, à la frontière entre privatisation du travail gratuit des utilisateurs (justifié par le service d’apprentissage de langue fourni par la plateforme) et contribution aux communs. En effet, les documents qui étaient soumis aux apprenants pour traduction avaient deux origines : soit ils provenaient des clients de Duolingo, qui récupéraient alors le copyright sur le résultat de la traduction, soit il s’agissait de documents sous licence Creative Commons soumis par n’importe quel utilisateur (la traduction étant alors gratuite et reversée dans le commun).

Finalement, les projets de sciences citoyennes s’inscrivent de manière évidente dans le domaine des communs. Les données initiales et produites sont généralement intégralement publiques. De plus, le travail des contributeurs sert à enrichir le commun de la connaissance scientifique, bien que se pose alors de manière aiguë la question de l’accès aux résultats de la recherche (cf. la rubrique sur l’open access).

Repères bibliographiques

• Doan A., Ramakrishnan R. et Halevy A., « Crowdsourcing systems on the World-Wide Web », Communications of the ACM, 2011, n° 4, pp. 86-96. [PDF]
• Estellés-arolas E. et González-Ladrón-de-Guevara F., « Towards an integrated crowdsourcing definition », Journal of Information Science, 2012, n° 2, pp. 189-200. [PDF]
• Liotard I. et Revest V., « InnoCentive : un modèle hybride d’innovation basé sur l’innovation ouverte », Le Retour des communs, Les Liens qui Libèrent, 2015, pp. 151-169. [PDF]

In this market where trust is based on automatic proof checkers, we can imagine how disruptive a proof of False may be: someone who is able to make the checker believe that they can prove False can actually prove any theorem and therefore is able to claim payment for any awaiting conjecture. They can also produce programs that do not really meet the specifications they claim to meet.

Until we can have absolute certainty that a proof checker, such as the kernel of a proof assistant, does not make it possible to prove False,¹ we need to leave room for this possibility and take measures so that it does not break havoc.²

To prevent a large disruptive effect, we need to have counter-measures for when a proof of False is found, and as soon as we acknowledge this, it becomes clear that we need to incentivize people to prove False and to share their proofs, by paying them for such a proof³ (in order to trigger said counter-measures).

What would counter-measures be like?

The basic idea is rather simple: as soon as a proof of False has been found, freeze the entire market for the time it takes for the developers of the proof checker to release a new version where the bug has been fixed. Once such a version is released, check all existing proofs and put transactions that are linked to a proof that does not check anymore on hold. If a proof was relying on a lemma that has been invalidated, the proof (and the associated transaction) can still be saved by finding an alternative proof to the lemma. Alternatively, if a transaction is associated to a theorem whose negation happens to be provable, or if no valid proof can be found for a reasonable delay, revert the transaction.

This looks like transaction history rewriting, like the hard fork of Ethereum blockchain after the DAO event, but this is different because here the reverting of such transactions is part of the predefined crypto-currency protocol so there is no debating to do on the legitimacy of such an action.

How to make sure that people share their proof of False rather than using them to steal other people’s money?

All proofs are public and people may look at them carefully to see whether they look suspicious or not. If a proof looks suspicious, then the person who finds the proof suspicious can try to derive a proof of False from it, either by proving that the theorem that is proved is actually wrong, or by extracting the fallacious argument (hack exploiting a critical bug) from the proof and using it to prove False directly. Then the person gets the reward and the original author of the suspicious proof loses their own rewards. Given that this is bound to happen, the self-interest of the original author pushes them to share their proof of False directly.

Where does the money for paying proofs of False come from?

The first solution that comes to the mind is to create these rewards out of fin air. Unfortunately, sudden creation of money decreases the value of the currency for everyone, and thus each proof of False has a negative impact on the whole market. This impact is unpredictable.

Another solution is inspired by CDS (credit default swaps): people can bet that no proof of False will be found by buying these bonds. The bonds have a predictable growth rate. Whenever a proof of False is found, the bonds serve to pay the reward and thus some people lose money but the actual market is unaffected (the money to pay the CDS rent is created⁴ in a fully predictable way).

This form of self-insurance would moreover be a strong driver to get a more and more resilient proof checker.

We could discuss how these bonds would work in more details, although this is not the subject of this post. Bonds could be created at regular intervals and so the longer since the last proof of False, the bigger the reward is (and the less interesting not sharing a proof of False becomes). The rent for these bonds could slowly decrease over time to compensate for the creation of new bonds (but sufficiently slowly so that people are well compensated for their initial investment). At bond creation, there could be an auction to choose who gets to buy it first and at what price.

Note that this might not be completely sufficient to avoid a sudden bad impact of a proof of False on the market, because if people start to believe that there is no proof of False left to be found, then they can start to think that the (large) reward for such a proof is never going to be claimed, and thus that this represents an amount of money that is actually out of the currency system. If such a belief is then contradicted, this would still create a shock.

Limitations

A first, important, limitation is the strong link required between the proof market and the crypto-currency itself. This is not without reason though, as smart contracts (which are basically programs) based upon invalidated proofs that they meet certain specifications would need to be invalidated as well.

A second limitation is the uncertainty that this places upon any transaction in the system. If some transactions happen to be reverted, then the wallet that was used to send you money may not have had enough money to actually do so. Then you will lose whatever exceeding amount you have received from this wallet. If this means that you, in turn, would not have been able to realize some transactions you previously conducted, the recipient may lose part of their money as well…

This inherent risk to any transaction may be evaluated and taken into account. With a public transaction record, it is easy to compute a risk factor depending on the amount available in the payer’s wallet, the part of this money that comes directly from rewards in the proof market and how long the associated proofs have been there, and recursively the risk associated to each of the transactions the rest of the money comes from. If this risk is too high, it might be a reason to refuse a transaction. Otherwise, the associated risk might just be taken into account as a supplementary fee.

An alternative solution to both of these limitations is to make the proof market use its own reward tokens that can be converted into real digital coins only after some time has elapsed. Then only the internal transactions in the proof market can be reverted and there is no risk associated to transactions that take place outside of it. This supposes to define what delay would be sufficient to guarantee with near certainty that the proofs that were submitted are not suspicious.

Conclusion

We may legitimately ask whether this whole protocol is necessary. At the moment, proof checkers are not critical enough applications to be fully trustworthy in an adversarial context. They are very helpful to verify critical applications, but in this case the proof author is not trying to fool the checker, and the risk of accidentally exploiting a bug is much lower. We could wait until a proof checker is, itself, formally verified (a huge task but still bound to happen in the future). However, we would still be trusting a conjecture: that the underlying logic is consistent.⁵ That in itself may not be viewed as such a big problem, given that the whole field of cryptography, and therefore crypto-currencies as well, already depend on a conjecture.

I started contributing to Coq in 2015. This year, the Coq development team was organizing the first Coding Sprint (later renamed into the Coq Implementors Workshop) and was accepting pull requests on the GitHub repository to get patches from external contributors¹. Back in these days, almost none of the development was carried out through pull requests (I opened PR #68). Things have changed dramatically since then.

Pull requests are now used routinely to review other developers’ patches before integrating them; continuous integration was introduced to automatically test whether a proposed change breaks a number of tracked external developments (plugins and libraries)². These new processes have brought much stability to the software at the price of a reasonably small overhead. They have also demonstrated to be an excellent tool for sharing knowledge.

Meanwhile, bugs continued to be reported on Bugzilla, the bug tracker that was used since July 2007 (after a first migration from JitterBug). Bugzilla suffered from many drawbacks that were made all the more apparent when comparing to the much nicer experience we were having in pull request discussions on GitHub.

Simply setting e-mail notifications for new bug reports was a hard task: we had the mailing list coq-bugs-redist@lists.gforge.inria.fr which was connected to a Bugzilla account that was put in cc of all new bug reports. But to subscribe to this mailing list, you had to get moderator approval and, for some time, no one was administrating this mailing list anymore³.

More importantly, the lack of edition features, the difficulty to search an issue, the loading times, the intimidating UI had a (non-quantified but probably) significant impact on the developers, who tended to prefer slightly off-topic discussions and digressions in a pull request thread, rather than discussing each specific issue in a separate thread on Bugzilla.

In April 2017, I opened a wiki page to discuss the possible alternatives. Having a strong preference for gathering all our tools on GitHub, I documented this one (and no one really documented any other alternative, even if they existed).

In August, the Coq website was down for more than a week because of an over-reaction of the IT services to an alleged hacking of the bug tracker (in fact just a spam). This was a good opportunity to discuss once more a migration to GitHub issues (with hosting less dynamic, subject-to-attack, content as a nice benefit).

While I was initially proposing a transition during which we would be using both bug trackers in parallel, the need to keep bug numbers as much as possible was expressed and a script was found⁴ which was designed for that purpose.

The migration script

The migration script that was found is a Python script⁵ which takes an export from Bugzilla to XML as input and uses the GitHub API to create new issues for every bug reports. It inserts first the bug reports whose number it can keep⁶ and only when this is done it inserts bug reports that need to be renumbered.

Because issue numbers are attributed by GitHub at creation time and are not chosen by the issue author, it is not possible to skip some non-existent bug number. That’s why the script contained an initial check that the input bug numbers are contiguous. This was not the case for the Coq Bugzilla: many bugs had been deleted, especially in the early years. Thus, the first modification that I did to this script was to use postponed bug reports to fill the holes (missing bug numbers) to recreate continuity in the result. This worked because the number of pull requests was already higher than the number of holes.

To increase the predictability of new issue numbers, it was important that no issue or pull request be opened during the few hours that the migration took to complete. This was achieved thanks to the “cool-down” feature that GitHub provides.

We wanted to limit interaction permissions as much as possible during the migration, but removing contributors also meant losing the ability to assign issues to them. The solution that was found was to add all the people who had bug reports assigned to them to the External team of the Coq organization, then temporarily restrict the permissions of this team to “Read” (basically the same thing as anyone else given that this is a public repository).

Another critical issue with the script was that the GitHub API was limiting issue creation to 300, after what it refused any new posting for the next 30 minutes (not just through the API by the way, during my tests I was also prevented from manually posting comments during this delay). While I initially implemented a wait-period, this limitation was going to make the migration unbearably long. Fortunately, after reaching out to GitHub support, they explained that this limitation was imposed on any interaction that emitted notifications but that they also provided a beta API specifically dedicated to issue import that had many notable advantages, one of them being that new issues created through this API did not emit notifications, and thus were not submitted to the same rate limits.

There are many more advantages to this API: you can create at once an issue and many comments, set creation dates for each of them, assign someone, set a milestone and some labels, etc. Adapting the script to this API was easy: the main difference is that the API is asynchronous. To ensure that issue numbers are predictable, you must make it synchronous by sending GET requests to check whether an issue has been created before sending the next one. On the advice of GitHub support, I implemented a back-off approach: first wait one second before sending the GET request, if still pending wait for twice that time before sending another request, if still pending wait for twice the previous time, etc. The one-second delay meant that we could not import more than 3600 issues per hour in theory (in practice the migration almost took four hours, which indicates that many times it took more than one second to import an issue; I did not collect this information, unfortunately).

On the other hand, the API still has some limitations: you can’t recreate the complete history of closing/re-opening and assignments, the labels and the assignees are put at issue import time, whereas you can set the closing date. I regret not having set the updated_at field: I did not see what purpose it served: in fact it is useful when you sort issues by “Recently updated” (then GitHub displays the date of the last update).

This API does not allow you to choose the author of issues / comments either and requires API requests to be authenticated with a repository administrator API token. That’s why our bot account @coqbot appears as the author of all imported issues and comments.

Some other improvements of the script included saving a trace of imported bug reports with the Bugzilla / GitHub ID correspondence, and using this to safely recover from possible crashes, fixing most references to other bug reports, and some very Coq-specific stuff like not displaying comment authors for the first 1657 comments because these were imported from JitterBug to Bugzilla ten years ago and the migration attributed all the comments in a given bug report to the initial reporter.

The resulting script is, I believe, largely improved over the original one but also not as generic. If you wish to use it for your own migration, feel free to do so and don’t forget to remove the Coq-specific material first. If you want to share the result, especially if it is more generic, and thus a better basis for future users, I will be happy to add the link from this post.

Epilogue

The migration was formally approved at the Coq Working Group on Oct 3-4th, 2017, and was conducted right after the 8.7.0 release, on the morning of October 18th. It was preceded by a series of e-mails to announce it and the fact that both bug trackers (the old and the new one) would be read-only for the duration of the migration.

All the bugs with a number below 1154 had to be renumbered, you can find a nice correspondence table with a search bar here. All the other bugs kept their number.

While the migration went smoothly, only time will tell how effective the change was on the development organization. I plan to fiddle with the GitHub API some more to get interesting statistics of issue creation before and after the migration (with the cool advantage that dates have been preserved for bug reports from before the migration), how long it takes to solve a bug on average, the growth of unsolved issues, etc. If you know of some services or scripts that already provides such statistics, I would be happy to know about them.

In other news, Pierre Letouzey has migrated the Coq wiki to GitHub as well :) which means that the Coq website is fully static now.

Updates

• Pierre has reused the correspondence table to redirect previous Bugzilla URLs to new GitHub ones. For instance, https://coq.inria.fr/bugs/show_bug.cgi?id=2 now redirects to https://github.com/coq/coq/issues/1156 and https://coq.inria.fr/bugs/show_bug.cgi?id=1153 now redirects to https://github.com/coq/coq/issues/5970.
• Erik Martin-Dorel has adapted the script to the migration of issues from a GitHub repository to another one and has used it successfully to migrate the 101 issues from https://github.com/psteckler/ProofGeneral to https://github.com/ProofGeneral/PG. The new script is available at https://github.com/erikmd/github-issues-import-api-tools.

Like every programmer, I have known the Stack Overflow Q&A website for a long time now. For our community, it probably was one of the most important innovations of the recent years and it is now a routinely used tool. Have a question on programming? You google it, and you are most likely to find, among the first results, one or several questions on Stack Overflow with good answers to your problem. A little bit like when googling for a general notion, one of the first results should probably be a Wikipedia page.

This is one of the key aspects of the platform. Most of its traffic comes from search engines and, similarly to Wikipedia, most viewers are just that: viewers. The platform does not try and actually does not want to convert most of the viewers into users because they would not bring significant value (value for the platform being good questions and most importantly good answers). In that respect, it is taking a very different approach compared to all the “social” platforms that pop up these days, and in particular it is much different from Quora, a competitor Q&A platform, which used to require signing up just to view a single question (I never did; now it asks me to sign up to view a second question).

The second and the most known component of the platform formula is to award “reputation”. Users earn reputation points by asking good questions and giving good answers and being up-voted by other users. Reputation has an inherent value for some programmers because it can help demonstrate to future employers that you possess expert skills which have been recognized by others. The same teacher who encouraged the students in my class to create a blog and a LinkedIn account also told us about earning reputation on Stack Overflow.

Reputation is also key to getting more involved in the community itself as you can unlock new privileges when reaching certain levels. Thus, it acts as XP in video games and it actually helps gamifying the whole activity of helping each other out. And it acts as a filter. By not getting full access to the website features right from the start, new users are taken through a path which will teach them how to properly interact with it. Only with some reputation can you start up-voting, later you can start leaving comments, later still you can start down-voting.

The community self-moderates. Moderation is crowd-sourced, as people with enough moderation can vote to close down bad questions. The dreaded down-vote is one main source of moderation. And it is one of the barrier to overpass when you are a new user because you are most likely to not fully understand the website requirements¹. Thus people may down-vote your question. It can feel a bit harsh. But then if you are wise, you edit or delete your question and learn from the experience².

Questions should show research: don’t ask what is obvious. Questions are supposed to serve as a canonical documentation for later viewers: duplicates are banned. While it is generally not recommended to dig up an old thread on a traditional forum, it is very much encouraged to add your answer or a comment or your vote to an old question.

StackOverflow is organized with tags, and this is very useful given the number of questions the site receives. Given that I am not too much into mainstream technologies, I can reduce drastically the number of questions I see by following only the tags which I am interested in. This year, I started following the Coq tag for the same reason I follow the Coq-Club mailing list: to know what the questions of beginners are, and to learn from the answers that other people give.

The adventure of crowd-sourced documentation

In August of this year, Stack Overflow introduced Documentation in public beta. They got my attention immediately as I want to see how they can apply their reputation-based methodology to the more complicated problem of mass collaboration for writing. So far, only Wikipedia has developed a successful model for such mass collaboration.

Wikipedia’s model is based on a posteriori moderation: anyone can contribute anytime and their edit is live immediately, but some people and some bots are constantly reviewing recent changes and when changes do not respect the rules, or obviously decrease the page’s quality, they are reverted.

On the contrary, Stack Overflow’s model revolves around reputation-based a priori moderation. To start proposing changes to the documentation on one particular programming language, you will first have to demonstrate your skills by getting up-votes for an answer on this language.

According to Michael Nielsen in Reinventing discovery, the wiki-novel “A Million Penguins” was a failure mainly because moderation was done by a limited group of persons (students in fact) who could not keep up with all the contributions which arrived due to the publicity around the project. Stack Overflow does not do this mistake by having a large body of reviewers (anyone above a certain level of reputation). Although several positive reviews are necessary to approve an edit, there have still been problems with bad edits being approved too often³. While reverts (“rollbacks”) are possible, they are not supposed to be part of the standard workflow.

After being curious at the beginning and even contributing some documentation about Elm (a programming language I recently got interested in), I was a bit disappointed by the current result and stopped participating (this was also the beginning of my PhD so I had other topics with higher priority). Still, I think this will be interesting to see what this Documentation feature gives after a longer period of gradual improvements.

Update: As of August 2017, Stack Overflow has decided to shutdown the documentation, showing once again how hard organizing collaborative writing is.

The Stack Exchange galaxy

As Stack Overflow kicked off right from the start, new Q&A sites were added by the team so that other domains and other communities could benefit from the same reputation-based software. No site has ever reached the size of Stack Overflow, which is huge, but some of them have become pretty well-known on their own and all have an active community.

Nowadays, the process to create a new site is entirely community-driven. There is a series of steps to go through, and a special site dedicated to the creation of new sites: Area 51. This is somewhat comforting me a little from the fact that the software is not open source⁴. You cannot run your own instance, but at least if you gain enough momentum you can start a new site on a new topic.

Among the sites that were added lately (only one and a half year ago actually, so it is seven years younger than Stack Overflow) is a beta site on free and open source software. I registered four months ago to answer a question which was on the verge of being closed because people thought it was not answerable objectively. Since then, I’ve answered 46 more questions, always happy to spread the good word and to help out people who struggle to understand the complicated world of copyright and licenses (questions about licenses are what this site gets the most). This has also helped me gain reputation faster than on StackOverflow, and thus has allowed me to test and better understand the various priviledges and moderation tools so that I could write this blog post.

But it would be absolutely naive to be content with rejecting electronic voting on the whole because it is already in use everywhere: from professional elections, to associations… and even in certain political elections. Moreover, many politicians are now advocating for a general implementation of electronic voting, in particular with the aim of improving the rate of participation. We therefore shouldn’t refuse to look at and analyze the risks and benefits induced by this type of ballot. Or rather, we should say, these types of ballots. Electronic voting can be of two very different kinds: voting machines and Internet voting. We will deal with both but take care to distinguish between their issues.

Read the rest of this article on Kinea, the multilingual magazine where it was published.

Sauf qu’il serait tout à fait naïf de se contenter de rejeter en bloc le vote électronique, car celui-ci est déjà partout : élections professionnelles, associatives… et même certaines élections politiques. De plus, de nombreux politiciens défendent désormais une généralisation du vote électronique, notamment en vue d’améliorer le taux de participation. Ne nous voilons donc pas la face et analysons quels sont les risques et les bénéfices induits par ce mode de scrutin. Ou plutôt devrions-nous dire ces modes de scrutins. Le vote électronique peut être de deux natures, bien différentes : machines de vote ou vote par internet. Nous traiterons ici des deux mais en prenant soin de distinguer les enjeux.

Continuez à lire cet article sur Kinea, le magazine plurilingue sur lequel il a été publié…

On peut tout de même faire des hypothèses sur les raisons de cette crise et je me permettrai d’en faire une. Les régimes démocratiques et les contextes sont bien différents d’un pays à l’autre. Qu’est-ce qui a changé partout à la fois pour provoquer cette crise généralisée ? L’une des nouveautés est l’apparition et la démocratisation d’internet, du web plus précisément, et, à travers ce biais, d’une multiplicité des sources d’information. Nos représentant.e.s ne sont peut-être pas moins bon.ne.s qu’avant mais ils/elles le paraissent car nous avons plus de moyens de nous informer sur leurs travers et le mécontentement se répand plus facilement.

Nous pouvons donc aujourd’hui prendre la mesure des limites de nos systèmes de démocratie représentative et c’est une raison bien suffisante pour souhaiter les rendre meilleurs. Peut-être l’outil qui aura permis de percer à jour les limites du système sera-t-il également utile pour en proposer un nouveau ?

C’est ce que pensent aujourd’hui beaucoup de gens : ceux/celles qui défendent la mobilisation citoyenne en ligne (par exemple Avaaz), ceux/celles qui testent la démocratie participative ou bien sont les chantres de l’open government ou de la démocratie ouverte. Et grâce à ces gens les choses avancent en effet : les mobilisations en ligne organisées par Avaaz et d’autres associations ont parfois des retombées très fortes ; le budget participatif mis en place par la maire de Paris a joui d’un grand succès ; la plate-forme Parlement & Citoyens a déjà attiré l’attention d’un grand nombre de parlementaires ; et pour la première fois en France, un projet de loi a été soumis aux amendements populaires avant son examen en Conseil des Ministres (loi sur la République Numérique).

Dans ce contexte, ce foisonnement d’idées, j’aurais tort de garder les miennes pour moi. Voici un projet qui me tourne dans la tête depuis déjà plus d’un an.

“Nul n’est censé ignorer la loi.” Ce principe de base, essentiel pour que la justice puisse fonctionner, est mis à mal, d’une part par la complexité des lois, d’autre part par la boulimie législative. Sans verser dans la pensée ultra-libérale qui consisterait à donner un grand coup de pied dans la fourmilière en supprimant, brutalement, 90% des textes de loi, on peut légitimement se demander si un peu de ménage ne serait pas nécessaire. C’est le constat qui est à la base de ce projet et c’est ce qui le distingue d’autres, plus courants, dont le but est d’inclure le/la citoyen.ne dans la préparation de nouvelles lois (toujours de nouvelles lois !).

Réapproprions-nous la loi !

La première étape, essentielle, c’est que nous soyons tous en mesure de comprendre la loi, au moins les textes qui nous concernent. Nombre de services de conseil juridique fleurissent sur le web. Certains sont très bien faits. Certains sont proposés par des associations, certains même le sont par l’État (Service-Public.fr). Cependant plutôt que de nous aider à comprendre la loi, ils nous aident à comprendre ce qu’il faut faire, ne pas faire, comment le faire. D’autre part, il y a Légifrance¹. Ce site permet de lire la loi, de comprendre comment elle est faite, mais pas ce qu’elle veut dire (dans cet esprit, voir aussi des initiatives privées telles que celle de Steeve Morin).

Pour que les citoyen.ne.s lisent enfin la loi lorsqu’ils/elles se posent des questions juridiques, mettons les explications en relation avec les textes ! Créons un outil (une plate-forme) qui permette d’une part de poser des questions juridiques et d’obtenir des réponses, par des gens qui se réfèrent aux textes, d’autre part de parcourir la loi et de voir, au fil du texte, les questions/réponses qui y ont été associées. Et qui permette, si un passage de la loi n’est pas clair et que rien n’y est encore associé, de le commenter…

Dépoussiérons la loi !

La suite vient d’elle-même. Si on s’amuse à parcourir la loi grâce à un outil bien fait, on tombera nécessairement sur des anachronismes (comme cette loi qui interdisait aux femmes de porter le pantalon et qui n’avait jamais été abrogée), on tombera sur des contradictions, ou on tombera sur des textes absurdes ou scandaleux. En effet, l’entretien n’a jamais été le fort des législat.eur/rice.s. On préfère s’assurer d’avoir une loi à son nom plutôt que d’abroger les lois datées. C’est donc aux citoyen.ne.s de s’emparer de cette tâche. Un outil bien pensé peut le permettre.

À la manière d’un wiki, on commencerait par rendre la loi “éditable”. Mais il est bien évidemment plus sensible de changer la loi que d’éditer une page d’encyclopédie. Il faudrait donc faire apparaître les modifications proposées par les citoyen.ne.s pour ce qu’elles sont : des propositions (on retrouve d’ailleurs une connexion avec l’outil commented.it). Notre outil pourrait facilement aller plus loin et générer automatiquement une proposition de loi correspondant à la modification (les propositions de loi ne sont jamais que des patchs, c’est-à-dire des descriptifs à apporter au code – code civil ou code source – pour passer de la version actuelle à la version proposée).

Promouvons les changements !

La première étape est rendue possible par la plate-forme et repose sur des initiatives individuelles, ainsi que des discussions de type commentaires. La seconde étape, plus délicate, consiste à vérifier si les propositions énoncées sont plébiscitées et éventuellement à les améliorer suite aux retours d’autres citoyen.ne.s, d’expert.e.s de la question traitée, et d’expert.e.s juridiques. À partir de là, plusieurs voies sont possibles.

Les voies du consensus sont les plus faciles à emprunter et pourraient être la priorité de la plate-forme : si la proposition est massivement rejetée, elle est enterrée ; si elle est massivement plébiscitée par les citoyen.ne.s utilisant la plate-forme, elle prend son envol.

C’est alors le rôle de l’association² soutenant la plate-forme que de lancer des enquêtes d’opinion pour évaluer si la proposition, largement soutenue par la communauté, est aussi largement soutenue chez les personnes qui n’ont pas rejoint le mouvement. Si c’est le cas et qu’il s’avère que la proposition est soutenue à l’échelle de la société toute entière, la dernière étape est celle du lobbying vis-à-vis des parlementaires pour faire inscrire la proposition de loi (toute prête) à l’agenda législatif et pour la faire voter. Cette étape ne sera sans doute pas la plus difficile : les grandes ONG sont déjà spécialistes de ce genre de choses et les parlementaires sont sensibles aux enquêtes d’opinion.

Organisons le débat

Il serait pour autant mesquin de se borner à traiter les propositions consensuelles (même si celles-ci doivent recevoir la priorité). Lorsqu’une proposition ne fait pas consensus, elle mérite un débat.

On dit que la démocratie directe ne marcherait pas parce que les sujets discutés au Parlement sont trop compliqués et demandent trop de préparation. En vrai, ils sont trop compliqués pour nos représentant.e.s qui, mal préparé.e.s, ne prennent même pas la peine de participer aux débats et font confiance au/à la seul.e spécialiste du sujet de leur groupe politique.

Un bon système démocratique laisserait débattre pour chaque sujet les milliers de vrai.e.s spécialistes qu’on peut trouver dans le pays, ensuite de quoi le peuple serait l’arbitre. Il y a, à mon avis, beaucoup à inventer pour organiser des débats sérieux, pendant lesquels les spécialistes ne s’écharperaient pas comme on le fait trop souvent en politique et ne chercheraient pas non plus à embobiner le public. Il y a un modèle à inventer pour que les contributions à haute valeur ajoutée aient de l’impact et que les mensonges et faux-arguments se retournent contre leurs auteur.e.s.

Ne passons pas à côté de la moitié des textes

La Constitution et la loi sont une chose mais beaucoup se décide également au niveau des décrets d’application, des ordonnances, des arrêtés locaux, de la réglementation européenne, des accords de branche, des traités internationaux. Tous les textes nous impactant méritent le même coup de projecteur, même s’il est clair que certains seront plus faciles à modifier que d’autres³.

Aujourd’hui les « solutions collaboratives » sont à la mode ainsi que « l’innovation ouverte » (et plus généralement ce qui est « ouvert »). Peut-on tout créer de manière collaborative ? Quand il s’agit de création artistique on est en droit d’en douter. Cependant on voit fleurir des initiatives s’engageant résolument dans cette direction.

Avec Jules Zimmermann, nous nous sommes posés la question, voilà maintenant un an, de savoir s’il était possible de créer un roman de manière entièrement collaborative (en excluant la collaboration à petite échelle de deux ou trois auteur·trice·s ou encore la collaboration limitée, où chacun·e écrit un chapitre). Nous n’avons pas encore la réponse.

Nous ne sommes pas les premiers à nous poser cette question, ce qui laisse penser que si une solution existe, elle n’est pas simple.

Solutions pour une collaboration massive (non littéraire)

Lorsqu’on observe le monde de la création collaborative, via internet, on rencontre deux modèles à succès. Tout d’abord il y a le logiciel libre, premier avatar dans l’histoire moderne de « l’ouvert » et du « collaboratif ». Le logiciel libre ne fournit pas un modèle universel de collaboration, chaque projet a le sien propre et la plupart ont d’ailleurs un modèle simple, celui où quelqu’un a tout fait dans son coin. Mais un certain modèle de collaboration pour le logiciel libre a la cote. Ce modèle, c’est celui de GitHub.

Le modèle de GitHub se décrit rapidement comme ceci : une petite équipe gère un dépôt ouvert contenant le code d’un logiciel libre. Des contributeur·trice·s extérieur·e·s soumettent des rapports de bug ainsi que des patchs. Sur GitHub, ces patchs prennent la forme de pull requests avec l’avantage qu’on peut très facilement observer les modifications proposées et en discuter (c’est certainement la clé du succès de cette plateforme, le principe de l’équipe cœur et des patchs lui étant antérieur).

L’autre modèle à succès de la collaboration massive, c’est celui de Wikipédia. Le principe du wiki est le plus simple qui soit : quiconque peut, à loisir, modifier une page quelconque de l’encyclopédie. Cependant, la clé du succès de ce modèle de collaboration réside dans le fait que l’historique des modifications est sauvegardé et que toute modification est réversible en un clic si elle s’avère inappropriée. Des modérateur·trice·s exercent donc un contrôle a posteriori, à l’aide d’outils spécialisés leur permettant de voir les modifications en temps réel. À cela on ajoutera que les pages les plus fréquemment vandalisées sont davantage protégées en y restreignant les droits de modifications aux utilisateur·trice·s enregistré·e·s, tout simplement.

Devant ces deux grands succès, on peut penser que l’une ou l’autre des solutions se transposera bien au cas de la création littéraire. Aucune modification ne devrait même être nécessaire, les deux permettant de travailler sur du texte (qu’est-ce qu’un code source sinon du texte). Voyons ce que ça a donné.

Le modèle de GitHub a bien été appliqué à l’écriture collaborative. À l’heure où j’écris ces lignes, 12 projets en rapport avec l’écriture sont mis en avant par GitHub (mise à jour : GitHub n’a jamais maintenu cette liste et a maintenant supprimé la page en question, d’où un lien vers Internet Archive). Sur ces projets, la plupart sont des tutoriels ou des manuels. Il s’avère que nous avons donc là un bon modèle, non seulement pour collaborer sur du code, mais aussi sur des tutoriels (de programmation soit dit en passant). Un seul projet sur douze est un roman mais quand on observe la page des contributions, on découvre le motif reconnaissable des projets reposant sur un seul homme : le premier contributeur (c’est-à-dire l’auteur) a écrit 100 000 lignes. Le second contributeur le plus prolifique a proposé deux modifications seulement, modifiant 10 lignes en tout.

On peut se dire que le modèle est le bon mais que l’outil est trop compliqué à utiliser pour des écrivain·e·s non-programmeur·se·s (ce qui expliquerait pourquoi tous les tutoriels ainsi écrits parlent de programmation). C’est le pari de Penflip, une copie de GitHub destinée aux écrivain·e·s. Ça a l’air plutôt réussi mais ça n’a pas l’air d’avoir donné lieu à une grande créativité jusqu’à présent.

Wikipédia étant un exemple réussi d’écriture collaborative, pourquoi ne pas faire un « wikiroman » ? Nombreux·ses sont ceux·lles qui y ont pensé. Le plus médiatique exemple a été celui lancé avec des roulements de tambours par la maison d’édition Penguins. Le projet, appelé « One million penguins », a été confié à un groupe d’étudiant·e·s chargé·e·s de le superviser. Hélas, la communication autour de ce projet a provoqué sa perte : les étudiant·e·s-éditeur·trice·s ont été débordé·e·s par le nombre de participant·e·s. De plus, en choisissant d’activer une modération a priori, l’équipe a tué l’idée géniale du wiki et s’est retrouvée avec le modèle précédent (celui de GitHub) dans un outil inadapté.

Solutions pour une collaboration restreinte

De l’autre côté du spectre des outils dits « collaboratifs » il y a Google Docs. Google Docs est un outil génial lorsque l’on veut collaborer sur un document avec relativement peu de monde. Il comporte deux modes principaux d’édition.

• Le mode Édition fonctionne sur le même principe que le wiki. On peut simplement faire ses modifications dans le corps du texte. Comme ce n’est pas prévu pour une collaboration massive, les outils pour contrôler l’historique des modifications et revenir à une version précédente, bien qu’existant, ne sont pas aussi accessibles et évidents à utiliser.
• Le mode Suggestion est inspiré du mode Révision ou Suivi des modifications qui existait dans Word depuis longtemps. Toute modification dans le corps du texte est traquée et marquée comme telle. À cela s’ajoute la possibilité de lancer une discussion à partir d’un commentaire ou d’une suggestion de modification.

Cette discussion en marge de la page, qui n’est rien d’autre que la note griffonnée depuis toujours dans un livre rendue sociale, est un concept qui a aussi pris récemment son essor. On la retrouve notamment chez Medium.com (chez qui les commentaires sont remplacés par des « notes » qui flottent à côté de chaque paragraphe¹). Cette fonctionnalité est d’ailleurs mise en avant comme « le mécanisme central de collaboration sur Medium ».

Solution pour une collaboration massive (littéraire)

Il n’y a plus qu’un pas à faire pour proposer un outil, s’inspirant de tous ces modes de collaboration mais différent, qui soit adapté à une collaboration massive sur un texte littéraire (mais pas que).

On décrira très succinctement cet outil auquel on a donné le nom de commented.it (et dont une version simplifiée se trouve sur la page de présentation du projet unkilodeplumes — mise à jour : le système n’est pas maintenu et n’est plus en démonstration sur ce site). Il consiste à faire figurer en parallèle le texte et une colonne de commentaires. Ces commentaires peuvent être associés à des propositions de modification (pendant des pull requests de GitHub). Comme dans Google Docs, ces modifications sont clairement marquées (suppressions barrées et surlignées de rouge, ajouts soulignés et surlignés de vert). Mais contrairement à Google Docs où ces modifications apparaissent directement dans le texte, il faut là cliquer pour les afficher. Ce choix permet la collaboration massive, quand un Google Doc deviendrait surchargé avec toutes les propositions de modification, d’auteur·trice·s différent·e·s, sans rapport les unes avec les autres. Comme sur Medium, les discussions ont lieu par « blocs » de texte, et sont donc liées au contexte. Enfin, on peut voter en faveur d’une modification. Un·e adminstrateur·trice de la page peut ensuite « valider » les propositions les plus populaires en les intégrant au texte.

De là à l’écriture collaborative d’un roman…

C’était là notre défi initial et nous n’y sommes pas encore. Si nous pensons que notre concept peut être utile dans ce but, il faudra noter que commented.it (que vous pouvez aussi prononcer comment-edit) ne fournit pas de modèle pour toutes les étapes de la création. Comme tous les autres outils dont j’ai parlé ici, il est bien adapté à l’édition collaborative d’un texte. Qui se charge de l’écriture d’un texte initial ?

Dans le cas des logiciels libres, tutoriels ou pages d’encyclopédie, c’est une personne seule qui commence le travail. Puis, des paragraphes sont ajoutés, ici et là. Est-ce que ça marcherait pour un roman, dont l’écriture est traditionnellement beaucoup plus linéaire ? Il faut expérimenter pour savoir. Mais même cette étape initiale d’écriture, nous aurions voulu la remplacer par un processus collaboratif, à savoir une « foire aux scenarii » puis une « foire aux textes », selon des modes et avec des outils qu’il reste à inventer…

La plus grande vulnérabilité est l’absence de garantie que l’expéditeur/trice est bien celui/celle indiqué-e. Exactement comme quand vous recevez une lettre par la Poste d’ailleurs, à moins que vous ne reconnaissiez l’écriture. La seconde vulnérabilité c’est que les mails sont a priori visibles par les acteurs qui les transmettent comme les cartes postales peuvent êtres lues par les facteurs.

Heureusement, il existe des mesures pour sécuriser ses mails. Ces techniques sont presque aussi vieilles que les mails eux-mêmes mais elles deviennent de plus en plus simples à mettre en place.

Dans ce billet, je vous propose de commencer très doucement : vous allez apprendre à vérifier que les mails que je vous envoie ont bien été écrits par moi. Ainsi, si un jour vous recevez un mail de moi vous disant que je suis coincé en Grèce et qu’il faut que vous me fassiez un virement sur un compte à l’étranger pour m’aider, il vous sera alors très simple de contrôler si oui ou non, je suis bien à l’origine du message.

Instructions si vous utilisez un webmail

(Si vous n’utilisez pas un webmail, sautez cette section.)

• Installez l’extension Mailvelope depuis le site officiel.
• Une fois l’installation terminée, une icône de cadenas est apparue dans votre navigateur. Cliquez dessus puis sur Options.

• Cliquez sur Importer les clés.
• Téléchargez ce fichier qui contient ma clé publique puis sélectionnez-le depuis l’interface de Mailvelope et validez en cliquant sur Importer.
• Ouvrez votre webmail. Si c’est autre chose que Gmail, Live ou Yahoo, il vous faudra probablement commencer par dire à Mailvelope de le reconnaître (en deux clics : depuis l’onglet de votre webmail, cliquez sur le cadenas de Mailvelope puis sur Ajouter) et éventuellement relancer votre navigateur.
• Cherchez un vieil e-mail signé de moi. Les mails signés sont facilement identifiables car ils commencent par la ligne :

-----BEGIN PGP SIGNED MESSAGE-----

Normalement, la seconde partie du message (la signature) est désormais recouverte d’un cachet. En cliquant dessus, la signature est vérifiée !

Désormais, vous pourrez facilement vérifier la signature des nouveaux mails que je vous envoie :)

Les cas problématiques

Mailvelope a été conçu pour rendre facile l’utilisation d’une technologie complexe. Hélas, les webmails ne lui rendent pas toujours la tâche facile.

Le problème PGP/MIME

Il existe deux types de signatures : dans le corps du message ou en pièce jointe. Mailvelope ne supporte que le premier type car il ne peut pas ouvrir vos pièces jointes. Or le second type est assez répandu. Dans mon cas, je fais attention d’envoyer des signatures du premier type le plus souvent possible.

Mais pour pouvoir signer des pièces jointes², seule la seconde solution fonctionne. Dans ce cas, vous ne pourrez pas vérifier la signature avec Mailvelope.

Des webmails trop malins

Lorsque vous incluez le texte des messages précédents dans votre réponse (ce qui est le comportement de la plupart des utilisateurs/trices), certains webmails tels que Gmail décident de masquer cette partie du mail. Le problème c’est que ce texte faisait intégralement partie du message et le masquer peut mener Mailvelope à être incapable de vérifier la signature, voire à penser que cette dernière est incorrecte.

De même, les messages avec du formatage sophistiqué (gras, italique, gros texte, tableaux) sont difficilement compatibles avec les signatures.

Ayez donc conscience que ce genre d’erreur peut se produire, tout en restant méfiant vis à vis des messages dont vous n’avez pas pu vérifier la signature (surtout s’ils vous demandent de faire une action risquée comme un transfert d’argent).

Dans mon cas, je fais attention à envoyer du texte non formaté et ne pas inclure les messages précédents dans mes réponses pour ne pas créer ces problèmes mais tout le monde ne fait pas comme moi.

Instructions si vous utilisez Thunderbird

(Si vous n’utilisez pas Thunderbird, sautez cette section.)

• Commencez par installer GPG³. Pour Windows, c’est ici (la version la plus légère Gpg4win-Vanilla suffit) et pour Linux, vous n’avez probablement rien à faire car le logiciel a de grandes chances d’être déjà installé.
• Dans le menu de Thunderbird, cliquez sur Modules complémentaires (peut se cacher dans le menu Outils dans certaines versions de Thunderbird).

• Dans la barre de recherche tapez “enigmail” et installez le module correspondant.
• Redémarrez Thunderbird comme suggéré.
• Au redémarrage, l’assistant de configuration d’Enigmail se lance. Il vous demande de choisir entre trois modes de configuration (débutant, avancé, expert). Sélectionnez expert (ne vous inquiétez pas, je vous guide).
• Sur l’écran suivant, cliquez sur le bouton Gestion de clefs (vous pourrez ensuite fermer l’assistant de configuration en cliquant sur Terminer).
• Téléchargez ce fichier qui contient ma clé publique puis sélectionnez-le depuis la fenêtre “Gestion de clef Enigmail” qui s’est ouverte (menu Fichier/Importer des clefs depuis un fichier).
• Cherchez un vieux mail signé que je vous ai envoyé. Vous reconnaitrez facilement les mails signés : un bandeau “Enigmail” apparait en haut de ces derniers.

Si vous avez correctement effectué l’étape précédente, le bandeau devrait être bleu-vert et indiquer “Signature correcte de …” probablement précédé de “NON CERTIFIÉE”.

Je vous expliquerai ce que veut dire “NON CERTIFIÉE” un autre jour. L’important est que la signature soit correcte. Vous pouvez d’ailleurs la vérifier en un clin d’oeil car si elle n’était pas correcte, le bandeau serait rouge.

Vous n’aurez plus jamais besoin d’importer ma clé. En revanche, si un autre de vos contacts décide de chiffrer ses mails et vous envoie sa clef, vous pourrez l’importer très facilement en ouvrant à nouveau la fenêtre “Gestion de clefs Enigmail”. Vous pouvez accéder à cette fenêtre à tout moment en ouvrant le menu de Thunderbird (sous-menu Enigmail/Gestion de clefs).

Instructions si vous avez sauté les deux sections précédentes

Si vous n’utilisez ni Thunderbird, ni un webmail, vous avez deux solutions :

1. Débrouillez-vous.
2. Installez Thunderbird et recommencez.

Aller plus loin

Si vous avez lu ce post jusqu’au bout, vous êtes désormais capables de vérifier la signature des mails que je vous envoie. Vous pourrez aussi facilement vérifier la signature d’autres personnes (à supposer que ces personnes signent leurs mails) en leur demandant leur clé publique.

Si vous souhaitez à votre tour signer vos mails, dites-le moi et je serai ravi d’écrire une suite à ce billet pour vous expliquer comment procéder.

En coulisses

La signature d’un message ne vous garantit pas seulement l’origine du destinataire. C’est un cachet qui vous assure que le message que vous lisez n’a pas été modifié.

Pour garantir qu’un document n’a pas été modifié, on utilise des fonctions à sens unique qui sont des fonctions mathématiques compliquées associant à tout texte de départ une courte “empreinte” (quasiment) unique. Il est concrètement impossible de reconstruire un texte à partir de son empreinte, le calcul ne peut se faire que dans l’autre sens : c’est pour ça que ces fonctions sont “à sens unique”.

Ces fonctions sont bien utiles pour d’autres applications : par exemple établir une antériorité. Vous publiez uniquement l’empreinte d’un texte détaillant votre découverte. Le jour où vous avez besoin de prouver que vous aviez fait cette découverte à telle date, vous révélez le contenu du texte et tout le monde peut alors calculer à nouveau son empreinte et constater qu’il s’agit bien de la même. En revanche, si vous ne changez ne serait-ce qu’une virgule au texte de départ, l’empreinte n’aura plus aucun rapport.

Dans le cas qui nous intéresse en revanche, ça ne suffit pas. Comment transmettre l’empreinte du message de façon sûre et en garantir l’origine ?

La solution repose sur la cryptographie dite asymétrique : l’expéditeur/trice dispose de deux clés qui sont liées entre elles : l’une est dite privée et seul-e l’expéditeur/trice en dispose. L’autre est dite publique et est distribuée le plus largement possible.

La clé privée permet de traduire l’empreinte du message en signature (le texte incompréhensible que vous voyez en bas du message). Quant à la clé publique, elle permet de traduire la signature en empreinte. Vérifier une signature consiste alors à comparer l’empreinte du message (facilement calculable) avec le résultat obtenu en déchiffrant la signature. Les deux doivent se correspondre exactement pour que la signature soit vérifiée.

Pour en savoir plus : “Signature numérique” sur Wikipédia.

Diffuser l’information

Si comme moi, vous signiez déjà vos mails, il est probable que très peu de vos contacts vérifiaient vos signatures. Or, dans ce billet, j’ai cherché à montrer que vérifier les mails signés est très simple, suffisamment simple pour que tout le monde le fasse.

Le problème actuel c’est que les explications sur les techniques de signature et de chiffrement vont toujours beaucoup trop loin, ce qui démotive la plupart des gens. Les signatures perdent cependant tout leur intérêt si personne ne les vérifie. Faisons donc en sorte que tous nos contacts se mettent à vérifier nos signatures. Par ailleurs, certains pourraient finir par avoir envie de signer leurs mails à leur tour et nous répandrons ainsi cette pratique.

N’hésitez donc pas à adapter et reblogger ce billet (en particulier, en mettant un lien vers votre propre clé publique à la place de la mienne). Comme d’habitude, il est sous licence CC-BY et c’est aussi le cas des captures d’écran qui l’accompagnent.

Qu’est-ce qu’un isomorphisme ?

La (courte) page Wikipédia traitant du sujet nous rappelle la définition usuelle :

Un isomorphisme entre deux ensembles structurés est une application bijective qui préserve la structure et dont la réciproque préserve aussi la structure.

En pratique, cette notion nous était généralement présentée en cours de mathématiques sur des exemples. Un isomorphisme de groupe par exemple est un morphisme bijectif (où dans ce cas précis morphisme signifie une application envoyant l’élément neutre sur l’élément neutre et le “produit” de deux éléments sur le “produit” de leurs images).

La notion admet une définition générale grâce à la notion sous-jacente de structure mathématique, c’est-à-dire un ensemble muni d’un certain nombre de relations et d’axiomes décrivant les propriétés de ces relations (cette notion s’apparente à celle de théorie). On dispose alors d’une structure concrète (ou modèle) lorsque l’on connait l’ensemble sous-jacent, l’on est capable de définir les relations et de démontrer les axiomes.

On peut voir le rapport avec le besoin d’abstraction en programmation. La notion de signature en OCaml (ou d’interface en Java) correspond à celle de structure et son implémentation en termes de modules (respectivement en classes) correspond à la concrétisation.

À quoi sert ce genre d’abstraction ?

L’un de l’intérêt de l’abstraction est de simplifier et généraliser les raisonnements. On voit aussi qu’il peut exister plusieurs modèles pour une même structure. On pourra ainsi démontrer un théorème portant sur les groupes, en toute généralité, i.e. en ne se servant que des axiomes. Quel est alors l’intérêt de transférer des théorèmes d’une structure concrète à l’autre (ce qui est une technique différente) ?

Parfois, on peut préférer une structure concrète à une autre car ses propriétés spécifiques rendent les raisonnements plus faciles. Pour reprendre l’exemple des matrices, il est drôlement plus facile de faire un produit de matrices plutôt que de composer “à la main” les applications linéaires correspondant. Les démonstrations de certains théorèmes se font donc non pas sur la base des axiomes uniquement mais sur la base des connaissances supplémentaires dont on dispose.

Deux ensembles ayant la même structure ne sont pas nécessairement isomorphes. Il existe par exemple toutes sortes de groupes : certains finis, d’autres infinis ; pour certains l’opération commute (groupe Abéliens), pour d’autres non. Montrer alors un théorème pour un de ces ensembles ne permet pas nécessairement de le transférer à tous les autres. On pourra le faire si on peut identifier les deux structures à l’aide d’un isomorphisme.

Le (la) mathématicien-ne va donc s’employer à chercher un isomorphisme. Lorsqu’il (elle) l’a trouvé et l’a démontré, il (elle) prend alors un air solennel et déclare “nous pouvons identifier les deux structures donc les théorèmes que nous avions démontré pour l’une sont valables pour l’autre”.

Qu’est-ce que ça veut dire ?

C’est la justification de cette déclaration qui m’intéresse ici car mon but est de pouvoir la donner à un ordinateur. Les ordinateurs n’apprécient guère les déclarations solennelles.

Wikipédia ne m’aidera pas dans ma quête. En effet, voici ce qu’on y lit :

Savoir que deux objets sont isomorphes présente un grand intérêt car cela permet de transposer des résultats et propriétés démontrés de l'un à l'autre.

Selon certains points de vue, deux objets isomorphes peuvent être considérés comme identiques, ou du moins indiscernables. En effet, bien souvent, les propriétés intéressantes d'un objet seront partagées par tous les objets isomorphes de la catégorie. Ainsi on parle souvent d'unicité ou d'identité « à isomorphisme près ».

Ce dont j’ai besoin c’est d’une sorte de théorème méta-mathématique, autrement dit logique qui exprime cela. Je pense qu’une expression approximative en serait : Si une formule logique dont les atomes ne font intervenir que les éléments - de manière abstraite - et les relations de la structure est vraie alors elle est aussi vraie pour toute structure isomorphe.

Je ne vous fournirai pas de démonstration de ce théorème car je l’ai exprimé de manière intuitive. Mais je serais curieux d’en lire une formulation et une démonstration rigoureuse (il y a sûrement des gens qui l’ont faite). Dans la suite, je vous montrerai une démonstration d’un cas particulier.

Les questions subséquentes sont alors de s’interroger sur la minimalité des hypothèses de ce théorème. A-t-on vraiment besoin d’un isomorphisme ? A-t-on besoin de la notion de “structure” ?

Nous n’avons pas toujours besoin d’isomorphisme.

Prenons deux ensembles E (respectivement E’) munis d’une relation R (respectivement R’).

Soit F(E, R, x₁, …, x_n) une formule du premier ordre positive² dont les variables libres³ sont x₁, …, x_n ∈ E et les atomes sont de la forme R(y₁, …, y_k).

Supposons qu’on dispose d’une fonction f : E → E’

• surjective : ∀ y ∈ E’, ∃ x ∈ E, f(x) = y
• avec une propriété de transfert de R : ∀ x₁, …, x_k ∈ E, R(x₁, …, x_k) → R’(f(x₁), …, f(x_k))

Alors si F(E, R, x₁, …, x_n) est vraie, F(E’, R’, f(x₁), …, f(x_n)) aussi.

Le cas particulier où il n’y a pas de variable libre nous montre que tout théorème positif du premier ordre ne portant que sur R se transfère de E à E’.

Effectuons la démonstration par récurrence structurelle sur F :

Cas F = ∀ x ∈ E, F’(E, R, x₁, …, x_n, x)

Soit x ∈ E’, d’après la surjectivité de f, on peut trouver x’ ∈ E tel que x = f(x’). Alors on applique F à x’ pour obtenir F(E, R, x₁, …, x_n, x’).

Du coup, par hypothèse de récurrence, F(E’, R’, f(x₁), …, f(x_n), f(x’)) est vraie, i.e. F(E’, R’, f(x₁), …, f(x_n), x) est vraie.

Ainsi on conclut que ∀ x ∈ E’, F’(E’, R’, f(x₁), …, f(x_n), x).

Cas F = ∃ x ∈ E, F’(E, R, x₁, …, x_n, x)

Soit un témoin x rendant la formule F’(E, R, x₁, …, x_n, x) vraie. Alors par hypothèse de récurrence, F’(E, R, f(x₁), …, f(x_n), f(x)). D’où f(x) est un témoin rendant la formule ∃ x ∈ E’, F’(E’, R’, f(x₁), …, f(x_n), x) vraie.

Cas F = F’(E, R, x₁, …, x_n) ∨ F’‘(E, R, x₁, …, x_n)

L’une au moins de ces deux sous-formules F’ et F’’ est vraie. Supposons par exemple que ce soit F’. Alors par hypothèse de récurrence, F’(E’, R’, f(x₁), …, f(x_n)) est vraie ce qui suffit à conclure que F’(E’, R’, f(x₁), …, f(x_n)) ∨ F’‘(E’, R’, f(x₁), …, f(x_n)) est vraie aussi.

Le cas avec ∧ est similaire.

Cas de base F = R(y₁, …, y_k)

C’est là qu’on utilise la seconde propriété de f et c’est alors immédiat.

QED

On peut généraliser facilement à des formules comportant aussi des négations ¬ et des implications → à condition :

1. Qu’aucun quantificateur n’apparaisse sous ces deux connecteurs logiques ;
2. Qu’on renforçe un petit peu la seconde hypothèse sur f : ∀ x₁, …, x_k ∈ E, R(x₁, …, x_k) ↔ R’(f(x₁), …, f(x_k)).

Pour le voir il faudra renforcer l’hypothèse de récurrence sur toutes les sous-formules sans quantificateurs, dans l’esprit avec lequel on a renforcé l’hypothèse sur f.

En revanche, nous avons besoin d’un isomorphisme pour considérer les théorèmes quelconques du premier ordre mixant allègrement les quantificateurs et les négations.

Nous avons besoin d’un isomorphisme si nous rajoutons l’égalité

Plus précisément, dès lors que nous autorisons les formules atomiques à être des égalités x = y et pas seulement des relations R(y₁,…,y_k), alors on peut exprimer la taille de l’ensemble pour tout ensemble fini. Une bijection est alors nécessaire pour qu’une telle propriété se transmette (une surjection entre deux ensembles finis de même taille est une bijection).

Nous n’avons pas besoin des axiomes de la structure

Il est bien connu qu’un morphisme de monoïde transfère les propriétés de groupe et de groupe Abélien. La raison est la même que pour tous les autres théorèmes que nous pouvons vouloir transférer. Par conséquent, tous ces axiomes structurels sont superflus : si on peut transférer les relations, on peut transférer les axiomes.

Que se passe-t-il lorsque nous avons des éléments distingués et des opérations ?

Des opérations (i.e. des applications à plusieurs arguments, à valeurs de départ et d’arrivée dans la structure) peuvent être représentées par des relations bien particulières.

De même, des éléments distingués (comme l’élément neutre d’un groupe) peuvent n’être distingués que par une relation spéciale à un seul argument, toujours fausse, sauf pour l’élément concerné.

Cependant, il pourra être utile, en encodant cela, de traiter les opérations et les éléments distingués de manière spécifique, notamment pour des raisons d’efficacité et d’utilisabilité.

Conclusion

J’ai essayé de faire une présentation assez pédagogique, au moins pour le début. En revanche, elle est aussi assez naïve, comme je ne suis pas spécialiste du sujet, alors que les questions soulevées m’intéressent vraiment pour mon travail. Je serais donc ravi d’avoir des retours de mes amis mathématiciens ou catégoriciens (ce mot n’existe pas, j’en ai conscience).

Si vous voulez en savoir plus, lisez l’article que j’ai écrit sur le sujet depuis [en anglais].

Le sujet abordé par ce livre est très vaste mais s’il fallait le réduire à quelques mots-clés, je listerais, par ordre d’importance : science ouverte (open science), collaboration, Internet, partage des données (open data), accès libre aux résultats de la recherche (open access), science participative (citizen science), mise en réseau des connaissances (data web), extraction automatique de significations nouvelles (data mining). Je vais m’étendre sur certains points plus que d’autres en fonction de l’intérêt personnel que j’y attache.

Michael Nielsen est un physicien qui, impressionné par le succès du projet Polymath¹, a décidé de se consacrer à l’étude de cette révolution silencieuse qu’Internet a déclenchée et qui est en train de redéfinir la manière dont la connaissance scientifique est produite. Dans son livre, il présente un certain nombre d’exemples concrets de projets² ayant eu du succès (ou pas) et analyse les éléments indispensables au succès d’un projet collaboratif.

Cette révolution du partage scientifique est comparable à la précédente révolution du même type : l’invention des revues dans lesquelles tout-e scientifique se doit de publier les résultats de sa recherche. Cette première révolution, au XVIIème siècle, eut un effet radical sur la manière dont la recherche scientifique se pratiquait et influence plus encore la manière dont elle se pratique aujourd’hui. En effet, la conséquence positive de cette révolution est une première forme de collaboration, la création de nouvelles connaissances s’appuyant sur les connaissances précédemment acquises par d’autres scientifiques et le principe de citation permettant aux articles de se baser les uns sur les autres.

Les clés du succès d’un projet collaboratif

Le concept de micro-expertise

La connaissance scientifique est devenue si vaste qu’il est aujourd’hui impossible d’être un-e expert-e sur tout (alors que c’était quasiment possible à son époque pour un génie comme Léonard de Vinci). Même dans leur propre domaine, les plus grand-e-s expert-e-s de notre époque (que sont, par exemple, les médaillé-e-s Fields en mathématiques ou les champion-ne-s du monde d’échecs), ne peuvent pas avoir une connaissance totale.

Sans être aussi brillant, un autre individu peut avoir des connaissances spécifiques sur un point de détail, simplement parce qu’il y a déjà été confronté. Cette micro-expertise peut alors surpasser celle de tout autre personne.

Par conséquent, nous pouvons “augmenter notre intelligence collective” (je dirais plutôt tirer parti au mieux de notre intelligence collective) si un système est capable de connecter adéquatement un problème à la personne ayant la meilleure micro-expertise pour le résoudre.

Faire collaborer les bonnes personnes

De manière plus générale, des scientifiques peuvent être confrontés à des problèmes qui sortent carrément de leur domaine d’expertise (nouveaux concepts mathématiques pour résoudre un problème de physique par exemple). Internet a déjà rendu beaucoup plus facile la tâche de trouver la bonne personne (autrement que par simple chance) mais des outils nouveaux émergent qui rendent cette tâche encore plus aisée. L’auteur utilise le terme de designed serendipity pour désigner le fait que cette connexion nécessite de “forcer le hasard”.

L’émulation

L’intervention au moment adéquat de la personne adéquate permet à la communauté cherchant à résoudre un problème plus général (tel qu’une démonstration) de ne pas être bloquée. S’en suit, si le nombre de collaborateurs/trices dépasse une taille critique, une sorte de réaction en chaîne des idées. Une personne peut apporter régulièrement des idées qui font progresser la résolution alors que, toute seule, elle aurait passé la plupart de son temps à essayer de se débloquer de situations dont elle n’était pas spécialiste.

Les caractéristiques du logiciel libre : modularité, réusabilité, micro-contributions

Un modèle collaboratif ayant eu beaucoup de succès est celui des logiciels libres. Souvent les équipes développant de tels logiciels font un réel effort pour rendre le développement le plus modulaire possible. Afin que les différentes personnes y contribuant puissent travailler le plus indépendamment possible.

La réusabilité est une caractéristique que partagent le logiciel libre et la recherche scientifique. En effet, de la même manière qu’il est beaucoup plus facile de créer un logiciel en utilisant des bibliothèques codées par d’autres, le principe des citations dans les articles scientifiques permet de construire de nouvelles connaissances en s’appuyant sur les résultats des autres. La preuve d’un théorème peut ainsi faire appel à plusieurs autres théorèmes sans pour autant devoir réexpliquer la preuve à condition qu’elle soit disponible quelque part.

Enfin, l’auteur observe que la plupart des contributions à des logiciels libres sont seulement d’une ou quelques lignes. Un projet collaboratif aura probablement d’autant plus de succès qu’il permet ce genre de micro-contributions.

La question de la modularité et des micro-contributions sont des éléments possibles pour réduire les “barrières à l’entrée” d’un projet collaboratif. De telles barrières sont un obstacle significatif à la réussite d’un projet massivement collaboratif car il est peu probable que tou-te-s les contributeurs/trices arrivent au même moment et suivent le projet avec le même degré d’attention. C’est une des raisons pour lesquelles le succès de Polymath a été limité à quelques dizaines de personnes et certainement pas quelques milliers.

Permettre les discussions et créer un esprit de communauté

La plupart des projets ayant eu du succès possédaient des espaces permettant la discussion et le débat mais aussi de forger un esprit d’appartenance à une communauté. Parfois de tels espaces créent une différence significative. Par exemple, si la communauté vote sur chaque décision comme c’était le cas lors du match d’échecs Kasparov vs the World, le fait d’avoir un espace de débats préalables permet d’orienter les votes vers de meilleures décisions. Et sur Wikipédia, l’existence de pages de discussion et de communauté fidélise les contributeurs et permet de résoudre les problèmes que l’outil du wiki lui-même ne suffit pas à combler.

Focaliser l’attention

Lorsqu’un projet enregistre un grand nombre de contributions, il devient impossible pour une personne seule de les suivre et les analyser dans leur ensemble. Différents mécanismes peuvent être mis en place de manière à focaliser l’attention.

Une première catégorie de mécanismes permet de mesurer la qualité de chaque contribution de sorte à concentrer l’attention générale sur les meilleures idées, celles qui permettront d’avancer plus vite et plus loin. La solution la plus simple dans cette catégorie consiste à attribuer un score à chaque solution (comme dans le concours organisé par MathWorks). Cependant, cette solution est loin d’être systématiquement praticable car il n’est pas toujours faisable d’évaluer automatiquement la qualité d’une idée ou solution.

L’auteur généralise l’idée du score au concept de shared praxis. D’une certaine manière, l’existence d’un score fournit un langage commun (rudimentaire) à tou-te-s les contributeurs/trices. Ce langage commun peut être en revanche plus compliqué, comme dans le cas du jargon scientifique. Dans les deux cas, la possession d’un tel langage se révèle importante pour la communication effective au sein de la communauté donc pour l’évaluation des idées émises par d’autres. En d’autres termes, “avoir une idée” est alors l’étape délicate tandis que “comprendre qu’une idée est bonne” est aisé. L’absence d’un tel moyen de partager effectivement ses idées rend au contraire les projets collaboratifs plus difficiles : c’est une problématique importante dans le domaine littéraire en particulier³ et dans le domaine de la création artistique en général, mais aussi en politique et dans tout domaine où il est compliqué d’obtenir un consensus d’un grand nombre de gens.

Une seconde catégorie de mécanismes permet de focaliser l’attention de chaque personne sur les problèmes les plus proches de son domaine d’expertise. Une telle catégorie d’outil est plus intéressante car elle permet une division de l’attention (donc la communauté dans son ensemble est attentive plus largement), tout en permettant le succès du concept de designed serendipity. Le monde du logiciel libre nous fournit un exemple basique de tel outil. Un issue tracer regroupe les bugs rapportés en un même endroit ; un système de tags permet de savoir si un bug vient d’être rapporté ou s’il a déjà été confirmé, si le type de problème qu’il soulève a déjà été identifié, et enfin si une personne spécialiste a été chargée de sa résolution.

L’extension des communs

La deuxième partie du livre (chapitre 6 et suivants) ne traite plus de projets collaboratifs en particulier mais plus généralement de la révolution du partage scientifique en cours. Par rapport à la première révolution suite à laquelle le partage scientifique se faisait uniquement par le biais de publications dans des revues, deux nouveautés essentielles sont l’open access et l’open data.

Les nouvelles formes de partage

L’open access est le fait de rendre librement (et gratuitement donc) accessibles les résultats de la recherche. De manière plus concrète, les articles scientifiques sont alors rendus publics sur des sites web dont l’accès n’est pas limité. Il prend deux formes : la mise à disposition par les chercheurs/euses eux/elles-mêmes de documents de travail et de preprints (version de l’article avant le travail d’édition effectué par la revue) sur des portails ouverts ; l’apparition de revues ouvertes qui ne se financent pas en vendant des abonnements et en restreignant l’accès mais par d’autres moyens (par exemple en facturant l’acte de publication directement aux auteur-e-s).

Dans le premier cas, les articles partagés n’ont pas nécessairement été relus et contrôlés par des comités de lecture, donc leur fiabilité est moindre. En revanche, la plupart des revues opérant encore de manière fermée, c’est bien par le partage de preprints qu’il y a le plus d’espoir aujourd’hui d’accéder aux derniers travaux de nombreux scientifiques.

Les scientifiques eux/elles-mêmes peuvent avoir intérêt à faire cette démarche de mettre en ligne leurs articles dans une version non-finale pour plusieurs raisons : atteindre un public plus large, obtenir des citations supplémentaires et s’assurer d’être les premiers/ères à publier un résultat inédit.

Des tentatives d’y adjoindre des sortes de relectures ont eu lieu. Une idée persistante est notamment d’en finir avec la relecture anonyme et d’encourager les chercheurs/euses à écrire et signer des commentaires des preprints mis en ligne par leurs collègues. Cette idée n’a cependant pas abouti pour l’instant. Deux explications possibles sont d’une part le manque de temps et d’incitations, d’autre part la crainte de payer le prix de critiques si les collègues critiqué-e-s se retrouvent ensuite à devoir évaluer l’article ou la demande de financement du/de la chercheur/euse auteur-e des critiques.

Pour en savoir plus sur l’open access, je recommande la lecture de ce dossier par Pablo Rauzy.

Le principe de l’open data est de rendre librement accessible les données récoltées pour une étude scientifique, soit immédiatement, soit au moment de la publication. Ces données peuvent alors servir à d’autres chercheurs/euses dans de nouvelles analyses.

Enfin, certain-e-s chercheurs/euses vont plus loin en partageant l’état de leur recherche, quasiment en direct, sur leur blog (ce qu’on peut qualifier de recherche ouverte ou recherche en public). Certains blogs de chercheurs/euses connu-e-s reçoivent alors des milliers de visiteurs/euses, y compris des gens en dehors du milieu scientifique et qui s’intéressent aux dernières avancées ou à la vision du monde qui est présentée dans ces espaces.

La combinaison de ces nouvelles formes de partage laisse entrevoir l’apparition d’un internet des données. L’objectif serait alors que l’immense majorité de la connaissance scientifique soit facilement accessible de sorte qu’il serait possible d’en tirer de nouvelles significations de manière automatique ou semi-automatique (à l’aide de requêtes potentiellement complexes). Outre la généralisation du partage des connaissances, une telle application nécessite l’utilisation de formats de données standardisés, aidant alors l’ordinateur à parcourir automatiquement la gigantesque base de données mondiale.

L’implication des citoyen-ne-s rendue possible

Les sciences citoyennes ne sont pas un phénomène nouveau (par exemple, ce sont souvent des amateurs/trices qui découvraient de nouvelles comètes) mais Internet rend l’implication des citoyen-ne-s beaucoup plus facile. Les amateurs/trices peuvent intervenir de plusieurs façons : en collectant et traitant de grands volumes d’information, mieux que les ordinateurs (Galaxy Zoo) et parfois mieux que les expert-e-s du domaine eux/elles-mêmes (FoldIt) ; en repérant les anomalies et ce qui est digne d’attention et en faisant parfois eux/elles-mêmes un véritable travail de recherche⁴ ; en compilant la littérature (Open Dinosaure Project). Enfin, lorsque même les amateurs/trices ne sont plus assez nombreux/euses pour traiter l’énorme volume de données disponibles, on peut se servir de leur travail pour entraîner des ordinateurs à reproduire leur “expertise”.

Un projet tel que Galaxy Zoo n’aurait pas été possible sans open data. Un projet comme Open Dinosaure n’aurait pas été possible sans open access. Autant l’un que l’autre sont indispensables lorsque des personnes hors du milieu académique décident de s’attaquer à un problème scientifique. Outre l’histoire des “green peas”, d’autres découvertes importantes ont récemment été le fait d’amateurs/trices. L’auteur cite le cas d’un informaticien à la retraite ayant découvert un lien entre la migraine et le manque de magnésium uniquement en sondant des bases d’articles en libre accès et donc en tirant de nouvelles conclusions d’études déjà réalisées.

Les sciences citoyennes (ou participatives) sont attrayantes car elles sont un moyen efficace d’utiliser le “surplus de temps disponible” de notre société, c’est-à-dire le temps que les individus n’ont pas besoin de passer à travailler, couramment associé aux loisirs. Pour autant, il est très dur de savoir à quel point les sciences participatives vont impacter la manière dont la recherche scientifique est conduite. Il se pourrait en effet qu’elles restent un phénomène marginal tant chaque nouveau projet demande de l’ingéniosité, notamment lorsqu’il s’agit de rendre ludique la résolution de problèmes scientifiques. Lorsque les citoyen-ne-s deviennent de véritables scientifiques et font de la vraie recherche (par opposition à seulement y contribuer sur des tâches spécifiques et répétitives), ils/elles ont besoin de systèmes d’auto-formation, de communautés et de mentors pour coopérer et progresser.

Le partage libre des connaissances scientifiques pourrait avoir un autre avantage, à savoir instaurer une communication plus directe entre science et décision politique. Le risque d’une surinterprétation ou d’une mauvaise interprétation des publications scientifiques par les médias grand public existe cependant. L’auteur n’est pas pour autant inquiet car, d’après lui, les médias mettent en danger leur réputation à chaque fois qu’ils publient une information qu’ils doivent démentir par la suite et vont donc rapidement acquérir des pratiques visant à éviter que ce genre de situation ne se produise trop souvent.

Les freins au partage

Une des thèses importantes de ce livre est que le partage est globalement une bonne chance pour la science et que celui-ci doit être encouragé. Cependant, alors que chaque scientifique a intérêt à ce que la communauté partage plus, il n’est pas dans son intérêt personnel d’agir individuellement dans ce sens.

Les scientifiques ne sont actuellement valorisé-e-s que lorsqu’ils/elles écrivent des articles scientifiques. Ils/Elles passent aussi une grosse partie de leur temps à chercher des financements (principalement en rédigeant des candidatures pour des allocations ou grants). Par manque de temps et de valorisation, rares sont ceux/celles qui contribuent à Wikipédia, documentent des programmes qu’ils/elles auraient programmés en vue de les partager, ou maintiennent des blogs actifs.

Le second frein résulte de la crainte que le partage ne profite qu’aux autres et soit même contre-productifs pour les chercheurs/euses, par exemple si leurs concurrent-e-s tirent avant eux/elles des analyses des données qu’ils/elles ont rendues publiques.

Enfin, un dernier frein est dû à la volonté de commercialiser les résultats scientifiques, essentiellement sous la forme des brevets. Dans les domaines où des possibilités de brevets existent, la recherche ne peut nécessairement avoir lieu qu’en secret (un esprit radicalement contradictoire par rapport à celui de la recherche ouverte). L’auteur pense néanmoins que ce problème a un impact mineur en comparaison avec les deux premiers.

Dans l’état actuel des choses, beaucoup de scientifiques hésitent voire refusent complètement de changer de pratiques vers plus d’ouverture. Pour combler ce différentiel entre intérêt collectif et intérêt personnel, des incitations ou des règles doivent être mises en place de manière institutionnelle.

Puisque les scientifiques sont essentiellement récompensé-e-s par leur réputation (qui leur servira ensuite à décrocher de meilleurs postes et d’autres avantages), il faut tout d’abord changer de mesure de réputation. Aujourd’hui le travail de création d’un outil collaboratif ou de partage de données est trop souvent dénigré. En s’assurant que citer les auteurs des données ou des outils utilisés pour une étude devienne aussi systématique que de citer les articles sur lesquels le travail se base, et en mesurant le nombre de citations recueillies par un-e auteur-e pour tous ses travaux, et pas seulement pour ses articles publiés dans des revues, l’incitation à faire de la science ouverte sera alors évidente. D’ores et déjà, des outils permettent de mesurer le nombre de citations d’un article (y compris d’un preprint et en comptant les citations par des preprints).

D’autre part, les scientifiques peuvent mettre en place de nouvelles règles que les agences de financement de la recherche peuvent alors faire appliquer. Un exemple est celui de l’accord des Bermudes en 1996 qui a édicté que toute donnée récoltée sur le génome humain doit être immédiatement rendue publique.

The idea of getting amateurs involved in science seems quite convincing. This really looks like a trending research topic today (see all the fuss about citizen science) and I think this is fantastic. Although, when it comes to mathematics, there don’t seem to be so many projects whose goal is to build tools for collaboration¹, I am nevertheless not the only one thinking that a lot of amateur mathematicians (students, engineers, self-trained hobbyists…) would be happy to join a global effort to help research progress.

Many had their doubts, however, on the technique I proposed in this aim. It essentially looks too simple, too optimistic and not enough thought-through. And also, since this is really hard to do formal proofs, it must be even harder making it feasible for large crowds without a specialized knowledge.

A priori, my proposed system is supposed to distribute all the intermediate goals to users. This was a concern for many as most of these intermediate goals probably aren’t particularly meaningful. And even a good mathematician might not be able to judge if a lemma is correct or not if the so-called lemma has no apparent meaning.

This might be a very important point to which I have no definite answer for now. However I imagine a system where the importance of each goal or sub-goal would be evaluated. We could have, for instance, a system of bounties² to give importance to an initial goal. As for the intermediate goals, those that would occur most frequently in the sketch proofs of the users and remain unsolved could be considered as more important (algorithm needed). The most important sub-goals would be more likely to be meaningful or at least worth giving meaning to. The system would then distribute only the most important goals and sub-goals to the user community.

But also, let’s see how it goes on examples! I should (I am going to) start working on some actual mathematical proofs and see to what extent these intermediate results are hard to grasp if they are presented out of context.

The second problem, according to the commenters, is that there are, on the one hand, hard theorems which require original ideas and, on the other hand, uninteresting intermediate goals which can be proved in a matter of minutes by a trained mathematician. So why would mathematicians risk losing the credit for a proof which they could have done alone? And why would mathematicians waste their time describing the goals formally in an online tool? Let me try to answer these two questions.

The way the scientific community attributes credit for a proof can evolve. It seems logical that peers will give more credit to the authors of the most difficult steps, even if many other contributors are involved at the edges. If this is necessary, we can even imagine a system to measure the relative contribution of each author to a proof (and how difficult were the problems they solved - again algorithm needed). But even without that, it should be already enough to make the entire proof history public. As explained by Tim Gowers when he presented Polymath for the first time, people can go and see by themselves who contributed to what in the proof. Contributors can gain reputation among their peers. And they can write cover letters for one another if that helps. This won’t necessarily be enough at first for people to agree to share their ideas on those conjectures that are the biggest challenges of one field (and thus could result in the most rewarding papers). But it might be just enough for side results, that nobody really has time to tackle by themselves but which raise enough interest from a significant number of mathematicians (and which can, like in the case of the Polymath project, result in a collective paper³).

We need to make sure that there is no waste of time in describing formally the goals in the online tool. Working directly on a proof online should be as simple as sketching a proof on draft paper, but with several advantages that come along for free. Word processors have been designed so well that most of the writers have stopped drafting on paper and have been working instead exclusively on their computers for some time already. Can we achieve the same for math? Yes, probably. Of course, the fact that current keyboards do not carry many keys for mathematical symbols does not help. But with a fantastic user interface, we should be able to compensate for that.

And what would be these free bonuses that come along? Well, there is the big bonus that proofs are automatically checked. There is the obvious advantage of generating a paper quickly from the draft. And lastly, mathematicians often use specific strategies (which are often specific to a particular domain): applying these strategies by a simple click on a button can possibly speed up the writing a little (a lot?).

So suppose that the interface of this system is so simple and so awesome that some mathematicians use it everyday to build up their proofs. Then, they would get an additional bonus which is: while they were working on a tedious but necessary sub-goal, maybe all the other tedious but necessary sub-goals will have been solved by various contributors around the world.

It has been good having all that feedback. I have started to realize that my project is fundamentally useless without a perfect interface. It cannot succeed without that! There is no point willing to work specifically on the “collaborative aspect”. All massively collaborative projects need great user interface (because massive implies lots of motivated users but bad interface implies unhappy users which in turn implies demotivated users). And thus, it is most likely that, by willing to make massive collaboration tools my subject, I am going to spend a lot of time working on user interfaces⁴. I should as well get used to the idea. In the case of the collaborative proofs project, this means I should work with people who have built good web interfaces for interactive theorem provers (if I can find them). I should join forces with them while postponing my collaborative ideas a little. I should dive into user interface so that I know I have a good one when I finally get to make the collaboration happen.

User interface in the case of an interactive theorem prover is much more than what the final user will see. It is also an interface in the sense that it links two worlds: indeed, the formal proofs a computer can understand are very different from what a mathematician is used to.

And quite frankly, for now, I don’t have a clear vision of what the perfect interface will be. The reason why is that I’m quite fresh in the proof assistant world. Thus, I need to practice and I need to know the domain better. This is also something that will probably be true of any collaborative project. Not suprisingly at all, a lot of successful projects (like Polymath or FoldIt) have been launched by people in the field (mathematicians, biologists…). I like to think that I, as a computer scientist, can be helpful. But for that, I need to know a little bit more about the domain I’m trying to help.

Even if it’s still blurry, I think a good interface for writing mathematical proofs on a computer will give an important place to the so-called tactics or strategies⁵. Thus, I need to work in a framework which has those (like Coq). Since tactics are so important, any mathematician should also be able to add one easily. But I haven’t even written a single Coq tactic myself! Let’s try to do that before imagining what good interface mathematicians will use to add their owns.

As a conclusion, there is a lot to do to make this project happen! The idea of doing collaborative proofs emerged because I saw it as a first step to do collaborative science. But clearly, this is not the easiest step. What I’m doing with this blog and what others are doing is open science and open research. This, more than anything, is the first and easiest step toward collaborative science.

As a opening, here’s a great talk about open science that I really encourage anyone to watch:

La licence GPL a été inventée par des gens et pour des gens qui pensent que tous les logiciels devraient être des logiciels libres³. Ne l’utilisez pas si vous n’êtes pas d’accord avec cette philosophie !

Si vous êtes d’accord avec cette philosophie, ayez conscience que l’usage de cette licence rend très compliquée l’utilisation de bibliothèques propriétaires (ou incompatibles avec la GPL) dans les programmes que vous développez⁴.

Maintenir deux versions d’un logiciel

Ce que je trouve stupide par dessus tout, ce sont les entreprises qui créent deux versions d’un logiciel : une version de base libre et gratuite sous licence GPL et une version améliorée, payante et non-libre (propriétaire). Pour pouvoir vendre ensuite la version fermée de leur programme et ne pas en dévoiler le code, elles ont besoin de posséder le copyright de l’ensemble. En particulier, l’intégralité du code sous GPL doit leur appartenir, de sorte que la GPL ne s’applique pas à elles-mêmes.

Ces entreprises font donc signer des contrats (dits contributor license agreement) à tou-te-s les contributeurs/trices dont elles intègrent les modifications. Il faut avoir conscience, lorsque vous contribuez à un logiciel sous GPL, géré par une entreprise qui exige que vous lui cédiez vos droits que vous êtes en train de briser vous aussi la philosophie selon laquelle tout logiciel devrait être libre⁵.

Ce ne sera pas le cas par contre si vous cédez vos droits à une organisation en laquelle vous avez confiance, telle que la Free Software Foundation. Les associations qui choisissent de centraliser le copyright le font souvent afin de simplifier la gestion des procès⁶.

Notez de plus que renoncer à ses droits d’auteur n’est pas une chose anodine. Selon le type de contrat que vous signez avec l’organisation gestionnaire du logiciel auquel vous contribuez, soit vous accordez à cette dernière une licence définitive, gratuite et non-exclusive d’utilisation et d’exploitation de votre code (pour qu’elle puisse le revendre au sein d’un logiciel fermé), soit vous lui cédez votre copyright. Dans ce second cas, vous n’êtes plus propriétaire de votre code et c’est uniquement parce que l’entreprise qui en est désormais propriétaire l’a publié sous GPL que vous continuez à pouvoir l’utiliser. Si dans le futur, vous choisissez de réutiliser votre code dans un logiciel fermé ou sous une licence différente, vous enfreindrez les termes de la GPL et vous serez dans l’illégalité. C’est pourquoi je vous encourage à ne jamais accepter de céder purement et simplement votre copyright à moins que vous soyez certain que tous les logiciels que vous produirez dans le futur seront aussi sous la même licence. Méfiez-vous, à ce propos, des incompatibilités entre les versions des GPL⁷.

Heureusement, il semblerait que l’accord que demande la FSF à ses contributeurs/trices inclue une clause stipulant que ceux-ci peuvent continuer à utiliser leur travail comme bon leur semble⁸. Un autre exemple est celui de Canonical, l’entreprise qui édite Ubuntu, un système d’exploitation basé sur Linux. Elle demandait par le passé que les contributeurs/trices lui cèdent leur copyright mais l’accord qu’elle leur demande désormais est beaucoup plus respectueux de leurs droits et garantit que leur code ne sera pas utilisé dans des programmes fermés⁹.

Les alternatives à la licence GPL

Moralement, les entreprises qui veulent développer deux versions (une libre, une fermée) de leur logiciel ne devraient pas utiliser la GPL.

Juridiquement, aussi, elles feraient mieux de ne pas l’utiliser. Si elles choisissent cette licence, c’est qu’elles se disent que cela va les protéger des concurrents qui produiraient un logiciel fermé en partie basé sur leur code source. C’est une crainte que n’ont que les petites entreprises (les plus grosses entreprises - Adobe, Apache, Apple, Google, Mozilla, Sun

• utilisent souvent des licences plus permissives telles que la licence Apache ou la MPL 2.0 ; ou alors, comme RedHat ou Canonical, ne produisent que des logiciels libres¹⁰). Cependant, il faudrait que ces petites entreprises craintives réalisent les difficultés qu’elles se créent en s’engageant dans cette voie !

D’abord le contrat qu’elles font signer à leurs contributeurs/trices ne sera certainement pas aussi peaufiné que les licences libres les plus courantes (et pourrait s’avérer caduque lors d’un procès).

Deuxièmement, en utilisant la GPL, ces entreprises se compliquent la vie si elles souhaitent utiliser des bibliothèques propriétaires, pour des raisons philosophiques qui leur échappent.

Troisièmement, ces entreprises ne peuvent pas du tout utiliser des bibliothèques libres sous GPL car celles-ci seraient incompatibles avec la version fermée de leur programme.

Enfin mais surtout, ces entreprises doivent contrôler que les contributions extérieures sont effectivement complètement nouvelles et qu’elles n’embarquent pas du code sous licence libre GPL d’une autre source. En effet, dans ce cas-là, le/la contributeur/trice ne possède pas le copyright sur ces lignes de code de source extérieure. Par conséquent, même en signant un accord quelconque, il/elle ne peut pas légalement céder les droits dessus. Je suis sûr que la plupart des entreprises qui fonctionnent sur ce modèle n’effectuent jamais ces vérifications car elles n’en ont pas les moyens.

En pratique, la conséquence c’est que beaucoup de logiciels libres ou non libres enfreignent la loi de manière notable ou anecdotique¹¹. Il ne faut pas encourager cela car cela met en danger le monde du logiciel libre dans son ensemble.

Note : dans le cas d’un logiciel destiné à tourner sur des serveurs distants et être utilisé via un navigateur plutôt que d’être installé sur des machines individuelles¹², la GPL n’a que peu d’intérêt. Tout ce que j’ai dit s’applique également à la licence AGPL¹³, plus adaptée à ce type d’usage.

Je trouve formidable que des entreprises souhaitent contribuer au libre tout en faisant des profits. Je comprends que pour certaines, cela implique de ne partager qu’une partie de leur code seulement (ou alors qu’elles veulent se garder des portes ouvertes si demain elles décidaient de repasser à un modèle fermé). Mais je leur déconseille avec force d’utiliser alors le système répandu GPL + accord avec les contributeurs.

Je leur conseille plutôt d’utiliser des licences qui ont été pensées, notamment, pour elles. Pour faire simple, le choix se résume à une alternative entre la licence Apache et la licence MPL 2.0.

La licence Apache est utilisée massivement par Google¹⁴ pour tous ses projets libres (tels qu’Android, Chromium et Chromium OS). Elle permet d’intégrer ces projets avec des extensions propriétaires, ce qui donne les nombreuses versions “fabricant” d’Android, ainsi que Chrome et Chrome OS. Cette licence n’exige pas que les modifications du programme soient partagées mais une entreprise comme Google n’a rien à craindre car elle sait qu’elle disposera toujours de la meilleure version même si des “passagers clandestins” refusent de participer à l’effort collectif.

Pour les plus petites entreprises, je recommande plutôt la licence MPL 2.0¹⁵, celle du navigateur Firefox. En effet, c’est une licence dite weak copyleft. Elle permet l’intégration dans des logiciels propriétaires, mais toutes les modifications apportées aux fichiers d’origine doivent être partagées. Cela permet de se protéger contre les profiteurs les plus immoraux tout en laissant la place pour des extensions payantes. Bien entendu, il ne s’agit pas de nier que des concurrents aussi pourront proposer des extensions payantes.

Deux licences que je n’ai pas citées et qui sont proches de la licence Apache et de la MPL 2.0 sont la licence MIT et la licence LGPL. Celles-ci sont aussi très intéressantes pour certains projets mais probablement moins adaptées à des entreprises.

La licence MIT est similaire à la licence Apache mais cette dernière intègre en plus des mesures de protection contre les brevets logiciels (problème qui ne nous touche pas encore en Europe mais ça pourrait arriver bientôt

• l’Office Européen des Brevets a commencé à enregistrer des brevets logiciels - et si vous avez des ambitions, vous ne souhaitez probablement pas vous limiter à l’Europe pour toujours
• aux États-Unis et dans la majorité du reste du monde le problème des brevets est réel). De telles mesures sont présentes dans toutes les grandes licences modernes (licence Apache, MPL 2.0, LGPL v3, GPL v3, AGPL v3).

La licence LGPL est proche de la MPL 2.0 sur le plan pratique (quoiqu’un peu plus tordue¹⁶), mais très différente au point de vue philosophique. La licence LGPL a été conçue par et pour des gens qui pensent que tout logiciel devrait être libre mais qui avaient conscience que, pour gagner le combat, il serait préalablement intéressant de créer des bibliothèques que tout le monde utilise y compris les logiciels fermés¹⁷. Ce pari est réussi car un grand nombre de bibliothèques standard sont aujourd’hui des bibliothèques libres si bien qu’on peut affirmer sans crainte de se tromper que le logiciel libre est partout¹⁸.

Vous devriez aussi savoir que les conditions d’utilisation de l’Apple Store contredisent les principes essentiels des licences libres GPL et LGPL¹⁹. Bien entendu cela devrait être une raison suffisante pour boycotter Apple. Cependant, si votre activité économique implique de distribuer des applications mobiles, vous aurez du mal à convaincre tous vos utilisateurs d’abandonner leur iPhone. Vous feriez donc bien d’envisager (tant qu’Apple maintient sa politique liberticide) d’utiliser des licences plus laxistes (pour une fois je trouve ce terme justifié) pour tous vos programmes pouvant être intégrés à des applications mobiles.

Remarque finale : Il n’est pas du tout absurde pour une entreprise d’avoir un business model basé sur la GPL. Si vous souhaitez suivre cette voie, plutôt que de maintenir deux versions de votre logiciel, vous devriez tout publier sous GPL et suivre l’exemple de RedHat pour faire des profits. À savoir, faire payer à vos clients non pas le logiciel lui-même mais la garantie et l’assistance.

Une autre manière de faire du business avec la GPL est celle qui consiste à vendre des exceptions²⁰. Cette méthode consiste à maintenir une unique version du logiciel et à la distribuer à la fois sous licence GPL et sous licence propriétaire (pour des clients souhaitant éviter les contraintes de la GPL). En revanche, elle n’est pas idéale en ce qu’elle souffre de la plupart des problèmes que j’ai décrits dans cet article.

The main idea of that kind of tool is crowd sourcing: making big things happen from many small contributions. A proof can possibly be a perfect application of this principle because it is local by nature (even if a global view is often a good thing). Also, people from different background can bring their own expertise and view a problem differently, possibly unlocking a proof someone else had started. The first challenge is to automatically split a proof in steps and distributing them to the contributors.

If we want an online tool that any mathematician will use without difficulty, it must be designed for them, which means as close as possible to the way they are used to doing math on paper. However, to guarantee that submitted proofs are correct, it must rely on an underlying formal proof checking tool (remark: another option would be a peer review mechanism but it does not give guarantees as good). A lot of formal proof systems already exist but most of the time they were not really thought for use by mathematicians and require an extensive learning phase. So providing a simplified access to one of these is another challenge.

To attract this population of amateur mathematicians, I believe the best time is during their studies. Indeed, while studying, they would learn to use the system (which would be really easy to use for any mathematician anyway) and this would help them make sure they have well understood the content of the course and the proofs they have seen in class. The website could have a special mode for learning. Then, thanks to some incitement and reward mechanism, the users would continue using the site. And by practicing their skills on a regular basis, they would not lose them.

Provided such a tool to help amateur mathematicians collaborate, will it really serve science? I cannot bring a firm answer here, although the best way to know is trying. But a glorious project has already led the way: Polymath¹ is a very successful collaborative math project launched by Fields medalist Tim Gowers. Without any specific tool, dozens of mathematicians have been able to collaborate and publish several novel proofs already. But it is highly unlikely that their method will scale to thousands of contributors if they continue using blog comments or wikis to collaborate.

Another goal is to allow big theorems to be formally checked quicker. Although it may seem less interesting, there is a growing interest in formalizing proofs of important theorem and people have spent decades doing so (by themselves or in small teams).

Before explaining my ideas further, I would like to remark that I was not the first one to have such an idea for increasing the speed of proof formalization (although my goal is larger). ProofPeer² is a very promising research project by a team in Edinburgh. It was fun to discover than one of their inspiration was Crowd Sourced Formal Verification³ which was also an inspiration to me (after I attended a seminar by Prof. Mike Ernst as I relate in a previous post.

However, I was surprised to read that they are going to rebuild a proof checker from scratch, although there are some really good such tools out there already. My viewpoint is to try to adapt an existing interactive theorem prover first (like Coq). Only if this happens to be infeasible, would I consider rebuilding everything (and even then, I would probably re-use some existing code).

One of the reason why they are reinventing the wheel is because they also want a specific proof script language. They want this language to have constructs to allow collaboration (holes in proofs). This is where I start viewing things really differently.

What I propose is a fully interactive tool. As with most theorem provers in interactive mode, you can first state a theorem that you would like to prove. Proving it will require successive applications of tactics which will break the initial goal in several sub-goals. A classical theorem prover would present to you these sub-goals one by one. A collaborative theorem prover would take each of these sub-goals and present them to different (possibly random) people, in parallel. The initial user would be one of them. Maybe she would be given the privilege to choose what sub-goal she wants to prove first. Each user would then try to prove their assigned sub-goal by applying a tactic and generating new sub-goals to be distributed to collaborators once more.

It is likely that, when reading the last paragraph, you thought: well, this looks really close to an exhaustive search for a proof, this will never work! And I agree fully with you if we stop here. But what I propose is a little less dumb.

First of, a user is never forced to prove an assigned sub-goal. If she does not think the result is true or if she has no idea on how to prove it, she should not try randomly any tactic that fits. Second, we would in fact present each sub-goal (as well as the initial goal) to several users, so that several strategies can be tested. Third, and most importantly, our tool would also evaluate, for each sub-goal as well as for the initial goal, the likelihood of it being true. The idea behind is just not spending too much time trying to prove false results. Of course the computer cannot evaluate the likelihood. But a (trained) human mind can.

In addition to being presented sub-goals to prove, users would also be asked to say if they think some conjectures are likely to be true: let’s say they would have a 5 ladder scale (certainly true, probably true, I don’t know, probably false, certainly false). Based on previous users predictions and achievements, the tool would have a varying confidence in each user. Then a pondered mean would be computed and the system would use the “evaluated likelihood” for presenting sub-goals to users that are very likely to be true way more often than sub-goals that are probably false.

There are many more questions that remain. Many I have think of, many I have not. I did not explain how to make it easy for any mathematician to use the tool. Although I have ideas about that too, I am far from having a clear view of what the final system will look like.

This post has a sequel: A key to massively collaborative math is a good interface for writing proofs.

Let’s rephrase our problem. Many people can write. Suppose we found a way to encourage them to do so and to post their work. Now, we’ve got tons of small pieces, each one of them may be interesting or not. How do we give every piece of writing an equal access to readers?

A statistical testing approach

The concept I’m about to describe is not new. Yet, I believe it could be used more often and I’m definitely interested in applying it in many of my future projects.

There is absolutely no way (so far, I think) to automatically analyze the content quality and relevance of a text. On the contrary, anyone is able to judge a text he/she reads (subjectively, of course). So why bother with complicated algorithms or full-time paid staff for picking articles when you could simply ask people what they think?

More precisely, the algorithm works that way:

You have a set of pieces as input.

You have readers to which you present a front page with a list of articles, the kind of front page any online newspapers, blogs or RSS readers would have.

Now, here’s the trick: you don’t need to present the same front page to every reader (and here I’m not talking of personalizing the front page with respect to the reader interests because we’ll suppose that you are not tracking the users of your web service, thus you know nothing about them).

Your front page will present each new piece to a statistically relevant number of random readers.

These new pieces will not be singled out from the popular pieces. So each reader will see a front page with a list of articles. Among them most will be already popular and some will be new. Then, when a reader decides to read an article (any article), once he/she reaches the end of it, your system will strongly encourage him/her to give an appreciation (the way in which this would be done can be discussed).

So you will have feedback. Based on that feedback, the algorithm simply gives a popularity score to the piece. The more popular, the more often it would reach the front page. At some point, the most popular pieces of work will have gone viral and will display on everyone’s front page.

Of course, many questions remain. What kind of feedback do you ask readers for? How do you compute popularity? What to do with controversial pieces (articles which would get a lot of positive and a lot of negative feedback)? This just means that this algorithm is not as simple as I said. But it is only a matter of parametrization.

This sort of testing is already widely used

Of course it is. Statistical testing is everywhere, particularly in scientific research. Now, I also believe that it is used by a lot of social media already (but inside messy and complicated algorithms). As a standalone technique for measuring popularity, it is probably not used enough.

Still, here are some organizations using that kind of technique that I’m aware of:

The world-changing organization Avaaz uses a kind of high-tech democratic principle: “campaign ideas are polled and tested weekly to 10,000-member random samples and only initiatives that find a strong response are taken to scale.”¹

This is somehow different but Duolingo, a web and mobile application for learning new languages, uses A/B testing to determine how to improve the learning experience².

##Presenting a new service. Code-name “Bloc”

Wait a minute, this is only conceptual! In the end of the article, you’ll be asked to leave a comment to say if we should build it.

This was imagined by Jules Zimmermann and myself.

We imagined this website on which anyone could post a new article. Articles would be required to be short (half a page) so that people can read them from begin to end and give feedback and no reader would be lost halfway. The articles could link to external references but we would always ask readers to give us their opinion before following these links (only the main content gets reviewed).

The review could be as simple as one of the four options: Like, Dislike, Uninteresting, Flag for shocking content.

Moreover, any article could be shared on the web but we would not ask people who reached the article via a direct link to give feedback. Only the people we randomly select can give feedback. This is important so that someone who has already a lot of followers on social networks cannot artificially increase the popularity of his/her articles: each piece is judged on its own. (Nota: the popularity of a particular piece would not be displayed anywhere except maybe directly to its author.)

We would not provide any means to follow a particular author but they could provide links to their own webpages, blogs or social media accounts.

Anyone could post anonymously or under pseudonym.

Finally, “Bloc” would have both a front page and categories / topics and we would evaluate if a publication is popular for the general public or for the public of such and such categories only. To do so, we would not track reader preferences. We would ask authors to designate a few categories they feel their content fits in. Then we would apply our algorithm independently for each of these categories. If an article gains popularity in most of these categories, we would then test it also on the front page (which means testing how a general audience reacts to it) by applying our algorithm once again.

So, why do we call it “Bloc”?

“Bloc” is a Blog made by everybody who Collaborates. Bloc represents also the block design we had imagined for it. Each block would link to an article, I mean, a Bloc (that would be the name we would give to posts).

Medium.com is similar but yet different

Evan Williams, one of the founders of Blogger and Twitter, strikes back! I won’t give a full description of “What is Medium” here: there are plenty already available out there^{3 4 5 6}. But I will still say a few things about it:

1. The core idea is the same³. Everyone has ideas. Giving an audience to everyone. Even if you don’t write often.

2. Their algorithm to give an audience to everyone seems more complicated (even if they don’t reveal it). And surely, it does not give an equal opportunity to every post.

3. They have stripped down many social media functions, but not all: in particular, it is possible to follow an author. I don’t see it as a problem though.

4. Several journalists have tested it and said it was a great writing tool^{4 5}. I feel I should test it too to measure how well it reaches its goal: giving an audience to posts by non-famous people.

So, until further notice, we’re not going to build “Bloc”. If you think the two things are different and we should make “Bloc” happen, please leave a comment telling so. Meanwhile, I think I’m going to try writing a post on Medium and see how it gets spread (if it does). I would encourage anyone who likes writing to try it too and if you’re nice, you’ll let a comment about it here. In particular, the big question is “Did it help you reaching an audience?”

Update: based on this post and based on the comments it received, it looks like Medium.com is getting away from their initial goal and becoming more or less yet another social network and blogging platform. Also, spoiler, their editor is not that good: well maybe for non-tech journalists it is but I did not like it at all.

Our societies are global constructions but, at a much smaller scale, one can think of a company as being an example of what voluntary cooperation of many can build. There are many tools and techniques which are used inside a company to make sure that everyone’s work is used to advance toward the common goal. One of these is the hierarchical structure. Another and necessary tool is communication. Communication can be from one human to another through oral language, it can be from one to many through seminars, written reports, it can be from many to many through meetings and workshops, it can combine many voices into one through vote.

In recent times, technical advances in the information technology (in particular the internet) have led to a breakthrough for communication tools. Even before the web, the e-mail had drastically improved intra and inter-company communication. Outside the entrepreneurial world, forums have enabled members of self-formed, amateur communities to share their experience and help one another.

Since then, new tools have emerged, some of them allowing so-called real-time collaboration. One tool, namely wiki, has made possible mass collaboration toward the creation of a global knowledge bank. Knowledge being necessary to intelligence, I would like to call this a first step toward the creation of a global intelligence.

Collaborative science

A lot of tools have been developed to enable mass collaboration. Sometimes, this is uninformed collaboration: people play an active role in helping out automatic character recognition via the system of reCaptcha¹. This is also an example of a case when people can help out without any particular technical knowledge.

At an ACL2 seminar last year, I listened to a talk of Prof. Mike Ernst on how people can help science while playing games (he was trying to apply it to specific software verification problems but anyways). There is one well-known example of this: it is FoldIt. But this approach cannot be applied to any type of problems and it requires a lot of thinking to transform a complex scientific problem into a game.

I’m more interested in finding ways to enable people with some minimal technical knowledge (even when this is self-taught knowledge) to take their part in the scientific journey. Galaxy Zoo, a website where people can contribute to astronomy by looking at images from telescopes like Hubble and annotating them, is a good example that you do not necessarily need to gamify science to make it attractive.

Through education, people generally learn a lot on many subjects. Most of this accumulated knowledge, while helping them to forge their own view of the world, will have no future usefulness for them at all. Sometimes, people can be genuinely interested in one subject and remember a lot of what they learned, but they won’t necessarily use any of it in their future work. I am sure that some of them would be happy, if given the opportunity, to contribute to projects where this knowledge can be useful. That could mean contributing during their leisure time and for free. In fact, there are already lots of examples for what I am talking about. People classifying stellar objects are one, developers contributing to open source applications are another. There is interesting scientific literature on why people contribute to these projects².

Given that people are willing to spend some of their leisure time to achieve collaborative side-projects, we (the computer scientists, the engineers, the developers) have a responsibility to create new tools to make it easier. And everybody has a responsibility to spread this new culture.

A lot of tools already exists. For open-source software, a lot has been thought and done already. This is not surprising: developers are helping themselves. It’s time to help other communities too.

From collaboration to mass collaboration

There is no clear limit when a collaborative project becomes massively collaborative. Given the project, the critical threshold can vary. But for all projects, the more people are involved, the more necessary specific tools are for the community. There are also lots of examples of projects that are both massive and not: a lot of open-source software rely on a small community of developers but have a much larger community of testers and even more people contribute once by sharing an idea for an improvement.

This is most likely that not all projects are suitable for massive collaboration. However, no massively collaborative project can succeed if it has not been thought carefully first and if the necessary tools are not available. Wikipedia wouldn’t be this wonderful giant encyclopedia if not for a software allowing everyone to make changes and regular users to track these changes. Can you imagine what it would be if not for this control tool?

There is a collaborative project I’m very much interesting in. It is called Polymath. People have discussed math and created proofs together for a very long time but Polymath is using the internet to invent proofs with tens to hundreds of participants. Yet, there are many more than hundreds of people who have the knowledge and ability to help with a proof. What about a proof that would involve thousands to millions of participants? At that scale, a new tool is required³.

Comments: please do not hesitate to leave a comment below. I would especially appreciate if you would take some of your time to share any information you have on any new and interesting collaborative projects you heard about or any pointers to scientific literature on the subject.

C’est un concept assez simple et il n’est pas nouveau dans mon esprit. Cependant, il se heurte à un problème majeur : comment convaincre les gens de partager leurs idées alors que ces dernières ne peuvent être protégées que par le secret ?

En effet, il n’y a pas de propriété intellectuelle sur les idées en général :

• Elles ne peuvent pas être protégées par le droit d’auteur. Seul l’écrit décrivant l’idée est protégé. Pas le contenu conceptuel. On peut accuser de plagiat celui qui décrirait de nouveau la même idée par la suite sans citer son auteur original. Mais on ne pourrait pas attaquer celui qui mettrait l’idée en oeuvre, par exemple en créant une entreprise.

• Lorsqu’une idée est réalisée par la création d’un logiciel, ce dernier est aussi protégé par le droit d’auteur. C’est pourquoi vous n’avez pas le droit de copier le logiciel et de l’utiliser sans l’accord de son auteur. En revanche, le droit d’auteur ne vous empêche pas de reproduire le logiciel à l’identique ou presque, si vous le re-codez de zéro. C’est une situation qui survient fréquemment et donne lieu à une concurrence effrénée entre plusieurs acteurs, sans que le premier à avoir eu l’idée ne tire de gros avantages, si ce n’est celui d’avoir commencé plus tôt.

• Certaines idées, à savoir les inventions et les procédés industriels, peuvent être brevetées, à condition d’avoir été décrits en suffisamment grands détails. L’idée initiale à partir de laquelle va naître l’invention n’est pas brevetable en tant que telle.

Peut-être que la solution réside dans un argument donné par Tim Gowers dans l’article de blog à l’origine du projet Polymath.

C’est ici qu’entre en jeu ce qui fait la beauté des blogs, des wikis, des forums, etc: ils sont entièrement publics, de même que l’est leur historique complet. Pour comprendre quel impact ça peut avoir, imaginez qu’un problème était résolu via les commentaires d’un article de blog. Supposons que le blog était très actif et que l’article en question recevait plusieurs commentaires intéressants. Et supposons que vous ayez une idée qui vous semble être potentiellement bonne. Au lieu de la réaction habituelle qui consiste à avoir peur de partager votre idée au cas où quelqu’un trouve la solution complète avant vous, vous auriez peur de ne pas la partager au cas où quelqu’un trouve cette idée précise avant vous.

Cette même idée est derrière la raison pour laquelle il a lancé ce projet à ce moment particulier :

J’avais imaginé faire ça depuis longtemps. La raison pour laquelle j’ai soudainement décidé de me lancer, c’est que j’ai suivi quelques liens depuis cet article sur le blog de Michael Nielsen et que j’ai découvert que, sans surprise, d’autres ont eu des idées similaires, et certaines personnes font déjà de la recherche en public. Mais l’idée semble encore plutôt neuve, en particulier appliquée à un unique problème de mathématiques, donc je voulais la tester tant qu’elle était encore fraîche.

La conclusion c’est que, dans le monde d’aujourd’hui, garder une idée secrète n’a plus grand sens, à moins que vous soyez très motivés par sa réalisation à court terme.

En effet, si vous ne la concrétisez pas vite, il est probable que vous ne serez plus le premier à l’avoir eue et que vous ne serez pas du tout crédité pour elle. Tandis que si vous la partagez, même si vous n’en retirerez pas nécessairement tous les bénéfices, vous pourrez au moins en assumer la (co-)paternité.

Car la publicité d’internet fera que les personnes qui auront, en fin de compte, réalisé votre idée ne pourront pas faire comme si vous n’existiez pas et seront tenues de donner des explications : soit votre idée les a inspirées, soit vous avez eu la même idée qu’elles (ou une idée similaire) de manière indépendante¹. Quel que soit ce qu’elles affirment, vous serez cité et ça aura certainement un impact sur votre réputation.

Pour finir, il serait grandement stupide que cette idée-ci (le concept d’un lieu où chacun puisse partager ses idées) traine longtemps dans un placard avant sa réalisation. Il faut donc trouver rapidement une voie de la rendre publique, éventuellement un article de blog, même si ça nécessite de créer un blog².

J’en profite pour rajouter que si vous êtes intéressé par cette idée, n’hésitez pas à laisser un commentaire : peut-être pourra-t-on la réaliser ensemble…