Thanks Mike for inviting me to talk here. I spent nearly all of last year working upstairs in this office, and until recently, I was the only San Francisco Mapbox employee -- most of the team is in DC. Having the fellows and incubators around made what could have been an isolating experience vibrant and interesting. So I'm grateful for the opportunity to talk about what I did last year and what I learned doing it.
I spent last year working on an editor for OpenStreetMap and on the design and functionality of OpenStreetMap.org. I'm going to talk a little bit and at a high level about the technical side of it -- enough to give you an idea of what our goals were -- but most of this talk is about the human side, about community management and open source stewardship.
And I'm talking about my experiences working with and in the OpenStreetMap community specifically, but hopefully in a general enough way that you can see how they could apply to other communities -- be they other open source projects, or civic communities, or local governments.
So why does Mapbox care about OpenStreetMap in the first place? Why would they pay someone to work on it? Well, the foundation of Mapbox maps is OpenStreetMap data. The roads, and parks and building footprints and points of interest come straight from OpenStreetMap. So Mapbox wins if the OpenStreetMap community has the tools, leadership, and community cohesion to produce geographic data which rival those of corporations like Google and Apple.
It's important that those interests align in a certain way. The community is bigger than any one interest group -- corporate, regional, language group. We can't win by trying to dominate the community, by trying to make changes unilaterally, or by forking the data and hoping people come over to our side. There was a company early on in the history of OpenStreetMap who -- in the eyes of some community members -- did try to do those things, and failed.
And, I saw the lingering effects that had on the community when I first started getting involved, in 2012. I attended my first OpenStreetMap conference in October, in Portland. Shortly after they announced a grant from the Knight Foundation to work on OSM core infrastructure. There was a session at the conference called "Knight Foundation's Investment in OpenStreetMap", and what I remember about it -- this was before I joined Mapbox -- was the tense, almost hostile mood. There were many long-time community members who were very concerned about what Mapbox was going to do, and how this influx of outside money was going to affect the project.
Fortunately, it was a productive and civil discussion, and what came out of it, and many other subsequent ones, was that we should focus on two things:
-
Building a new, modern editor, based on web standards, and targeting first and foremost the needs of new and casual contributors. The editor we built is called iD, it's built entirely in JavaScript and HTML and CSS and is embedded directly in the OSM website.
-
Improvements to the website -- focusing on improving the experience for first time visitors and people who were new to OSM, consolidating some duplication of functionality, and giving the site a modern look and feel. It had never had focused attention from a professional designer.
-
Timelines
-
Monster pull request
Final redesign: November.
Andy Alan's question:
"If you have any suggestions or experiences about the whole process to share, I'd like to hear them. Making large, or even medium-sized changes to OSM becomes an almost herculean task, and so anything we can collectively learn to make this easier in the future is important."
When I reflected on how to answer this, the first thing that I realized was that from the community's perspective, the redesign was in many ways a larger and more significant change than iD was, even though iD was a much larger project technically. So the answer to Andy's question began to take shape: why was that the case, what were the challenges that made changing the design harder than changing the editor, and how were we able to successfully accomplish both?
iD was, like I said, a larger engineering effort than all of the design changes put together, but it had the significant advantage of being compartmentalizable. We could work on it largely on our own schedule and using our own processes, and then slot it in to OSM.org when done. Of course like much of our work, iD was developed in the open from the get go, but because it was brand new, it enjoyed relative anonymity early in its life.
I say "enjoyed anonymity" because software without users is the easiest software to change. It's more malleable than it will be at any other point in its lifecycle, especially after it becomes successful and enjoys the benefits -- but also the costs -- of an active user base.
OpenStreetMap.org has millions of users. It's hard to change. One reason for this is that humans, and especially groups of humans, tend to be inherently conservative. We are loss averse, strongly preferring the avoidance of losses to the aquisition of gains.
One of the first experiments to look at loss aversion involved two groups of participants. Each person in the first group was given a mug, and told that it was now theirs to keep. The people in the second group were merely shown the mug and invited to inspect it. And then each group was asked to name a price at which they would sell or buy the mug. The mug owners named an average selling price of $5.78, and the mug buyers were willing pay $2.21. So the people who had something wanted much more to part with it than the potential acquirers wanted to pay.
Loss aversion contributes to status quo bias, a preference for things as they are. We prefer to keep what we currently have rather than risk what often seems like an uncertain tradeoff.
Economists and decision theorists view loss aversion and status quo bias as irrational. But I think that when it comes to software, they may actually be rational, learned responses. We've all seen software that went bad, either accumulating feature bloat to the point where it collapses under its own weight, or undergoing a misguided redesign that aligns a product with corporate goals but against user interests.
With those examples in mind, I try to respond to resistance to change in OSM with empathy. We are lucky to have passionate community members who perceive the reasons that OSM has succeeded, and want to make sure that those reasons are not easily abandoned. This is not to say that they are always right, or always have good ideas about the direction the project should go -- far from it -- but their resistance is often rooted in legitimate concerns which we can listen for.
For more on the importance of listening and empathy in building workable open source communities, I highly recommend Isaac Schlueter's talk on Compassionate Communities in Tech.
Anyway back to the question. What things did we do that made us successful in being able to accomplish change? Here are some of the most important things.
Work incrementally. Small changes are easier to digest; it's easier for people to see that their potential losses are correspondingly small (or that there is no loss). Often the gains are clearer too, but even when they aren't (like when incremental changes need to build on each other to be fully realized), it's easier to build trust via a series of small incremental changes than one larger change. Our redesign pull request is far too big. It would have never stood a chance if we didn't have trust built up from the smaller changes that preceded it.
Overcommunicate. Clearly explain the objectives and benefits of the change, in multiple venues and at multiple points in time.
Mapbox blog, separate OSM devblog, four conference talks, multiple birds of a feather sessions, many in person conversations and private emails, mailing list threads, GitHub pull requests, OSM diaries, IRC.
You don't necessarily have to be verbose; in fact simpler explanations are usually better. The point is that while you've been involved with the change from the inception, everyone else hears about it at a different time and place. Most of them just need a little bit of reassurance that the reasons that motivate you are also meaningful to them.
- Why wasn't I consulted?
Paul Ford.
"Brace yourself for the initial angry wave of criticism: How dare you, I hate it, it's ugly, you're stupid. The Internet runs on knee-jerk reactions. People will test your work against their pet theories: It is not free, and thus has no value; it lacks community features; I can't believe you don't use dotcaps, lampsheets, or pixel scrims; it is not written in Rusp or Erskell; my cat is displeased. The ultimate question lurks beneath these curses: why wasn't I consulted?"
Communicating early and often lets people feel like they are being consulted. Some of them will give you great feedback. Some of them won't. And many of them, who might have been part of the angry mob if they felt unconsulted, will think "I'm OK with this."
Be polite. Always. Thank people for their feedback and give it genuine consideration. If you disagree, politely explain your reasons. If you need to, ignore a conversation until you can give a patient and courteous reply. Don't feel obligated to respond at all to obvious trolls or those that are consistently negative; they will effectively marginalize themselves without your help.
Set bounds. Actively define what you are not trying to accomplish with a particular change and what you consider to be off topic for the given conversation. Something like 50% of feedback will be suggestions that fall outside these bounds. That's fine, just respond with variants of "sounds like a good idea, but that's more than we are trying to accomplish with this change" (and maybe use it as an opportunity to overcommunicate what the goals are).
Call for cloture. Debates in OSM will go on forever if you let them. Don't. OSM is a do-ocracy, and this applies just as much to finishing change as to initiating it. At a certain point, thank everyone for their feedback, reiterate what your goals are and the benefits that the change introduces, and remind folks that perfect is the enemy of "much, much better than what we have now".
And finally, be patient. Change in OSM always takes longer than I expect (even taking into account Hofstadter's Law, but it does happen.