By Ela Kagel, Platform Coops eG, Berlin
I had the honour of giving a keynote at this year’s FOSS4G Global Gathering in Hiroshima, Japan. The invitation came with an interesting challenge: to bring a cooperativist perspective into a community that has been building some of the world’s most important open geospatial technologies for decades.
The organisers provided this question as a starting point: What happens when something that started as a gift becomes infrastructure that the world depends on?
Every open source project begins with an act of sharing. Someone encounters a problem, finds a way to solve it and decides not to keep the solution to themselves. They put the code out there. Others pick it up, improve it, translate the documentation, fix bugs and answer questions. Over time, a community forms around something that none of its members could have created alone.
There is something extraordinary about this. But there is also a moment when the nature of the problem changes. What started as a piece of code can become critical infrastructure. And then we have to ask questions that are no longer primarily technical. Who will maintain it ten years from now? Who has the resources to do the invisible work? What happens when a key maintainer leaves? Who decides when there is a conflict? And who is responsible for making sure that the people carrying the project do not eventually burn out?
These questions are particularly important in the geospatial world.
Why FOSS4G data matters more than ever
Geospatial data and technology has become deeply embedded in how we understand the world around us. We use maps so routinely that it is easy to forget what sits underneath them: enormous amounts of data, sophisticated software, shared standards and the work of thousands of people who make it possible to collect & visualize information about places. The stakes are no longer limited to finding the fastest route to a restaurant.
Geospatial technologies help us understand where people live and how cities grow. They allow us to monitor forests, agricultural land and biodiversity. They help us model floods, wildfires, rising sea levels and so many other scenarios of how nature responds to climate change. When earthquakes strike, maps and geographic information become essential tools for coordinating emergency response and getting aid to the places where it is needed.
Climate change is making all of this even more important. We increasingly need to understand not only what is happening to our planet, but where it is happening and who is affected. This is why the work of the FOSS4G community matters.
Free and open source geospatial technologies make it possible to build this kind of knowledge without having to depend entirely on proprietary systems or a small number of commercial providers. They create an ecosystem in which governments, researchers, civil society organizations, businesses and local communities can access and build upon the same technological foundations.
OpenStreetMap is perhaps the most visible example of what this can mean in practice: a collaboratively created geographic database that has become an important resource for public services and countless applications around the world.
The openness of these technologies is therefore not simply a question of software philosophy. It is increasingly a question of societal resilience, which makes the question of sustainability even more pressing.
Sustainability has an institutional dimension
When we talk about sustaining open source, we tend to think first about the technology itself. Is the software maintained? Is the infrastructure reliable? Then we think about money. Can the project survive through grants, donations, foundations, public funding or commercial services?
These are important questions. But there is another layer that we tend to overlook: the institutional one. Who owns the organization around the project? Who gets to make decisions? How are conflicts resolved? How does succession work? What happens when the people who founded or maintain a project want to step back? And how can responsibility be distributed so that the future of an important piece of infrastructure does not depend on a handful of exhausted individuals?
These are not problems unique to open source. In fact, they are questions that almost every organization eventually has to confront. And this is one reason why I find the cooperative model so interesting.
Cooperatives were invented to organize collective responsibility
We often talk about cooperatives as an alternative business model. Historically, however, cooperatives emerged from a more fundamental problem: how can people organize themselves to achieve something collectively when no individual can, or should, control the whole thing?
A cooperative provides an institutional framework for doing exactly that. It defines membership, ownership and decision-making. It gives people a way to share responsibility and participate in the governance of something they depend on. Open source communities have developed their own remarkable ways of coordinating collective action. They often rely on contribution, trust, reputation, technical merit and community norms rather than formal ownership.
That informality can be incredibly productive. It is one of the reasons open source can grow across borders and institutions so quickly. But when a project becomes essential infrastructure, informality can also become a vulnerability. This is where I see a useful conversation between the cooperative movement and open source.
Not because open source should become more closed or because every open source project should become a cooperative. Quite the opposite. The interesting question is whether we can build cooperative institutions around open commons without enclosing the commons itself.
The unbounded gift and bounded solidarity
There is a fundamental difference between the two models. Open source creates something that can, in principle, be used by everyone. It is an unbounded gift: the software is shared beyond the group of people who created it.
A cooperative works differently. It creates a defined community of members who share ownership and responsibility. In that sense, it is a form of bounded solidarity. These two principles do not have to compete. A cooperative could provide a stable institutional home for the people and organizations maintaining an open resource while keeping the underlying technology open and accessible to everyone. This is the idea that interests me most.
What platform cooperatives can add
Platform cooperatives have emerged around a similar question in the digital economy: what would happen if the people who depend on a digital platform could also own and govern it? Instead of extracting value from users and workers for external shareholders, a platform cooperative distributes ownership among the people who create and depend on the platform.
But the principle can be applied more broadly than to marketplaces. We can imagine cooperative organizations forming around open source ecosystems. The code remains open. The data remains accessible. But the organizations providing hosting, maintenance, support, education, professional services and long-term stewardship are collectively owned by the people who depend on that infrastructure.
There are already examples pointing in this direction. CoopCycle, for instance, has developed a federation based on cooperative values around open source technology for local delivery cooperatives. The technology is shared, while the federation provides a structure through which local organizations can collaborate and collectively sustain the ecosystem.
There is no reason to assume that the same model will work everywhere. But examples like CoopCycle demonstrate that open technology and cooperative organization can coexist and strengthen one another. And there is a growing ecosystem of technology cooperatives experimenting with different approaches. Resources such as Tech Co-ops and the Platform Cooperative Directory make this emerging landscape increasingly visible.
What does this mean for financing?
The financing question is particularly interesting. When an open source project becomes important, the usual conversation is about finding a sponsor: a company, a foundation, a government or a group of donors willing to pay for its continued development. That can work. But it also creates dependencies.
A cooperative starts from a different premise. Rather than asking only who might finance the infrastructure, it asks who depends on it and could participate in owning it? Members of a cooperative contribute capital by purchasing shares. More importantly, they gain a voice in the organization and a stake in its future.
Imagine a geospatial ecosystem in which maintainers, users, service providers, educators, public institutions and businesses all depend on the same open infrastructure. A cooperative structure could potentially allow them to share not only the cost of maintaining it, but also the responsibility for deciding how it evolves.
This does not magically solve the funding problem. But it changes the relationship between those who finance infrastructure and those who depend on it.
It moves the conversation from “Who will pay for this?” towards “Who has a stake in keeping this alive?”
We don't need to turn every open source project into a cooperative
I want to be careful here. I am not suggesting that every open source project needs a cooperative structure. Nor do I think that formalizing every community would make it stronger. Sometimes precisely the opposite is true. However, I do think we should do is broaden the conversation about sustainability.
We could start by making the invisible work around open source more visible. Who is maintaining the project? Who is answering questions? Who is carrying the organizational burden? What happens if they stop? We could experiment with shared funding mechanisms and stronger support for maintainers. We could think more deliberately about succession. We could introduce cooperative principles into governance without immediately adopting a cooperative legal structure.
And where the conditions are right, perhaps a cooperative can become the institutional home that allows an open source ecosystem to mature without giving up its openness.
From contributors to stewards
This, ultimately, is the connection I see between open source and the cooperative movement. Open source has shown us that people can create extraordinary things together without having to share the same employer, country or institution.
The cooperative tradition adds another insight: collective creation becomes more resilient when people have institutions through which they can collectively care for what they have created. That distinction matters. A contributor gives something to the commons. A steward takes responsibility for its future.
As open source technologies become increasingly important to society, we need to think about how contributors can become long-term stewards. People who are not only willing to donate their time and expertise, but who also have a sustainable way of sharing responsibility, recognition and value.
For me, this is one of the most interesting questions at the intersection of open source and platform cooperatives. The goal is not to put a fence around the commons. It is to build structures strong enough to keep the gate open.
And in a world facing earthquakes, floods, wildfires, climate change and increasingly complex decisions about how we use our land and resources, the technologies that help us understand our physical world are simply too important not to think seriously about how we will sustain them. Open source gives us a powerful culture of sharing. Cooperatives give us a powerful culture of collective responsibility. The future of our digital commons certainly needs both.