Nicht wenige Nutzer von mapbox-gl-js dürften sich Anfang Dezember 2020 verwundert die Augen gerieben haben. Die neue Version der bis dato unter Open-Source-Lizenz stehenden WebMapping-Library wartete plötzlich mit einer Closed-Source-Lizenz auf. Keine 24 Stunden später findet sich u.a. auf unsere Initative eine internationale Koalition zusammen, um einen Community-Fork einzuleiten – MapLibre ist geboren.
Mich hat der Schritt von Mapbox ehrlich gesagt überrascht – zwar hat Mapbox bereits in der Vergangenheit einzelne Projekte unter einer Closed-Source-Lizenz veröffentlicht, aber im Gesamtbild von Dutzenden, aktiv entwickelten Open-Source-Projekten, handelte es sich doch um einzelne Ausnahmen. Auf jeden Fall schmerzt der Wechsel; hatte sich die Firma in den letzten sechs Jahren doch sehr um die Themen VectorTiles und Performance verdient gemacht und vor allem das Thema GIS konsequent weg vom Drucker gedacht.
Über die geschäftlichen Hintergründe muss man nicht lange rätseln. Wie viele andere Open-Source-Projekte leidet wohl auch Mapbox unter Free-Riding: Dritte vermarkten das Produkt als Clouddienstleistung, steuern aber zum eigentlichen Projekt nichts bei. Allein ist Mapbox damit nicht: So haben sich in neuerer Zeit Redis und MongoDB unter viel Beachtung ganz oder teilweise aus der Open-Source-Welt zurückgezogen. Elastic kündigte das Gleiche letzte Woche für Kibana und Elasticsearch an – was indirekt auch auf GIS-Projekte wie Photon Auswirkungen haben dürfte.
Lizenztechnisch sind wir als Open-Source-User erst einmal fein raus: Nichts spricht dagegen, die letzte unter Open-Source-Lizenz stehenden Versionen einer Software weiter zu benutzen. Lange gut gehen wird das aber nicht: Jede Software braucht aktive Wartung in erheblichem Umfang – Arbeit, die von Nutzern im Gegensatz zu neuen Features nur ungern finanziert wird. Ein klassisches “Tragic of the Commons” also . Das MapLibre-Projekt steht so nicht nur vor der Herausforderung, ein komplexes Software-Projekt mit vielen Unterprojekten zu übernehmen, sondern auch, tragfähige Modelle für die Wartung dieser Software zu entwickeln.
Im Moment gilt es bei MapLibre aber erst einmal, die organisatorischen Themen rund um den Fork abzuarbeiten. Build-Pipelines müssen wieder laufen, die Dokumentation angepasst werden, anbieterunabhängige Demo-Dienste bereitgestellt werden. Ziel ist, dass möglichst viele Nutzer sofort zu MapLibre wechseln können. In der Hinsicht sind bereits Erfolge vorzuweisen (so läuft z.B. der Bewegungsradiusrechner bereits mit MapLibre) und so langsam lichtet sich das Chaos der Anfangszeit.
Ich bin jedenfalls guter Dinge und gespannt, wie das Projekt weiter voranschreitet. Wir werden jedenfalls unseren Beitrag leisten, um zu einem Erfolg von MapLibre beizutragen.