Open Source Cities
If you live in a city (and odds are you do), I’m sure you’re frustrated trying to understand what the city does and why. Cities seem to adopt unpopular policies, even if their elected officials are very popular. If you’re motivated like me and have tried to change things, I’m sure you’re even more frustrated. The way that cities work is not working for most of us, and this is what I aim to change.
Cities are complex and hard to understand. They’re staffed by professionals that tell us to trust them, then don’t earn that trust. And what each person wants from a city can be - and is - so wildly different that it’s difficult to even talk to each other about what we’re trying to do, much less how to do it or even help each other.
The funny thing is, we solved these problems a long time ago in a different domain - computer networks. These exact same problems - complexity, opacity, and disjointedness - have solutions. But the solutions work so well, most people have no idea they exist. That’s why I’m writing this - because I think, even if it takes some time, we can solve these problems again for cities.
I’ll start with a short explanation of how things work, and why that doesn’t work. It’s not that cities aren’t doing work - they just never seem to get the right work done, and every major accomplishment comes at an exorbitant cost. We’ll take a look at why that is, because without that understanding, the solution doesn’t really make sense. We’ll look at how the big three problems we started with - complexity, opacity, and disjointedness - logically come from this standard way of doing things.
Then we’ll look at the solution. There is another way of doing things, and it works. It’s what makes the computers you interact with simple to use, and you have no idea it exists because it does its job so well. I think people understand that computers are complex, but they have no idea how complex they actually are, because we have managed to use that complexity in a way that creates more benefit than harm. That doesn’t mean we don’t have other problems - but having other ways of doing things gives us more options to solve them.
Finally, we’ll look at how some of these ideas are already being applied in cities and how they’re working. We’ll talk about how you can apply them in your city. And I’ll talk about how I’m applying them in my city, if you want to help.
The problem - How and why things (don’t) work
Money
When people set out to understand how and why cities make the decisions they do, cities are often compared to households or businesses. This is misleading for a number of reasons. First, both households and businesses operate to enrich their members by accumulating wealth. Cities are supposed to make sure this process goes smoothly, but cities themselves are not allowed to become wealthy. For the most part, the wealth created in a city is privatized, whether it’s operators of public services collecting fees or homeowners liquidating the increase in value of their properties from neighborhood improvements. The (false) reasoning for this is that the people involved perform the work (drive the bus, fix the house) so they should make the money.
On the surface that makes sense, but it explains why comparing cities to businesses doesn’t work at all. When a business or a household decides what to do, day to day, it’s looking at its finances. It wants to take in more money than it spends. If it doesn’t have the money to spend, or a particular course of action will cost more than it makes, it just doesn’t do it. But that’s not how cities work at all. Cities bring in money through taxes, mostly property taxes, and then decide how to spend it. The idea (in traditional economics) is that nobody would pay for the actual value of the services cities provide, such as public schools, libraries, safety and road maintenance. But that’s ridiculous, because we are paying for it, with our tax dollars.
Where it really falls apart is when you start trying to untangle where your tax dollars are spent, or even how much you’re paying in taxes. You can look at a receipt that has taxes on it, or your tax return, but that’s not even close to the whole story. What part of your rent goes towards your landlord’s tax bill? What part of the price of a pastry goes towards paying the income tax of the person that made it? How much of the taxes on that pastry goes towards funding local schools versus prisons?
It gets even crazier when you try to understand how public services like transit are funded. The money that comes out of your bank account on tax day passes through many, many hands before it pays the bus driver. And many public services are not funded directly through tax revenue. Schools, for example, rely on a complex grant system, and many infrastructure projects like sewers and highways are funded through public debt. While public finance is fascinating and the role of debt in government is hotly debated, I’m going to set that aside for now because what we really want to talk about is work.
Management
One way that cities do act like businesses is in how work gets divided up. Whether you’re working in a city, a business, or the military, all work is divided between three roles - working, managing, and leading. Working is just making changes. This is the part most of us are familiar with. Whether you’re digging ditches or balancing accounts, you’re changing one thing (dirt, a pile of receipts) into something else (a ditch, a map of a financial situation). You might think this is what most people spend most of their work time doing, but you would be wrong - keep this in mind while we’re talking about the other two roles.
Managing is the process of deciding how to get the work done - what to do first, who should do what work, when the job is finished. Most workers have to manage themselves a little bit, and generally the more you get paid the more you have to manage yourself. This part of work is complicated enough that some people can do it as a full time job. These people are called managers.
Lastly, leading is deciding what to do. This is a different set of skills from management. A boss is a leader that also manages. In cities, leaders are elected - similarly to a business’s shareholders electing a board of directors. This election process is supposed to make sure leaders do what the people that voted for them want, but as we can see, that’s not how it works at all. The question is, why?
As we can see, these roles are not neatly separated. If you’ve ever worked from a blueprint or followed furniture assembly instructions, you know that no amount of instructions are ever going to be complete - there are going to be things you have to figure out. When we work as individuals or in small groups, we can handle all of these roles at the same time. Why is it different in the workplace?
A False Choice
For the moment, we’re going to assume that everyone is just trying to do a good job, and there’s evidence that this is a reasonable assumption. That leaves us to analyze the disconnect between what we want to do and what we actually do. A big part of it is that most of us only know how to work in two ways: command, which we just described and use for work, and consensus, which is more or less the only other way we make decisions. These are both good for certain things: think of a military expedition for a command model, or ordering pizza for a consensus model. But both of these break down when faced with a modern city. Let’s dig into why; first, let’s consider our alternative, consensus, and compare it to the command model.
Consensus is a way of doing things by group agreement. Anyone can propose an idea, people will hear them out and agree or disagree, and once everyone agrees the group puts the idea into action. This can work well if people understand and are considerate of each other, but it breaks down pretty much completely if there’s even one person who doesn’t get along. When consensus breaks down, we can call the way the group behaves chaos. The group loses its ability to respond as a group to its out of control elements, leaving each member of the group to respond as individuals. This should sound pretty familiar, because that is how many areas of our life run. Think of an out of control kindergarten, or a highway during rush hour, or most downtowns. The order that exists in these situations comes from individual members of the group making good decisions, not the coordinated or intentional activity of the group.
Because consensus breaks down into chaos, most people prefer a command model for important things, like delivering the mail or making sure your bank account doesn’t get hacked. But command has some pretty important drawbacks too. For one, most people don’t get to make many decisions. That means if you don’t have some kind of leadership role and things aren’t working out, your best bet is to complain and hope someone listens. Pretty quickly the complaints department is the largest department in the company. More importantly, when a small group is making decisions for everyone, that group tends to think of themselves first - again, not because they don’t care or want to do good things, but because of the inherent complexity of groups of people.
Let’s take a closer look at how command breaks down, because it should sound familiar. A small group of people is elected to make decisions for the group. Those people need to digest as much information as they can about the group, then make decisions - and often they’re making these decisions under a lot of pressure. Most of the group is not in the room where the decisions are made, and even if everything in that room is recorded, everyone else has other things to do, like putting those decisions into practice. The nature of the task, even if everything goes well, is complex.
Because of the complexity of the task, both the leaders and the group are going to have to take shortcuts when understanding the decisions that are made, and how they turn out. Because of this, leaders have a hard time understanding what the group is actually doing because they’re spending all their time making decisions, and workers and managers have a hard time understanding leadership’s decisions because they don’t have the same information. Even with the best intentions, the group becomes opaque.
If everyone is doing a really good job and this gradual falling apart of the groups into many smaller groups is still something that works well enough, the smaller groups that form will go through the same process. These groups end up competing against each other for the larger group’s resources and eventually for control of the group. This kind of competition can be useful and is sometimes encouraged, but more often than not it leads to disjointed or uncoordinated activity.
This process of decay has been well studied, and because we see it everywhere it’s tempting to think that it’s natural - that that’s just how large groups of people work. But the way things are is definitely not the way things have to be, because this isn’t always the case. We’ll look at an alternative next.
When you ask people which model they prefer, they often choose consensus, because it seems more fair. In theory, everyone gets a voice and everyone’s needs are taken into account. But because consensus requires trust and unity, when you have to work with people you don’t completely agree with, we fall back into a command mode by default, because that’s preferable to chaos. But there’s another way, and we’re going to call it composition.
The solution - composition
The way open source software is built overcomes these challenges in a way that is so satisfying, so empowering and uplifting that many people will do it for free. And I am completely convinced, given historical evidence, that the same could be true for cities. The point is not to try to build cities of volunteers, but to make participation in the process so rewarding that it reorganizes the way things work, as it has for software. The key, as I have hinted, is in participation.
For those just learning about open source, it can be baffling, because it goes against everything we thought we knew about how and why people work together. But a closer look shows that you already know why it works, and probably use it in your own life. Because I’m writing for a general audience, we’ll talk about the way groups of open source programmers work together first, and then I’ll mention some specific technologies that make it all work.
What is open source anyway?
If you have a smartphone, most likely the operating system on your phone is open source. What does that mean? First of all, it means that anyone can see the code that is running. Not just what the code looks like inside your computer, but the code as the developer sees it. This makes it easier for everyone to reason about what the code ends up actually doing and discuss changes in an informed way. Second, it means anyone can copy or modify the code. This takes a few different forms. If you want to modify your version of the software, there’s no way to stop you. If other people then want to use your modified version, they can add your modifications to their copy. There are sophisticated ways of combining many modifications so that the result is better than the original. Because of this, open source development is both efficient and transparent, because doing the work and communicating what you’re doing (and why) is the same thing.
Talk is cheap - Solutions not opinions
If you’ve ever been to a public meeting in your city, you know that people with lots of time on their hands love to share their opinions. For most of us, that and voting is as much as we can participate in running the city. But if you work for a city, you have a very different experience of public meetings. You know how difficult having a boss can be - try having a city full of them. It’s impossible to average out all the opinions of people in the city to come up with a policy that’s acceptable to everyone. In theory, this is why we vote. So how does open source do it differently?
Open source is built on changes - building, improving, or fixing things. There’s not even a conversation to be had if there’s not a change being discussed. Because computers run by themselves, programmers are laser focused on how they run, making sure they have the correct instructions. It’s literally impossible to micromanage a computer. They’re too fast, too complex - just like cities. Unless you’ve studied computer science it’s impossible for you to imagine how complex this can be. Compared to computers, cities are very slow and simple. So why do we get so much wrong about cities?
To blame it on human nature is both wrong and lazy. It makes much more sense to say that we are working with faulty instructions - bad code, as we say in the programming world. When you look at it this way, it’s easy to take a look at your city code and see improvements. Cities, like computers, for the most part are following instructions. Those instructions come from many different people with different goals and ideas - like computers. In computer networks, even with bad actors, people can work together very effectively. But cities get bogged down easily by gridlock. Maybe if we focused on fixing the code instead of trying to shout every specific outcome into existence, we could free up some resources to improve things.
That’s the first big difference in open source - the instructions are for anyone to use at any time! This flexibility really puts them to the test and shows where they do and don’t work. And that’s the next big difference - anyone can change the instructions or put them to the test. If some instructions don’t work, you are free to modify them! That doesn’t mean you can just do whatever you want - there are some important legal rules on the use of open source software that have been worked out over the years and lots of ways of keeping people honest. But as far as building, improving, and fixing them - all are welcome to contribute. That brings us to our next point:
Speak up, show up - Participation is decision making
In the open source world, complaining is of very limited value. In fact, on most open source projects, the idea of customer service is exactly backwards - if the software doesn’t work in your situation, you’re expected to contribute to the solution! Of course, you haven’t paid anything for it - or if you did, the company you’re paying to run the software for you is in the exact same situation you are. That doesn’t sound like a very good product at first glance, but keep in mind - this isn’t a product you’re using, it’s a process you get to participate in. And if the process or outcome isn’t what you want it to be, you are fully empowered to improve it! You don’t need anyone’s permission.
Of course, if you’re off on your own using bits and pieces of other people’s projects, that’s only useful for you. It really becomes powerful when groups of people find that they all have similar problems, or similar solutions to different problems. When these groups of people combine their solutions, those solutions become more valuable in a way that is unique. The idea that combining our resources or ideas leads to a sum greater than the parts is not new, but there’s something unique about combining instructions. Instructions can be composed in predictable ways. This is how software handles complexity. You no longer have to understand everything about the system - you can focus on the ways the pieces fit together. This might be a familiar principle to you from the hardware store, and indeed, you have scientists and engineers to thank for both situations. But products that fit together and processes that fit together are different sciences and require different skills and different ways of thinking about them and working with them.
So how does this relate to participation? Well, you might not have ever built a house but you’ve definitely fixed part of one, even if you didn’t own it - and this is the logic we can apply to cities. Of course, I’m not suggesting you go out and patch the potholes on the road in front of your house right away. But maybe if your city made it easier for you to help that happen, it might get done faster and better. Better yet, if you see the same pothole appear again and again, you’re probably in a better position to understand why than the road crews that keep getting sent to fix it. And this is where it all comes together - the people closest to the problem have the best information for fixing it.
Follow through - Decision making is participation
In a consensus or command model, the goal is to make the group act as one. This is fine for some tasks, but past a certain level of complexity, it doesn’t work. A large group of people like a city can’t possibly all be moving in the same direction with the same perspective, much less opinions. It’s self-defeating to try to get everyone on the same page when we have a way to make use of all our different perspectives. The real power of open source is that it allows us to act as many. This means that if there are different approaches to solving a problem, we can try all of them at the same time in different places and share our results.
Open source eliminates many debates by reducing the number of people needed to make decisions, similarly to command, but it reduces this number in a completely different way. Command puts the responsibility for decisions on the people distributing resources, like money and equipment. Composition puts the responsibility for decisions with the people doing the work. Let’s take a look at an example: fixing a pothole.
This is how it works in most cities: someone affected by the pothole calls the city to complain. That complaint gets filed and sent to someone in the department responsible for roads. That department reviews all the complaints filed in the city along with work they have planned and decides what’s most important for the work crews to do. Eventually the crews go out and do the work, but if that pothole doesn’t have urgent priority, it’s just going to get worse until it’s bad enough to need to be fixed. In the meanwhile, neighbors just have to live with the pothole. And unless there are crews out taking stock of the roads, which might happen once a year, every pothole in the city has to go through this process. If the road crew fixes the pothole but not the underlying problem, the whole process has to start over again when the pothole reappears.
An open source city might take a different approach: The neighbor sees a pothole and reports it in an app, which encourages them to add information such as photos. The app notices several other reports from the same intersection and shows photos, asking if it’s the same issue. These reports are combined and posted in a public database, and a group of people that live in the neighborhood reviews it. That group has been given control over the portion of the city budget for their street, and they decide how much they want to spend to fix it. They bundle it with other similar work and set a reasonable price to get the fix done. Once the price is set, notifications go to the neighbors that reported the issue, city crews, and local contractors that the work is ready to be done. Anyone who is able and ready can do the work. Once the work is done, a city inspector and a representative from the neighborhood group is notified to sign off that it was done safely and correctly. With their approval, the cost of doing the work gets paid out of the city budget. The reports, authorization, contract award, inspection results, approval, and payout are all public. With the help of open finance platforms like OpenCollective, many large software projects are already funded in this way.
When people doing the work are also deciding which work to do and what resources to commit, it radically simplifies the process of doing work. Rather than needing city meetings to schedule work, citizen groups and workers can set and change their own priorities. Rather than controlling costs implicitly by balancing workloads across the entire city, the city can use participatory budgeting to keep itself financially healthy, while allowing neighborhoods to focus on what matters to them. Rather than city planners having to study an area to understand its tradeoffs, the people that live there are empowered to make those decisions themselves.
Summary
Giving decision making power to the people doing the work changes what work gets done and how it gets done. It means less waiting and more doing. Open source techniques can keep everyone on the same page about the things that matter even if they’re working on different things and don’t talk to each other very much or at all. And if mistakes are made they’re much easier to correct because the whole story leading up to the mistake got written down. The most important part of open source is having clear instructions - that’s the source. As long as anyone can read, use, and change these instructions, we can build a city that works well for everyone even if their needs and wants are very different.
Specific solutions for cities
Let’s apply these principles to some of the processes that make cities run and see how it might change things.
From reporting to exposing - truly open data
Making changes to a city can be difficult if you don’t understand why things are the way they are in the first place. On top of that, when you set out to get answers to make improvements, you’re making more work for city staff - and information seeking is a low priority compared to all the other work they have to do. There’s an easy solution: make all city operating data public. Many cities hire an “open data team” that publishes information that citizens have asked for. I am proposing something more thorough. Whatever system the city uses to schedule and perform work should be public by default. Not just the data people ask for, the data the city uses day to day.
This accomplishes several goals at once. First, it drops the city’s open data costs to nothing. If the city’s open data is just data that the city is already using, there’s no need to maintain a separate system for publishing it. Like a library, it creates a self-service model for information about the city. This both takes a burden off of city staff and creates new business opportunities for helping people navigate the complexity of the city. It also makes it easier for departments within the city to work together, and it clearly shows the consequences of not working together, which might otherwise be hidden. Finally, it provides the complete story about what the city is trying to do and how effective it is. We should be asking why we are satisfied with anything less than the whole truth.
I know when I talk about data people are thinking of the kind of data that only experts can use. But this data is no more complicated than your maps app. If you can scan, zoom, search and select to learn about your city’s physical situation, you can do it with the organization of the city itself.
One cool and unexpected effect of open data is that it not only shows everything that’s there, it also shows what’s missing. When I did an open data investigation in my own city I immediately noticed what was missing or out of date. In my city, I can’t make those updates myself - I have to ask for someone to do it for me. That’s expensive. My city built an app to take citizen reports, but that app is made for people to request services. If a city wants to make the most of open data, they need to find a way to allow anyone to contribute.
Everyone gets paid fairly - open procurement
Fortunately, cities are already set up, on paper, to allow anyone to contribute. Most cities, and states for that matter, still have a place where they post everything they need - school buses, road maintenance, office paper - and in theory anyone can get paid to take care of these. In practice, it might look very different, and that’s our goal with this approach - to close the gap between theory and practice. While the contracts themselves may be available for anyone to view, awarding and performing the contract are considered the domain of specialists. With open source techniques, we can consolidate some of this work by making it open.
As an example, let’s consider landscaping. Typically this is a patchwork of people fixing their personal problems with next to no coordination, or all the work is done by one agency, such as a parks and rec department or HOA. Anything that falls between the two simply doesn’t get done. This is a similar problem to bugs in commercial software. If the problem affects the selling company’s bottom line, it will get fixed; if not, it’s unlikely. However, in open source software, anyone can report a bug and anyone can fix it. The role of the project maintainer is not to fix bugs but to verify and coordinate the fixes - a very different role! This also means that if people disagree on what the fix should be, they get to have that conversation before the fix is actually made, instead of having to undo work done incorrectly. With landscaping, this is even more important, because changes are impossible to undo. An open source landscaping approach is place based, with anyone making or suggesting changes going through a public change tracker.
Landscaping is a great example to use for this because landscaping companies don’t often live where they work. That means they’re not affected by the consequences of their work. If the people paying for landscaping also don’t live in the area, poorly managed or destructive landscaping practices can persist for generations. Change tracking can be a way to protect a place, and it can be a huge help with planning and budgeting, as we will see.
From participatory budgeting to voting with your tax dollars
As we discussed, we’ve avoided talking about finance because it can complicate things. Now we can explore what a city finance system that uses composition instead of command might look like. The Participatory Budgeting project is a great example of including neighbors in deciding how to spend their own tax dollars. In a Participatory Budgeting process, the city presents a neighborhood with a report showing how much money is available to be spent. Then the neighborhood is given choices about how to spend that money. Proposals are submitted and put to a vote, then the city uses the priorities given by the neighborhood to decide how to spend tax money. While this is a big step in the right direction, you might see how it’s not fully open. What would an open city finance system look like?
We can build on our discussion of open data to imagine extending open source to finance. First, all the money flows in the city would need to be part of an open data system. Individual data might need to be hidden for privacy reasons, but data down to the neighborhood level should be available. Many cities provide detailed spending reports already, but this system would need to be built into how the city actually makes and takes payments. This would make paying your tax bills easier!
However, simply exposing the existing flow of money in the city is just one kind of openness. As we’ve seen, the technique becomes really powerful when it allows anyone to participate. The biggest change would be to incorporate the ideas behind participatory budgeting into this open data system. While there are major civil rights problems with allowing individual citizens to decide how all their tax dollars are going to be spent, we’ve seen encouraging results around dollar voting.
As an easy example, imagine you pay $1000 to the city throughout the year. At the end of the year, the city presents you with a receipt showing all the different ways you’ve paid the city - fees, sales taxes, and property taxes. Next, the receipt shows how those dollars fund the city’s obligations, like debt and pensions - things that aren’t negotiable. Last, the receipt contains an order form, showing how much of your tax dollars are left over to fund other programs. Each is listed with a default amount next to it, and you either accept the default or fill out how much of your tax dollars you want to go to each program. If you don’t want to use all your tax dollars, they get refunded to you, and if you want to pay more, you can decide where those extra payments go. Just like with votes, individual choices should be private, but statistics and results must be public.
It’s well established that cities don’t spend according to their citizens’ preferences, and the excuse I hear from city officials is that preferences are inconsistent. Dollar voting turns that inconsistency into agility.
Open code
We’ve been working our way through the layers of the city. We started by looking at what cities do and how they do it, and now that we’ve talked about money we can finally start asking questions about why - or why not. We need to talk about code.
I know I’ve been comparing computer code to city activity, but there’s an important difference we need to talk about now. As we’ve said, computer code is a set of instructions that a computer that understands them will execute exactly. City code is very different - rather than instructions for making changes, it’s a set of rules for how things should be. While this is much easier to write, it’s also much harder to fix. This is where lack of trust comes into play. Because city code is written for city officials and not for just anyone, we have to trust that city officials are taking everything and everyone into account when they write the code - and as we’ve seen, that’s a logical impossibility. The things that go wrong aren’t in the code, they’re somewhere else, so it’s impossible to connect things that are going wrong to flaws in the code. That’s very nice for the people that are writing the code but not for the rest of us. If we want city code that works for everyone, it needs to be something anyone can read, use, and put to the test. That way it’s obvious when something isn’t working and anyone can come in and fix it. How can we do that?
Making the shift from rules to instructions is the first step. A very simple rule like minimum parking may create very complex instructions, and when that’s not in the code it can be a hidden problem for a long time. Creating a test process for code is another major change. Some cities have testing processes, but they’re a lot of extra work because it’s not built into the way that the code is developed. A consistent test and release process for code is the reason that software can be built very quickly, because problems can be caught on a small scale before they affect the whole system. Because software is so complex it can fail in big ways very fast, so software developers spend most of their time detecting and preventing problems instead of building new things. While that might seem frustrating, I think we would all be happy to see our cities trying new things out in a way that’s thoughtful, considerate, and cautious. Finally, applying the open contribution process we’ve talked about to the code of the city itself would unlock a vast untapped pool of talent while freeing up city resources to focus on getting it right instead of just getting it done.
Open planning
We’ve been talking a lot about day to day changes and a little about year to year changes. But what about very large long term changes, like airports, casinos, and stadiums? Does this approach work on that scale? You might be surprised to hear that not only is the answer yes, the process for planning these things looks a lot like what I’ve already described. The big difference between how they are done now and what I’m proposing has to do with how open the process is.
Right now, big projects tend to be issues that decide elections. When a candidate runs for city hall campaigning either for or against a big project, electing them or not is usually the only way ordinary citizens can affect that big project. Between elections, city hall can kind of do whatever they want. However, because these big projects are complex, city hall has to handle that complexity in a way that they don’t for day to day city operations like fixing potholes. The best techniques for handling complexity come from open source software, so things like open comments, open bidding, and community buy-in are already normal for these big projects. If anything, these projects might be the first place to apply open source to your city. How would that be different?
The big difference here has to do with how the project is planned. With a big project like a stadium, proposals are prepared behind closed doors, and citizens offer feedback. There might be several rounds of feedback, but at the end of the day it’s going to be an up or down vote on whether the project proceeds. An open source planning approach would have proposals come from the citizens. This is where the technique of composition really shines. Rather than citizens selecting from competing proposals, choosing the option that offends the fewest people, we can have everyone contributing what matters most to them. Sports fans might contribute most to the design of the stadium while environmental groups might find a way to incorporate transit and parks onto the site to reduce its impact or even make it beneficial. Having citizens participate in the tradeoffs of the planning process helps with eventual acceptance of the project and reduces waste and failure in the long term. The role of the city goes from paying experts for solutions to paying facilitators to help citizens work things out amongst themselves.
This approach also works beyond a single project at the district and citywide level. Master planning is always a huge project in itself, and cities struggle to engage citizens as much as necessary. The problem that they run into is they pay three times for it - once to gather ideas, again to figure out how to make them fit together, and again to actually put it into practice. Opening the planning process to ordinary people - not just in surveys and charrettes but on an ongoing basis - completely changes the process. This is where the value of the small scale open source projects in the city starts to compound. If citizens are already participating in day to day planning and operations in their neighborhoods, the city has all that open data and discussion to inform the big plan. The way things run now, the city has to go out and gather that information as a separate project every time it wants to update the master plan, which is why master plans tend to be obsolete as soon as they’re published.
A living master plan sounds like an impossible dream for most cities, but software projects with far more complexity can’t work without it. As cities evolve to become even more complex, it won’t be hard to imagine planning in this way - it will be hard to imagine planning in any other way.
An operating system for cities
As we come to a close I’d like to return to software to show you how big the wins we can achieve with this approach can be - I’d like to tell you, briefly, the story of Linux.
Linux is a type of software called an operating system. This kind of software is unique in one way: even though you use it all the time, you almost never see it. Like a city, an operating system manages the shared resources of your computer’s hardware. It provides a way for all the programs on your computer to share resources without having to work out every detail amongst themselves. As you can imagine, this job is very complex, and if it’s not done well, the whole computer is unusable. A good operating system is what makes computers useful to people who aren’t experts.
What makes Linux unique among operating systems is that it is open source. Anyone can modify it, anyone can share their modifications, and anyone can run it at no cost. Thousands of people around the world work on it for very different reasons, and because it doesn’t cost anything to run, people show their appreciation by sharing their improvements.
For several decades, Linux was only for experts. It was mostly used in factories and universities. Ordinary people would use Windows or MacOS because that’s what came with their computer. But when people started using smartphones, a group of Linux developers found that the parts of Linux that made it difficult for ordinary people actually made it perfect for smartphones. Specifically, Linux can be customized in ways that Windows and MacOS can’t. This meant that Linux could work in more situations and with more limitations. These developers started a project called Android to build a version of Linux that worked better on smartphones than anything else. Microsoft and Apple, the makers of Windows and MacOS, struggled to compete with the work of thousands of volunteers. The decisive moment came when Google, rather than creating its own operating system for smartphones, threw its weight behind Android, paying its developers to volunteer on the project. Google had experience with open source and knew that being part of the community by contributing was better for its business than trying to get people to pay for something they needed. Within four years, Android was running on most smartphones, a situation which continues to this day.
I see a similar possibility for cities. Since the Industrial Revolution cities have been dominated by the interests and opinions of a small group of wealthy individuals. We could say that most cities are running a post-industrial operating system, building factories, slums, office parks, strip malls, and suburbs. But the problems facing our cities have not changed since the 1970s. When you look at most cities you can see that the solutions that are out there haven’t even been tried, and that when non-experts propose new solutions the city is built to reject them since they don’t fit the existing code. Cities need a project like Linux, a new operating system that can adapt to each unique situation by welcoming the effort and creativity of everyone. Just like Linux, it can start very humbly, in universities and workplaces, but as it evolves it will come to benefit all of us.