I spent last year working on the iD 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 those efforts — enough to give you an idea of what their goals were — but most of this talk is about the human side, about community management and open source stewardship.
My hope for this talk is that sharing what worked for me and my collaborators will help three groups of people: first, open source contributors who, like me, want to help the project tackle big technical challenges. Second, other outside organizations — public or private — that want to engage effectively with the OSM community. And finally, members of the community who want to see OpenStreetMap become a more friendly and welcoming community for everyone who would like to contribute.
I work at Mapbox — Mapbox paid me to work on iD and on the website. So first I want to answer the question: why does Mapbox care about OpenStreetMap anyway? 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 only if the OpenStreetMap community has the tools, leadership, and community cohesion to produce geographic data which rival those of much bigger or better funded organizations.
It's important that those interests — the interests of Mapbox and of OSM — align in a certain way. The community is bigger than any one interest group — corporation, geographic region, language-based community. It’s very unlikely that one of these groups can win by trying to dominate the community, by trying to make changes unilaterally, or by forking the data and hoping people come over to their side. Several times in OSM’s history particular organizations or groups of people have tried to do that — how many times exactly depends on who you ask — but it has happened. Fortunately none of those efforts were successful.
But they did leave a mark, and I saw that when I first started getting involved, in 2012. I attended my first OpenStreetMap conference in October, in Portland. This was shortly after Mapbox announced a $575,000 grant from the Knight Foundation to work on OSM core infrastructure, and before I started working there. I went to a session at the conference called "Knight Foundation's Investment in OpenStreetMap", and what I remember about it 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 — engineers and designers at Mapbox and other interested community members — 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. The website had developed as many open source projects do, by slowly accreting features over time, and it had very little focused attention on design or information architecture.
In May we launched version one of iD, and it was made available as an editor choice on OSM.org. In July we kicked off our iterations on OSM.org design with a consolidation of the map controls for navigation, sharing, layers, and notes in the top right. Then we worked on a welcome landing page for new users, which explains the most essential points about the project. That shipped in August, followed by a redesign of the map sharing and permalink controls. And we made changes and additions that the community felt were essential to iD becoming the default editor, which it did in August.
What about September through November? Well, in September I went to the State of the Map International conference in the UK, and then took advantage of being there by spending several weeks cycle touring the country.
And then in October and November, this happened.
This is the GitHub pull request in which we redesigned the map pages on OpenStreetMap.org — the front page, the export and history pages, and pages that display individual features. 250+ commits, 33 participants, 121 comments, dozens of screenshots. I opened it on October 1st and it was merged on November 28th, and the redesign was live.
This is what collaboration in modern open source communities looks like.
"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]http://bit.ly/1kdBm9m) 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.
We prefer to keep what we currently have rather than risk what often seems like an uncertain tradeoff. Another way to look at this is that there’s a status quo bias, a preference for things as they are.
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 effective and welcoming 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 accomplishing change? Here are some of the most important things.
Work in the open. This is so ingrained in the way that Mapbox operates, that I almost didn’t think think to put in in these slides. But it’s incredibly important — kind of like the price of admission for working effectively in open source and with open data communities. If you want the trust and expertise of the community, then be transparent about your goals and motivations, and show your work.
Do that work incrementally, in small pieces. Remember loss aversion: when changes come in small pieces it’s easier for people to see that their potential losses are also 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.
Over-communicating is not the same as being 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.
"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. But 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 "better than what we have now".
And finally, be patient. Change in OSM always takes longer than I expect, but it does happen.
Well written. The stand out point for me is "Overcommunicate", something which can be hard in OpenStreetMap. We have so many communication channels and some will always get missed (and as we know, will result in a rush of comments on go-live).
I think communication is the next area for OSM to work on. Mailing Lists, IRC and GitHub are foreign to people who come from outside of the IT/Tech world. We need something more mainstream.