Ian Schuler is the CEO of Development Seed — the team behind a lot of the open source tooling that quietly holds up the geospatial world. He’s been at the helm for over a decade, and in this conversation, we dig into what he calls the great retooling: the idea that cloud-native geospatial is about to flip from an emerging pattern to the dominant one, and that AI is the thing tipping it over the edge.
The argument is simple — agents want to discover your data, query it, transform it, and hand back an answer. If your data isn’t in a format they can reach, you’re simply not part of the conversation anymore.
A really enjoyable one. I hope you get as much out of it as I did.
Register for the forum 👉 https://2026.cloudnativegeo.org
—
This episode is sponsored by the Cloud Native Geospatial Forum. The CNG Forum 2026 runs October 6–9 at Snowbird, Utah — three days of real-world cloud-native geospatial (STAC, COGs, GeoParquet, Zarr, and more) with the teams actually building this stuff at scale, plus a hands-on workshop day to kick things off. Register at https://2026.cloudnativegeo.org
In Conversation
Meet Ian Schuler and Development Seed
Daniel: You’re the CEO of Development Seed. Could you put a few more words around the short introduction I just gave — what is Dev Seed up to these days?
Ian: I’ve been running Development Seed for about 12 years, but it’s existed much longer than that. It was created in 2003 by three grad students who were in Ayacucho, Peru — Eric Gunderson, Bonnie Bogle, and Ian Ward. They were seeing this moment where the idea that “the future is here, it’s just not evenly distributed” was very real. Being in rural Peru, the technology wasn’t being used the way they thought was possible. So they started an organization focused on the development organizations, governments, and public institutions that are critical to society, helping them catch up with where things are in technology and data. That group ended up building a tool called Mapbox, which spun out as a separate organization in 2013. I took over Development Seed at that point and continued the journey, and that has led us deeper into geospatial and Earth observation.
Daniel: So it didn’t start as a geospatial company — you grew into that. If you could go back, would you still choose geospatial?
Ian: Yeah, I think so. Data about the Earth and its populations is pretty much the most important information out there, and from a technology standpoint it’s been a really exciting place to be — the transition to the cloud, the growth of AI in both computer vision and LLMs. One of the unique things about Development Seed is that we’ve always been an open-source shop. As we build things, we’re kind of putting ourselves out of business — by the sixth or seventh time we build something, hopefully we build it in a way that you don’t need Dev Seed anymore. That forces us to keep thinking about what’s next. I wouldn’t have chosen anything else.
What “The Great Retooling” Means
Daniel: In our first conversation you kept repeating this phrase — the great retooling. What do you mean by it, and how does it relate to cloud-native geospatial?
Ian: The great retooling is an internal term for what we believe will be a massive shift in the tools people use to work with geospatial data over the next couple of years. There are two components. First is the shift of cloud-native geospatial from an emerging pattern to the dominant pattern for managing and distributing data. Second is the increasing adoption of AI or agentic tooling for understanding, parsing, discovering, and visualizing that data. It’s really that second part that drives the velocity of the first — people will shift to cloud-native infrastructure because they need to in order to take advantage of these AI capabilities. We’ll quickly find ourselves in a place where if your data isn’t available to agents, it just won’t be part of the conversation anymore.
Daniel: Is the technology — the file formats and standards — mature enough to handle the shift that’s coming?
Ian: It’s still a very dynamic place, and new standards keep emerging. But I think the known known is this: we don’t know which AI tools will win, but we have a pretty good idea of how they’ll want to consume data. They’ll want to look over large masses of data efficiently, grab just the bits that are interesting, and transform that data without a lot of overhead. Those access patterns are fairly predictable, and right now the cloud-native data formats are the best available approach for accomplishing them.
Inside a Cloud-Native Stack
Daniel: Could you describe a cloud-native stack for me — in simple terms, not for the engineer?
Ian: In the simplest terms, a cloud-native stack is one built for machines as the primary user rather than humans. In the old days, humans worked on files on their own computers, subset them, and handed them to someone else. Cloud-native formats put that data in a way that performs really well when you have a lot of computers in one space — essentially blob storage, buckets of data with light organization over them, but indexed so an API call can find the right information and, hopefully, the smallest amount of information necessary to answer its question.
Daniel: And finding just the bits the agent wants to access — that’s range requests?
Ian: That’s largely the method, yes. For me this is one of the magical things about cloud-native — I just get that piece of information instead of being told to download a 30-gigabyte GeoTIFF, unpack it, and pull out just the bands I’m interested in. Now I can bring my analysis to massive amounts of data. But what was most interesting is the access patterns it opens up. I can build a precision-ag app, and when somebody looks at their field, it gives them the information at the speed people expect on the web. It opens up use cases, ways of communicating, and business cases that weren’t possible previously.
New Use Cases Cloud-Native Unlocks
Daniel: Do you have interesting examples of business cases or use cases that weren’t possible before?
Ian: On the business side, point at any of the apps that let users look at their farming data and pull Sentinel or predicted-yield data for a very specific place on Earth. Even modern weather apps wouldn’t be possible without these formats. One area that was fun for me was work we did with NASA around biomass data. There’s a project called MAAP that NASA has been working on for years, supported by their office for data science initiatives, that we build alongside JPL. Once you get missions like NISAR and the biomass satellite — instruments really good at understanding forests — the data they produce is massive. You’re not going to download that onto your computer; you have to bring your analysis to the data. It’s one of those domains where that’s mandatory.
Ian: The neat thing is that once you reorganize how people do their work — away from university-based supercomputing clusters and into the cloud — you enable collaboration across universities. People who used to be at the same institution can keep collaborating. One team that finds something can much more easily make it available to another group. You get toward these loops of reproducibility. Jed shared an article with me about “frictionless reproducibility,” and once you have that, it really changes research in that area.
Daniel: Years ago the catchphrase was “take your algorithm to the data.” With cloud-native, the burden is lifted on the data provider — they host less compute — and the consumer’s access increases because they don’t have to pull 500 GB when they wanted 10 megabytes. And it can speed up the pipeline from research to application, because applications can be built on exactly the same data the research used.
Ian: Exactly. And we always come back to satellite data when we talk about cloud-native — partly because it’s a massive amount of data that forces you into these patterns sooner. But there’s really interesting work on the vector side too. The Overture Foundation is probably a good example of vector data in a cloud-native format.
Where Cloud-Native Isn’t the Right Fit (Yet)
Daniel: What use cases is cloud-native not going to be right for, at least not right now? I often talk with the GIS analyst working for a local government who hears about cloud-native geospatial and has no clue how it fits her workflow.
Ian: There are two things to distinguish — the use of the commercial cloud, with its own cost structures, and the cloud-native formats and standards themselves. If you have a workflow that’s working and you’re producing a report every month and you’ve automated exactly how to do it, maybe there isn’t a lot of benefit. The cloud also has real costs. NASA has something like 180 petabytes of Earth data being managed; some of those datasets make sense to move to the cloud and convert to a cloud-native format, and for some the cost equation works out differently. So it’s a question dataset by dataset. That said, more and more of the tooling people will want to use is going to expect data in lighter, more machine-friendly formats — and within the next few years, the conversion will be easier and cheaper than it was a year or two ago.
Daniel: It’ll be interesting to hear stories of people moving away from GeoServer or ArcGIS Server — not needing that infrastructure running constantly in the background, just writing a file, putting it somewhere, and marketing where it is.
Ian: We’re seeing more of that. We’ve had a number of projects over the last year where clients specifically wanted to migrate away from GeoServer into a more cloud-native approach. Those insights are part of what got us seeing this as a trend in our work.
Agentic Interfaces and the End of the Dashboard
Daniel: You mentioned an example — Global Nature Watch, an agentic interface. Would you talk us through that?
Ian: We’ve done about 10 to 12 of these projects. The Land & Carbon Lab at the World Resources Institute is a great example. They have 80-some datasets — and more all the time — about forests, water, carbon stock, biodiversity. The set of people who could benefit from that information is much greater than the number using it, because it’s hard to work with and hard to even know what’s available. The key insight is this: if you were to task a GIS expert with “what are the drivers of deforestation around Lisbon,” that person would understand the question, figure out which datasets exist, find them, query them for the right time and place, run a transformation, and bring back a report. Many pieces of that can be automated by an LLM — they’re very good at writing code, writing API calls, and turning a user’s intent into math you can respond to.
Ian: The important thing is you aren’t letting the agent come up with the answer or hallucinate. It goes and accesses real data and displays it. It might show you Lisbon, Ohio when you wanted Lisbon, Portugal — but it’s showing real data, and you can have a conversation and say, “No, this is what I meant,” and it will fix it. Where this ends up going is even more interesting: eventually people won’t need to come to Global Nature Watch at all. They’ll just ask their agent of choice, “what’s going on with deforestation in my area,” and if your data is in a format the agent can reach, you’ll be part of the conversation — and if it’s not, you won’t.
Daniel: What’s going to happen to the static dashboard?
Ian: The static dashboard was always the least-worst answer to the question. The first project where I saw the power of a map was in 2008 in Afghanistan, when I was the client and hired Development Seed to understand the election. They scraped a 2,000-page PDF of results in Urdu, matched it with polling-station locations, and created a map that changed the conversation in a room full of people who wanted to say it was a good election — they just couldn’t anymore. We learned that most people either wanted the raw data to work with in their own tools, or they just wanted to be told what happened. Very few wanted to play around with a dashboard. So we spent a decade trying not to build dashboards, trying to build data products around a particular purpose. Now we have a whole new set of tools that are the new least-worst option — where people don’t have to learn your interface or taxonomy; they can just ask questions and see results.
The Future of Geospatial Services
Daniel: What does a geospatial services company look like in three, four, five years?
Ian: The one thing I’m confident about is that it will still exist — there will still be a need for this work. I’m also pretty confident it’ll look very different. Some things will be commodified easily, but there’s still going to be a need for people who really understand how to work with data, connect it to problems, and deliver the answer. That still requires really smart, thoughtful humans.
Daniel: I have a quote from you: friction never goes away, it just changes shape. So we’re really in the business of predicting what shape the friction will be in.
Ian: That’s right. One advantage of being in services rather than a big product company is that you see a lot of different pain points. As the world changes, you get early exposure to where the friction is going to be. A lot of our success has been noticing that friction early enough to build an open tool or library that hits a nerve and becomes part of the stack. The best services companies also genuinely care about the client — we select for clients where we believe in what they’re doing. Helping them figure out how to be successful is a more interesting problem than meeting a spec.
Hiring, Careers, and Where to Work
Daniel: This is a brave new world for the people working in geospatial too. As a CEO, what makes a good employee for Development Seed right now?
Ian: Most people aren’t a fit for Development Seed, and that’s perfectly okay. We look for people who are a bit impatient about the state of the world and want to make it better. It’s easier to take someone who understands and cares about the world and teach them tech than to take a technologist and teach them to care. A lot of people at Dev Seed come from public health or forestry and found their way into technology. We have very light management, so we need people with a lot of ownership who are intrinsically motivated, work well in teams, and are good at self-teaching — because what we work on is going to keep changing.
Daniel: And for someone coming into the field — an entry-level geospatial analyst?
Ian: The cliché answer is lean into it, try stuff, work with the emerging tools. That’s not bad advice, but I’d add two things. One: contribute to open source. It’s something we look for as a signal, and it’s a good way to be part of a community and learn from skilled people. Two: on where to work, in times of high tech velocity look for an organization whose mandate is well above its current staffing. That could be a startup. When you see an opportunity to apply a new tool, you’ll be allowed to run with it because there’s so much work and not enough people. Finding yourself in an organization like that, in a moment like this, will do more for your career than almost anything else.
Daniel: Ian Schuler, CEO at Development Seed — thank you so much. This has been a fascinating conversation, and thank you for what you do for our community.
Ian: I appreciate you as well.
