We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Implementing change in OpenStreetMap

00:00

Formal Metadata

Title
Implementing change in OpenStreetMap
Title of Series
Number of Parts
188
Author
License
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language
Producer
Production Year2014
Production PlacePortland, Oregon, United States of America

Content Metadata

Subject Area
Genre
Abstract
In 2013, I was involved in two substantial technical changes to OpenStreetMap: a new default editor and a redesign of the website. Because OpenStreetMap is a collaborative project, these were as much social as technical efforts. This talk will explore the social dynamics of collaborative open source projects and the techniques that helped us successfully implement technical change in a social environment that by nature tends to be change averse.
Keywords
Functional (mathematics)Data managementWebsite2 (number)Group actionLevel (video gaming)Self-organizationOpen sourceBitCollaborationismText editorOpen setProjective planeCuboid
Cohesion (computer science)CuboidLevel (video gaming)Set theoryPoint (geometry)MappingSelf-organizationComputer animation
MathematicsGroup actionFormal languageProjective planeMappingCuboidLevel (video gaming)Computer animation
CuboidGoodness of fitProjective planeCore dumpNumerical analysisFlow separationMeeting/Interview
Text editorStandard deviationRight angleDefault (computer science)Web 2.0System callComputer animation
WebsiteProjective planeComputer architectureFunctional (mathematics)InformationOpen sourceFocus (optics)Point (geometry)Multiplication signWordComputer animation
Landing pageGame controllerLevel (video gaming)Shared memoryText editorComputer configurationDefault (computer science)IterationPoint (geometry)Revision controlIntegrated development environmentWebsiteComputer animation
Point (geometry)Level (video gaming)Term (mathematics)MappingDefault (computer science)Game controllerAdditionText editorMathematicsShift operatorFeedbackShared memoryXMLComputer animation
State of matterCycle (graph theory)Level (video gaming)Moment (mathematics)Computer animation
Level (video gaming)Contrast (vision)Web pageOpen sourceLink (knot theory)CollaborationismWebsiteVideo gameLinear regressionComputer animation
Point (geometry)Decision theorySoftwareDependent and independent variablesSoftware developerIrrational numberTerm (mathematics)Insertion lossTheoryAreaGroup actionProjective planeCartesian coordinate systemLevel (video gaming)MathematicsBookmark (World Wide Web)Default (computer science)EmailMultiplication signCASE <Informatik>Process (computing)Perspective (visual)Task (computing)Direction (geometry)Scheduling (computing)AverageCuboidText editorVideo gameVector potentialWebsiteAngleMereologyView (database)Cycle (graph theory)Endliche ModelltheorieMUDShape (magazine)Revision control
MathematicsCompass (drafting)Video gameLink (knot theory)Moment (mathematics)1 (number)BuildingCompilation album
MathematicsInsertion lossCuboidBitOpen setPoint (geometry)FeedbackWaveOpen sourceBuildingInternetworkingWeb 2.0Mobile appService (economics)Bound stateSystem callMultiplicationSeries (mathematics)TheoryObject (grammar)Level (video gaming)Spherical capBlogMereologyMultiplication signComputer-assisted translationPixelFlow separationData conversionPerfect groupOnline helpProcess (computing)Set theoryType theoryAsymmetryEmailElectronic mailing listMessage passingDifferent (Kate Ryan album)Projective planeUltraviolet photoelectron spectroscopyDependent and independent variablesIterationSlide ruleModal logicSoftware testingTouchscreenThread (computing)Copyright infringementComputer animation
Transcript: English(auto-generated)
Hello, hello Thanks everyone for coming there's So many fantastic speakers Speaking this morning and right now, so I appreciate everyone coming to this talk in particular My name is John and I spent most of last year working on
the ID editor for OpenStreetMap and on the design and Functionality of the OpenStreetMap website OpenStreetMap org And I'm going to talk a little bit kind of at a high level about the technical side of those efforts Enough to give you an idea of what our motivations and goals are with them
But mostly this talk is about the human side about community management and open open source stewardship and my hope for this talk is that Sharing what worked for me and my collaborators will help a couple a few groups of people first
Open source contributors who? Like me want to help the projects that they're involved in tackle big technical challenges and second other outside organizations Could be public or private that want to engage effectively with open source communities
Finally individual community members Who want to see the? Projects that they're involved with become more Friendly and welcoming to everyone who would like to contribute
so I work at map box and Map box pay me to work on ID and OpenStreetMap website So first I want to answer the question of why they did that why does map box care about OpenStreetMap? Why would they pay someone to work on it? So the most fundamental reason is that the foundation of map box maps is OpenStreetMap data the roads the parks building
footprints Points of interest all of that comes straight from OpenStreetMap so Mapbox wins if and only if the OpenStreetMap community has tools and Community leadership and community cohesion
That Allows them to produce a geographic data set that can rival The data sets of much bigger or better funded organizations, so it's important that These interests the interests of map box and of a OpenStreetMap align in a certain way
The OpenStreetMap community is bigger than any one interest group whether that be a corporation or a geographic region or group of language a community United by a common language, so it's very unlikely that any one of those groups could
Win by trying to dominate the community by trying to make changes unilaterally or by forking The project and the data and hoping that the majority of the contributors come over to their side Depending on who you ask in the OpenStreetMap community
That may have been attempted once or twice in the project's history But fortunately none of those efforts were successful They they did leave a mark and I saw that when I first started getting involved in
contributing technical contributions to OpenStreetMap which was in 2012 almost exactly two years ago I attended my first OpenStreetMap conference here in Portland in this convention center and It was shortly after Mapbox had announced a grant from the Knight Foundation to work on OpenStreetMap core infrastructure and
It was before I started working at Mapbox and I went to the session I went to a session at the conference called Knight Foundation's investment in OpenStreetMap Which was a kind of a roundtable hosted by Several people at Mapbox
and what I remember about this session was that the mood in the room was kind of tense almost hostile and There were a good number of longtime community members there who were very concerned about the
Amount of money Mapbox was receiving and what they were going to do with it How that was going to affect the project? Fortunately the the session was productive and civil and what came out of it and many subsequent discussions in the months that followed was that
We the engineers and designers at Mapbox and other Community members who are interested in and joining with us should focus on two things The first thing that we focused on was building a new modern editor based on web standards
implemented in JavaScript and HTML and CSS and targeting first and foremost the needs of new and casual to mid-level contributors to OpenStreetMap and So we built an editor. It's called ID and
Right now it is the the default editor on OpenStreetMap if you sign up and dive right in And the second thing that we wanted to work on were improvements to the website So we wanted to focus on the experience for first-time visitors people that were new to the project
We wanted to consolidate some Duplication of functionality and we wanted to give the site a modern look and feel So it's it was a site that had developed as a lot of open source projects Do you buy kind of slowly accreting features over time?
without having a Point at which someone said stop and and give some focused attention on design or information architecture So this is what the website looked like In the end of the first half of
2013 before Our redesign efforts got underway and this is what it looks like Well, this is pretty much what it looks like now after the redesign work was completed so this is a brief timeline of the work that we did this is all 2013 dates in May we launched the
version 1.0 of ID and It was made available as an option as an editor on OpenStreetMap.org, but it wasn't the default editor at that point In July, we kicked off our design iterations on the website
starting with a consolidation of map controls for navigation and sharing and layers and notes putting those all in one place in the UI and We followed that up by working on a welcome landing page for new users it explains
The most important points about OpenStreetMap What's on the map? What isn't on the map some basic terms for mapping and the most essential points that shipped in August and then we worked on a redesign of the map sharing and permalink controls and
We made changes to the ID editor that Based on feedback from the 1.0 release the community felt there were some important additions to make before ID could become the default editor and
We made those and it became the default at the end of August So what about the rest of the year September through November? September I went to the state of map conference and The international conference in the UK and took advantage of being in the UK to do a bike tour afterwards
I love biking in the UK if you're interested in long-distance cycling go there. You'll have a lot of fun and After I got back This is what I was working on so this is the github pull request It looks like the contrast is a little high
But this is a github pull request in which we redesigned the map pages on OpenStreetMap.org the front page the history page export page And pages that display individual map features so probably a half a dozen main pages plus the main
navigational UI across the whole site And So this is 250 plus commits 100 sorry 33 participants 121 comments dozens of screenshots and links to other issues on github I Opened the pull request on the 1st of October and it was merged on the 28th of November
And the redesign was live on OpenStreetMap.org So this is what collaboration in modern open source communities looks like And after the the redesign landed I got an email from a long time
contributor to OpenStreetMap One of my favorite contributors Andy Allen who maintains the map style the default map style for OpenStreetMap and He wrote
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 tasks and so anything we can collectively learn to make this easier in the future is important and
So when I reflected on how to answer this question the first thing that I realized was that from the community's perspective The redesign work had been a much larger and more significant change than ID was even though To me ID was a much larger project from a technical perspective
So the answer to Andy's question Kind of became to take shape. Why was that the case? Why what were the challenges? that made the design changes harder than changing an editor and How are we able to successfully accomplish both of those?
So although ID was a larger engineering effort than the design changes It had an advantage and the advantages was that it was compartmentalizable and what I mean by that is We me and my colleagues at map box could work on it largely on our own schedule and
using our own processes and then slot it into OSM org and in an obvious place when it was finished Of course like most of our work at my box ID was developed in the open from the get-go
But because it was something that was brand new it enjoyed relative anonymity early in its life and I say enjoyed anonymity advisedly 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 Successful software has users and Having users is wonderful. It means that you've built something useful. Hopefully something that's a joy to use even but having an active users base also has costs primarily in terms of
Development agility and your ability to change the software in areas where it needs to advance or correct a shortcoming OpenStreetMap has millions of users The website is hard to change Why is that?
What is it exactly about having an established community that makes change difficult? I? Think one one of the big reasons is that humans especially groups of humans have Inherently conservative and tendency in a certain way We are loss-averse strongly preferring to
Avoid potential losses than to potentially make gains so loss aversion is a concept in behavioral economics that was developed in the early 1990s and One of the first experiments to look at it
Involved two groups of participants And in the first group every person was given a mug and they were told this is your mug you own it now And the people in the second group were were shown the mug, but they weren't given one They were shown the mug and and offer you know invited to look at it and then
Each of the groups was asked to name a price At which they would sell in the case of the first group or buy in the case of the second group that mug and the group of mug owners named an average selling price of five dollars and seventy eight cents and
The group of mug buyers named an average buying price of two dollars and twenty one cents so the group who had something wanted much more to part with it than the group of potential acquirers wanted to pay
So another way to look at loss aversion another angle to it is that You can look at it as a status quo bias a preference for a preference for things as they are Now we prefer to keep what we currently have Then to risk what seems like an often uncertain trade-off
now economists and decision theorists view loss aversion and Status quo bias as examples of irrational behavior irrational economic behavior but I kind of think that when it comes to software. They're actually rational learned responses maybe because
everyone knows of an example of software that went bad maybe it was a Tool that accumulated so many features that it collapsed under its own way or
An application that underwent a Redesign that aligned it with some kind of Shady corporate goals, but against the interests of its users so With examples like that in mind I try to respond to resistance to change in open-street-map with empathy
the project is really lucky to have a group of passionate community members who Perceive very clearly the reason that the project has succeeded and want to make sure that those reasons are not easily abandoned and That's not to say that they're always right or that they always have good ideas
About the direction the project should go I don't think that's true, but Their resistance. I think is rooted in legitimate concerns, which we can try to listen for So I was very heavily influenced by a talk last year
By Isaac schleuter Called bill building compassionate compassionate communities in tech This is given at no conk no comp EU I Have a link to the this talk at the end
And I recommend watching it. There's a point in in the talk where he stops and recommends a book And says if you get nothing else out of this talk Remember this book recommendation go read it It it could change your life So this is that moment in my talk if you get nothing else out of it go watch this one
Maybe it'll change your life So anyway back to the question What things did we do that made us successful in accomplishing change? So here are some of the most important ones work in the open
This this is a principle that's so ingrained in the way that map box operates that I almost didn't think to include it In the slides, but it's incredibly important. It's kind of like the price of admission to working with So to working effectively in an open source community or an open data community if you want the trust and expertise of
members of that community then be transparent about your goals and your motivations and Show your work and do that work incrementally in small pieces Working incrementally kind of acts like an antidote to loss aversion
because when changes come in small pieces, it's easier to see that the potential losses are correspondingly small or that there is no loss And often the gains are clear too with small changes, but even when they aren't like when Incremental changes have to build on each other to really pay off
It's easier to build trust Via a series of small changes than by one big omnibus change So the the redesign pull request that I showed earlier is way way way too big and it wouldn't have stood a chance if we hadn't
Built up a level of trust with the community by all the smaller changes that preceded it Over communicate clearly explain The objectives and the benefits of the change that you're proposing in multiple venues and at multiple points in time
so for our work on OpenStreetMap, we Blogged about it on the Mapbox blog. We had a separate OSM dev blog Exclusively for that work. We gave four conference talks We attended multiple birds-of-a-feather sessions and many in-person conversations and private emails
mailing list threads, GitHub pull requests, OSM diaries, IRC all these things Over communicating isn't the same thing as being verbose. In fact, simpler explanations are almost always better The reason to over communicate is that there's an inherent
Asymmetry of knowledge between you who are intimately immersed in a project and the larger community So what you've been involved in this thing from the the very inception But everyone else is hearing about it at a different place in time so make sure your message is there for them when they do hear about it and
Most people just need a little bit of But a little bit of reassurance at that point that the reasons that motivate you are also meaningful for them Over communicating helps
avoid a phenomenon Called why wasn't I consulted and this goes back to an essay by Paul Ford called the web as a customer service medium and One of the things he writes in this essay is this 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 didn't use dot caps lamp sheets or pixel scrims It is not risk written in rasp or skull my cat is displeased
The ultimate question lurks beneath these curses. Why wasn't I consulted? So communicating early and often Lets people feel consulted some of them will give you great feedback. Some of them won't that's okay The point is many of them
Who might have felt? Might have been part of an angry mob if they felt unconsulted will Leave thinking I'm okay with this Be polite always be polite thank people for their feedback and
Give it genuine consideration Regardless of the tone they use if you disagree with them politely explain your reasons if their tone is Really offensive and you need to ignore a conversation until you can give a patient And courteous or reply do that
Don't Feel obligated to respond to obvious trolls or to people that are consistently negative I Found that most of the time those type of people do a very effective job at marginalizing themselves without your help
Set bounds Actively each try to define what you are Trying to accomplish with a particular change and what you consider to be off-topic For the given conversation, so I found that a lot of the discussions about changes or new features
Involved Feedback that was was like 50% Suggestions that fell outside of the bounds of what I was trying to accomplish and that's fine I just responded with a variant of that sounds like a good idea, but it's more than we're trying to
Accomplish with this change and those also are good opportunities to Over communicate to reiterate what your your goals are call for cloture This is this is to one thing that's true in open-stream app I'm sure it's true in a lot of open source communities is that debates will go on forever if you let them
So don't let them It's often said that OSM is a duocracy and I think that applies just as much to Finishing changes as to initiating them so one thing that I would do is at a certain point I
Thank everyone for their feedback reiterate what the goals are and the benefits that the change introduces and remind people that Perfect is the enemy of much better than what we have right now and finally be patient
Change in open source always takes longer than I expect, but it does happen Thank you