Stamen is a design/technology company known for its data visualization and open work (e.g. Stamen Watercolor). SteveG consults for Stamen now and then on mobile and is known for another open source map toolkit (WhirlyGlobe-Maply) which made the transition to Metal years ago.
We're floating a proposal with some of Stamen's clients to upgrade MapLibre Native to:
- Open up the rendering subsystem in MapLibre Native
- Implement a Metal rendering module for iOS / MacOS
- Build doc and learning modules for adding new rendering pieces
The biggest goal is to bring MapLibre Native into the modern GPU era. Second is avoiding this problem in the future by making it easier to experiment with the rendering core. Last, to use that as an educational tool to expand real time rendering expertise in geo.
And yes, getting paid. This is too big an effort to expect volunteers to do and, frankly, the big companies who need this should be expressing their desires in cash.
Stamen has a number of large clients using old versions of MapboxGL, all facing much the same problem. Do they spend money upgrading to the closed version of MapboxGL or do they spend money enhancing the open version (e.g. MapLibre Native)?
I do not have clients using MapboxGL, for the most part, but I don't like how things shook out over the last decade in open source geo. A chance to fix that problem is enticing.
We're all aware this is a group effort. It's impossible to predict who will do what pieces and it's clear this work needs to be done in the open.
What Stamen is proposing is a series of short efforts to try to move the ball forward. We follow the plan laid out above in general, but propose specific deliverables with short timelines and see how the community reacts.
Frankly this complicates the normal consulting process. Usually we (both Stamen and SteveG's companies) make a proposal, we haggle a bit and then we start, getting paid with various milestones.
In this case, the potential client(s) want the community involved. And so we now bring as much of this process in the open as we can.
Which is to say that Stamen is making the general proposal above to companies who can pay for it, but various stakeholders want to know how the community feels about it.
This could go on for pages, so let's keep it short.
Our main goal would be an interface compatible upgrade to MapLibre Native that supports the new rendering architecture. If you have an app which works with the last open MapboxGL, you should be able to recompile it with the new MapLibre Native with, ideally, no changes. Or at the very least just a few changes.
That implies a lot. Most of the toolkit would not change. We'd suggest just modularizing the rendering core and then adding a direct Metal implementation as a sibling to the OpenGL ES implementation. Other siblings could be added later, like Vulkan or DirectX or more exotic implementations.
That's not as ambitious as some ideas, but it's not incompatible with them either. Once there's a modularized rendering core, you could implement a module in other languages or APIs as long as it interfaces to C++. One could imagine a Rust/WebGPU based approach that used this as a stepping stone.
We'd like to get a sense of what the community thinks of doing it this way. That will inform how the potential clients feel and we'll proceed from there.
This is a complex process and there are no guarantees it will lead anywhere, but this is what we're up to and we'd like to hear what you think.