MapLibre: The Fork That Saved Open Mapping

A Twitter Thread on a Tuesday in December

On a Tuesday in December of twenty-twenty, the company Mapbox announced that the next major version of their flagship product, a piece of software called Mapbox GL JS, would no longer be open source. The previous versions had been published under a permissive license called BSD. The new version, two-point-zero, would require an API key from Mapbox to function, would phone home for billing every time a map was loaded, and would be governed by a proprietary license that explicitly prohibited running it without Mapbox's servers.

The reaction was immediate. Mapbox GL JS was, at that point, one of the most important pieces of open source mapping software in the world. It was used by news organizations, by humanitarian groups, by national mapping agencies, by hobbyist projects, by big technology companies, and by hundreds of thousands of websites that needed an interactive map. The library was a foundational layer of the modern web. And in one announcement, it had stopped being open.

Within hours, a fork was proposed on GitHub. The fork started from the last open-source version of Mapbox GL JS, which had been released the previous day under the original BSD license. The fork was given the name MapLibre, and it was governed by a coalition of companies and individuals who depended on the previous open behavior of the library. By the next week, MapLibre had a working build. By the next month, it had its first stable release. By the next year, it had diverged from Mapbox in features, in performance, and in philosophy. Today, in twenty-twenty-six, MapLibre is the de facto open standard for interactive web mapping, and most new projects use it without ever considering Mapbox.

This is one of the cleanest examples in software history of an open-source community defending itself against a commercial enclosure. The story is worth knowing not just because it explains why the modern open mapping stack looks the way it does, but because it reveals something about how the open-source ecosystem holds itself together.

What A Map Library Actually Does

To understand what MapLibre does, you have to understand the trick that makes modern web maps fast. Every interactive map on the web is a stack of tiles. The earth is sliced up into rectangular pieces. Each rectangle is rendered into an image or a vector dataset and stored on a server. When you zoom and pan around the map in your browser, the browser fetches the tiles that cover the area you are looking at, and the library on the page assembles them into a continuous visual surface.

In the early days of web mapping, the tiles were raster images. Photographs of map data, basically. Each tile was a small PNG file. The map style, the colors of the roads and the buildings and the parks, was baked into the image when it was rendered on the server. If you wanted to change the style, you had to re-render every tile. If you wanted to support a hundred different visual styles, you had to render the world a hundred times. Map storage costs were enormous. Style flexibility was minimal.

Mapbox's original contribution to the field, going back to around twenty-fourteen, was the popularization of vector tiles. Instead of sending the browser a finished image of each tile, the server sends the browser the underlying geometry. The roads are stored as lines. The buildings are stored as polygons. The labels are stored as points with attached text. The browser receives this raw geometry and renders it into pixels on the fly, using a graphics processing unit, in real time.

The benefit is enormous. The style is no longer baked in. The same vector tiles can be rendered with any visual style you want. You can have a dark mode and a light mode and a sepia mode and a print mode and a screen mode, all using the same underlying data. You can rotate the map. You can tilt it into a three-dimensional perspective. You can animate features. You can interact with individual buildings or roads. The map becomes a live document instead of a printed photograph.

Mapbox GL JS was the JavaScript library that made vector tiles work in a browser. It was an enormous piece of engineering, written largely by a small team in Washington, D.C., over several years. It used a technology called WebGL to talk directly to the graphics card, which is what gives modern web maps their smooth panning and zooming. It defined a JSON-based style format for describing how to render the tiles, which has become a de facto standard.

When Mapbox closed the license, all of that engineering, all of that style format, all of that ecosystem, was suddenly behind a commercial wall. The fork had to recreate the open path forward. The fact that they succeeded, and succeeded quickly, is genuinely remarkable.

How The Fork Survived

There is a question worth lingering on. How does a fork like MapLibre actually survive? Most software forks fail. The fork has to attract enough developers to keep up with bug fixes and new features. It has to attract enough users to justify the developers' time. It has to maintain enough compatibility with the original that existing users can migrate without rewriting their applications. It has to differentiate enough that new users see a reason to choose the fork over the original. All of these are hard, and most forks die quietly within two years.

MapLibre survived because the constituency for an open mapping library was unusually broad and unusually motivated. Government mapping agencies were dependent on the library and did not want to be locked into a commercial vendor. Humanitarian organizations like OpenStreetMap-based services needed software that worked offline and at low cost. News organizations needed something they could embed in articles without recurring per-view fees. And competing companies, notably Microsoft, Amazon Web Services, and the German mapping company MapTiler, had commercial reasons to support an open alternative to Mapbox.

[serious]

These groups formed the MapLibre coalition. They contributed developer time, sponsored bug fixes, ran continuous integration infrastructure, hosted documentation servers. None of them had to act alone. The cost to each contributor was small. The benefit to each contributor was that a foundational piece of software stayed open. This is the open-source coordination problem at its best. When the incentives align, the work gets done.

The fork also benefited from a small piece of technical luck. The last open version of Mapbox GL JS was, by accident, one of the most mature points in the library's history. The major architectural rewrite that broke compatibility happened in version two, which was the closed version. The last open version was version one-point-thirteen, and it was stable and well-tested. The fork started from a strong base. MapLibre was not stitching together a half-broken codebase. It was inheriting a working product that just needed to keep being improved.

