Since the publication of Nadia Eghbal’s groundbreaking 2016 report, “Roads and Bridges: The Unseen Labor behind Our Digital Infrastructure,” physical infrastructure has become the favored metaphor for sustainability in OSS.
I find this metaphor fascinating. Professionally, I’m a product manager and programmer, but I also spend a lot of my time thinking about cities. My hobby is to explore how technology, culture, economics, and geography drive outcomes in urban environments. Though I had both used OSS and studied cities for years, it was Eghbal’s “roads and bridges” imagery that first made me see the connection between the two.
I learned in school that metaphors are a kind of flourish, something ornamental and unnecessary for pragmatic, utilitarian writing. In the years since, I’ve come to realize that this view is sorely lacking. Metaphor is not just a question of rhetoric. It shapes our perception of problems as well as the solutions we pose to address them. Indeed, metaphor dictates the way we understand the world. For that reason, it’s especially important to examine those we rely on again and again, and to learn from the lessons they offer.
Cities and OSS share three challenges that stand out to me in particular: governance, funding, and congestion. There’s no one correct solution to any of these problems, but the long history of cities offers useful models for OSS—not only for what can work, but for what is possible.
How to make decisions
Collective decision-making is a challenge for both cities and OSS projects. Both types of communities have many players contending for outcomes, and who has the authority to decide is continuously under negotiation.
In cities, for instance, planning a bus route requires weighing a wide range of considerations that affect groups in different ways, including (but certainly not limited to):
Where do people currently travel to and from the most?
Where would riders like to travel more but currently cannot?
What communities are disadvantaged in terms of transit access?
Does the planned route perpetuate historic, structural inequality?
How will this route affect the neighborhoods it passes through?
These questions echo the choices that OSS projects must make:
Which features are used the most?
Which desired features are missing?
What kinds of users does this project currently not serve?
Does this planned feature benefit one group at a cost to another?
Will this planned feature affect a user who already depends on this project?
This is part of what makes an OSS maintainer’s job so demanding: They’re charged with making decisions on behalf of a community as a whole. They also set the tone for governance. In other words, they decide how decisions get made, which is the most momentous decision of them all.
Perhaps the most important factor when it comes to governance, in both cities and in OSS, is the degree to which authority is centralized. Some OSS communities, like Elm or Redis, have strong leaders with opinionated tastes. Major (if not all) changes pass through that person’s filter, resulting in a clear, cohesive vision. They tend to make big decisions swiftly after sustained periods of contemplation. In contrast, decentralized OSS ecosystems like JavaScript or Bitcoin evolve through an accretion of small individual contributions. Big initiatives require consensus building. It’s harder to make big, sweeping changes, even when many people agree they are necessary. At the same time, they tend to see more continuous small-scale evolution that’s harder to accomplish when there’s a centralized bottleneck.
There’s no ideal amount of centralization. There are trade-offs as you move toward either extreme. The development of 19th-century Paris and modern-day San Francisco are two examples that illustrate how cities have grappled with the advantages and disadvantages on both ends of this spectrum.
Under Emperor Napoleon III, the French capital was renovated over 16 years in a series of ambitious, controversial projects made possible by the centralized control of an imperial government. They leveled neighborhoods to make way for a centralized sewer system, aesthetically consistent buildings, and straight roads that cut across the city. On one hand, the project destroyed the lives of hundreds of thousands of Parisians. On the other hand, it dramatically improved living conditions for following generations. It also recast what is now one of the world’s most beloved cities. It was a decisive undertaking that could only have had the necessary legitimacy and momentum with a centralized decision-maker calling the shots.
This stands in stark contrast to the far more democratic approach of modern-day San Francisco, my home city. In the midst of a housing crisis, San Francisco doesn’t have enough residential development to satisfy current demand. The solution is clear: Build more. However, our collective decision-making process gives broad veto powers to almost everyone in the community. This empowers small groups to stall or kill projects that would alleviate the shortage, protecting narrow interests while hurting the community as a whole. This is a serious shortcoming of the existing system.
But the story is more complicated than that. San Francisco’s labyrinthine permitting process is the unforeseen consequence of well-intentioned activism. Power used to be far more consolidated, and, in the 1940s, city planners sliced through the city to create elevated highways, bulldozing entire neighborhoods in the process. (It’s no coincidence that those neighborhoods often belonged to working-class communities of color, who were not represented in the rather homogenous ranks of the city planning office.) The consequences were devastating: the wholesale destruction of entire communities. In response, a 1959 petition bearing the signatures of 30,000 citizens—4 percent of the city’s population—was presented to the board of supervisors to halt these projects.
To prevent the future exclusion of relevant stakeholders from city planning conversations, San Francisco reversed its governance structure. Reforms brought about discretionary review, a practice which allows anyone to file an appeal against a building permit. It was intended as a checks-and-balances mechanism to ensure that citizens had a say in how their city would be shaped, to be used only in “exceptional and extraordinary circumstances.” However, almost every permit now goes through the discretionary review process, due to ever-expanding interpretation of its vague language.
“All anyone will have to do is dredge up some feeble-minded citizen to oppose, and we will sit for a full-dress hearing,” warned a planning commissioner in 1954 who opposed the changes. This patronizing comment both evinces the planners’ arrogance (which triggered the very reforms he criticized) and foreshadows the issues the new system would come to create. The pendulum swung from an era of bold but destructive changes to a new paradigm of frustrating stagnation and skyrocketing rent. In both scenarios, residents with the least power, economic and otherwise, suffer most.
The examples of Paris and San Francisco demonstrate the complexities of determining how and where power should be distributed. While OSS projects have a profoundly different scope than cities, they also touch many aspects of human life. And as our relationships and livelihoods move increasingly online, it’s all the more important to ensure that OSS projects understand the stakes. As fundamentally collaborative endeavors, they must also choose between centralized or consensus-driven governance, balancing speed and clarity of vision with the needs of everyone affected, and working toward what’s best for all while ensuring that all are heard.
How to secure funding
In cities, it’s politically expedient to underinvest in maintenance. The New York City subway, for instance, transports nearly six million people per day, but budget cuts have left the system with chronic problems that disrupt commutes, frustrate schedules, and isolate neighborhoods.
How did this happen? Well, the repercussions of deferred maintenance only appear years or decades later, while local politicians operate on a radically different timeline: in two- to four-year terms. The temptation to divert the budget from maintenance to prestige projects is hard to refuse, and in New York, one mayor after another has diverted tax revenues earmarked for the city’s transit system.
The dynamics of supporting OSS are similar. The benefits from the software accrue over a long time and impact a wide range of people, while the consequences of deferring maintenance lag. Currently, OSS operates less like a subway (underfunded or not) and more like a group of volunteers running a carpool service. Investing more resources—human and financial—into the digital infrastructure of OSS would yield even more value in the form of stable, secure, innovative, and efficient software. We could unlock further potential if there were a more proportionate match between the value created and the value captured and invested back into our digital infrastructure.
Take PostgreSQL, which puts a world-class database at every developer’s fingertips. A 2016 report by the market intelligence firm IDC found that organizations that used PostgreSQL spent 65 percent less on combined capital expenditure and operating expense on average. On top of this, AWS’s popular Relational Database Service product is one of their primary offerings, which is effectively “PostgreSQL as a Service.” PostgreSQL’s liberal licensing makes it hard to measure the project’s total impact, but even a conservative estimate of the value it creates is astounding.
However, PostgreSQL sees only a tiny fraction of this value—in code, money, and staff time—in return. A generous corporate donor may give $20,000 per year, but even that amount is minuscule compared to the value a software company derives from PostgreSQL. This is a problem not because this rate of return is unfair, but because it leaves so much utility on the table. If PostgreSQL’s development were just 5 percent faster, the entire software industry would benefit. What might it look like with the resources to do more?
OSS could draw inspiration from cities with thriving rail service and secure funding streams. In Singapore and Hong Kong, robust transit systems are funded by land value capture (LVC), a policy approach that recovers property-value increases generated from public investment. According to the Lincoln Institute of Land Policy, transferable development rights, betterment contributions, public land leasing, inclusionary housing and zoning, linkage or impact fees, business improvement districts, and certain applications of the property tax are all common LVC mechanisms.
When a city builds a new subway line, the neighborhoods that surround it see an increase in property value as they experience an increase in accessibility. This growth in value is then reflected in higher property taxes paid by the owners of that land, as well as in the higher rents the owners can charge. LVC describes when that revenue is funneled back into the infrastructure that increased the property values in the first place. However, in many U.S. cities, that key condition is often not met. Rather than return to the subway for its expansion and maintenance, property taxes go elsewhere.
In contrast, Singapore and Hong Kong channel those funds back into their transit systems. “Development helps to pay for itself by unlocking the funds necessary to bring forward the infrastructure needed to support further development,” writes Edwin Loo, a Singapore-based urban planner, in The Financial Times. The result is apparent in the very fabric of the city: superior service, world-class trains and stations, and regular expansion of the rail networks. When sufficient value created by the system is fed back into it, the pace of development accelerates.
Currently, little of the value created by OSS is captured and reinvested, but Singapore and Hong Kong’s stewardship of land assets are legitimate blueprints for change.
How to manage congestion
Physical infrastructure calls for large initial investment but has low marginal costs. For example, the construction and overall maintenance of a new road is expensive, but each additional car that uses that road doesn’t much increase the cost. However, the more cars use the road, the faster it wears out and the more traffic slows.
It would seem that OSS need not worry about gridlock. After all, software’s duplication and distribution costs are effectively zero. But OSS has real marginal costs; they’re just less conspicuous. Every time someone pulls down a new dependency, the maintainer of that package has an additional person who might ask questions, demand a new feature, or open a pull request. As a project scales, the workload of supporting its users grows with it. This manifests as unresolved issues piling up, unmerged pull requests, and shrill commentary that stresses out the maintainer but offers little in the way of help.
There’s an asymmetry between the low cost of community participation and the high cost that others’ participation places on the leaders of the community. Over time, this becomes a problem for users of the project, too. If the maintainer of a package you depend on is already inundated with requests, they may not have time to help out when you run into a problem or request a new feature.
This problem has a lot in common with automobile traffic. Each car on the road increases congestion for everybody else, but individual drivers don’t pay for the congestion they create. Freed from that expense, drivers are incentivized to get in their cars despite the possibility of traffic. However, the more drivers there are on the road, the more likely they’ll end up in gridlock.
To combat this, some cities institute congestion pricing, which requires drivers to pay to access busier roads. Stockholm, Singapore, and London, among others, have implemented it with much success, including increased revenue and reduced congestion.
In the realm of OSS, the duplication cost of software is zero, but the cost of maintenance and support is not. This burden is borne especially by maintainers. Meanwhile, it’s all too easy for users to add to a maintainer’s workload—a kind of cognitive congestion—in ways they, the users, don’t actually value that highly: by opening an issue without checking if anyone has asked the same question before, submitting a pull request with zero test coverage for an unsolicited feature (maintainers sometimes call these “drive-by PRs”), or just adding another thumbs-up emoji to a rude comment. In one sense, it’s a measure of a project’s success that so many users want to engage. But it puts an increasingly heavy burden on the maintainer to wade through it all. Ultimately, this outcome is harmful to everyone involved because it distracts the maintainer from higher priorities that would be of more benefit to the project community as a whole.
What would congestion pricing look like in OSS? One idea would be to charge to open an issue or PR. It wouldn’t have to be expensive to have an effect—there is a big psychological difference between $1 and $0. Alternatively, community members could begin with a limited set of tokens that they could spend to open an issue or PR. They could also earn additional tokens as they made valuable contributions to the project and demonstrated longer-term investment. However it might be implemented, congestion pricing offers a compelling model for rebalancing the burden that unproductive interactions place on OSS maintainers.
How to find hope
Physical infrastructure requires immense cooperation, yet it’s easy to underestimate it once it’s in place. We think of sewers, transit networks, and bridges as problems that have already been solved, but it wasn’t so long ago that major cities didn’t have them at all. (As late as the 1960s, Japanese cities lacked central sewage systems, but over just a few decades, central sewage expanded from serving less than 5 percent of the population to serving almost everyone.) Today, we’re still innovating on technical and social systems to build infrastructure better. Aligning stakeholders, even when it’s in their long-term best interest to work together, is no small task.
The history of cities should give those of us in open source hope. While OSS communities face major challenges, from governance to funding to limited resources, urban communities have overcome issues like these before. After all, cities have had 10,000 years (give or take a millennium) to figure it out, and they still have more to learn. Open source has only just begun.