# uMap 2

> [en] But it’s deeper that that. Open source is *good for humanity*. It’s only slightly hyperbolic to say that ==open source is one of the most notable collective successes== of humankind as a species! It’s one of the few places where essentially all of humanity works together on something that benefits everyone. A world without open source would be substantially worse than the world we live in.
>
> <cite>*[Paying people to work on open source is good actually](https://jacobian.org/2024/feb/16/paying-maintainers-is-good/)*</cite>

J’ai déjà parlé [d’open-source](/david/2024/01/18/), de [mécénat](/david/2024/01/31/), de [versions](/david/2024/02/09/), de [licences](/david/2024/02/15/), mais comment se passe une *release* de produit open-source ?

On commence à avoir affiné et [documenté le processus](https://docs.umap-project.org/en/master/release/), on a [des scripts dédiés](https://github.com/umap-project/umap-deploy-osmfr) pour arriver à cela lorsque le moment est venu et nous sommes pour l’instant 2 à pouvoir faire cela de bout en bout avec [Yohan](https://yohanboniface.me/). C’est peu mais c’est aussi +100% par rapport à l’année dernière…

Nous n’étions pas très loin de repousser encore une fois la version 2 car il y avait un dernier changement majeur à faire passer. Tiraillés, nous avons repoussé cela à une version 3 quitte à ce qu’elle arrive prochainement. Franchir cette barrière psychologique était important pour la suite. Le faire en visio de bout en bout (comme une bonne partie de nos interactions sur le produit) était enthousiasmant. En bonus, c’était un vendredi après-midi.

Voilà donc [un *changelog*](https://docs.umap-project.org/en/master/changelog/#200-2024-02-16) déjà bien chargé. Nous nous sommes rendu compte au cours du processus que le versionnement était davantage pertinent pour les mainteneur·euses que pour les utilisateur·ices. Les fonctionnalités sont ajoutées au compte-goutte mais il faut prévenir les personnes qui vont mettre à jour l’outil de ce qui pourrait coincer lors du déploiement. Certains changements ont été volontaires (modules ESM => support navigateurs), d’autres contraints (fin du support de l’authification OpenStreetMap OAuth1), d’autres subis (Django 5 => Python 3.10). Un beau mélange.

Je ne vais rien annoncer pour une version 3 car ce serait ajouter une pression inutile et même si on a des intuitions tout est loin d’être priorisé. Dans mes motivations *personnelles* :

* aller vers une amélioration de l’accessibilité ;
* voir les [explorations d’Alexis](https://blog.notmyidea.org/tag/umap.html) prendre forme ;
* clarifier les lieux de support / documentation en participant davantage.

> [en] We have to accept the world as it is – even if it’s not the world we want. This means we have to be okay with the idea that maintainers need to be paid. Far too often I see arguments like: “==maintainers shouldn’t be paid by private companies because the government should be supporting them.==” Sure, this sounds great – but *governments aren’t doing this!* So this argument reduces to “open source maintainers shouldn’t be paid”. I can’t get on board with that.
> 
> <cite>*Ibid.*</cite>

Étant actuellement payé par l’Agence nationale de la cohésion des territoires pour participer à de l’*open-source*, je ne peux qu’approuver cette partie de la citation et être heureux de me trouver là où je suis. Les exceptions existent grâce à une conjonction de volontés, de privilèges et de coups de bol.

---

> [en] [uv](https://github.com/astral-sh/uv) represents a milestone in our pursuit of a “[Cargo for Python](https://blog.rust-lang.org/2016/05/05/cargo-pillars.html#pillars-of-cargo)”: a comprehensive Python project and package manager that’s fast, reliable, and easy to use.
> 
> <cite>*[uv: Python packaging in Rust](https://astral.sh/blog/uv)*</cite>

Un futur de Python se dessine et j’en apprécie les esquisses.

#commun #décision #opensource