What MapLibre Looks Like In Use

Practically speaking, MapLibre is a JavaScript library you include in a web page. You give it a container element. You give it a style document. You give it a starting position and zoom level. It renders a map. The map is interactive. You can pan and zoom. You can add layers. You can subscribe to events when the user clicks on a feature.

The style document is the interesting part. It is a JSON file that describes, in declarative terms, exactly how every layer of the map should look. The land color. The water color. The road widths at different zoom levels. The font and size of labels. The icons for points of interest. The opacity of building footprints in three-dimensional view. The whole visual style of the map is one large JSON document, which means it can be edited, version-controlled, programmatically generated, or hand-tuned to match a brand.

For journalism, this is enormously useful. A newspaper can define a house style for maps, save it as a JSON document, and use it across every interactive map in every article on the site. Every map looks like it belongs to the same publication. The branding is consistent. The work is reusable. If the design team decides to change the typography or color palette, one edit to the style document updates every map automatically.

The same style can also be used in QGIS, with some translation. The vector tiles can be rendered in QGIS for print using the same data sources. The result is that the print maps and the web maps for the same article can share a common visual identity, which is genuinely difficult to achieve with most other mapping tools. The vector tile pipeline, originally invented to save server costs, has become the foundation for unified print-and-web cartography.

The Coalition Model And Why It Works

The thing worth understanding about MapLibre is that it is governed by a coalition rather than by a single company or maintainer. There is a steering committee. There are working groups. There is a code of conduct. There is a foundation that holds the trademarks. The governance is, by software standards, slightly bureaucratic.

This bureaucracy is the cost of the model, and it is worth paying. The reason MapLibre cannot be enclosed the way Mapbox enclosed itself is that no single company can buy or take over the project. The trademark belongs to a non-profit. The code is contributed by many parties under licenses that explicitly forbid retroactive changes. The governance is designed to resist capture.

[calm]

This is what mature open-source governance looks like. It is not the romantic image of a single brilliant maintainer working out of their garage. It is committees, voting procedures, conflict resolution policies, and meetings. It is dull. It works. The boring governance is precisely what makes the project durable.

For a journalist deciding what mapping stack to commit to, this matters. The boring governance is the reason MapLibre will still be open and free five years from now. Mapbox could change its license again tomorrow and there would be nothing the community could do about it. MapLibre cannot change its license without coalition agreement, and the coalition has explicit reasons not to want it changed. The structural protection is real.

What This Means For A One-Person Newsroom

If you are building maps for a publication, MapLibre is essentially the default choice in twenty-twenty-six. The alternatives have specific reasons to exist. Leaflet, an older library, is simpler and works well for basic raster tile maps. OpenLayers is more rigorous but harder to learn. Google Maps is closed and expensive. Mapbox is closed and expensive and politically tainted by the fork. MapLibre is open, free, fast, well-supported, and increasingly the standard.

The integration with everything else in the open geographic ecosystem is the practical benefit. MapLibre reads vector tile formats that are also produced by open tools. The style format is shared with QGIS through plugins. The tile servers that serve vector tiles are mostly open. The data sources, from OpenStreetMap to national agencies, increasingly publish in formats that MapLibre can consume directly. The whole stack works together because the parts were designed to.

For someone interested in the kind of map work where the same source data needs to be rendered into both a print pull-out and a live web interaction, MapLibre plus QGIS plus vector tiles is the technical answer. The print maps and the web maps share their data source, which means the readers of the printed paper and the readers of the website are looking at the same underlying geography, just rendered differently. The pipeline is internally consistent. The article can reference the map in either medium and the map is the same map. This is harder to achieve than it sounds, and the open stack makes it possible.

A Larger Pattern

The MapLibre story is one instance of a pattern that keeps showing up in modern open-source software. A company builds something useful on open foundations. The company grows. The company decides that the open foundations are now a business risk. The company closes the source. The community forks the last open version and continues. The fork wins because it has more contributors and more legitimacy than the closed version.

This has happened with Elasticsearch and OpenSearch. It has happened with Terraform and OpenTofu. It is happening, in slower form, with various other infrastructure tools that started open and gradually closed. The pattern is now familiar enough that companies announce these closures expecting forks, and the forks form within hours.

The optimistic reading is that open source has become resilient in a way it was not before. The community knows how to fork. The legal infrastructure exists. The coalitions form. The standard does not get captured. The bad reading is that this has become an arms race, with companies constantly looking for ways to enclose the work and communities constantly defending. The energy spent on defense is energy not spent on improvement.

The truth is probably both. Open source as a model has matured. It now has its own defensive mechanisms, its own institutions, its own playbook. The mapping ecosystem, post-MapLibre, is genuinely better than the mapping ecosystem before Mapbox closed. The fork forced a reckoning that produced a more durable structure. The story is, in the end, a hopeful one. Open work, when defended properly, wins. The Tuesday in December was not the death of open mapping. It was the day open mapping learned how to defend itself, and got better at it.