There have been a couple of threads on OpenStreetMap’s mailing list this month to do with change. The first, entitled “Request for feedback: new building colours in openstreetmap-carto”, is all to do with a change to the way the default map style looks on openstreetmap.org. The second, “MEP – pipelines”, refers to a mechanical edit of the OpenStreetMap data. Both have been met with some level of resistance – but is this proportionate?
Change: For and Against
Failure to adapt and change can result in obsolescence and opens the door for new innovative competitors. The same is true for OpenStreetMap. We rely on an army of mappers to continue to contribute data and many of these mappers are motivated by the idea that the map data is being used and not just sitting idle. As our users’ needs change, so do our contributors’ – we are faced by a constant requirement to adapt. Fulfilling these requests for change in a timely manner is great for the long term success of OpenStreetMap.
Take tags for example: we don’t have a rigid set of tagging rules and as such contributors can come up with their own tags for new, never mapped before features. Over time preferred tags become more populous and gradually more contributors adapt to use the common tag – old tags may even get updated. If our contributors didn’t change then our data would be a miss-match of ‘stuff’ and would be difficult to add to and problematic for our end users.
But change is not always a good thing. Those same users who require us to adapt, are also likely to want us to provide a stable product. Our users have products and services that rely on our data and when we change something they may also need to update something on their side. As such unrequested change, or change with insufficient notice, may cause as much problems as a failure to adapt when desired.
“As OpenStreetMap matures the amount of prior notice of changes we will be expected to give will increase and we will be expected to announce planned changes to some of the smaller things”
Change in OpenStreetMap is often done in small evolutionary steps, however we’ve seen big changes too, such as the licence change and the introduction of new editing software. As OpenStreetMap matures the amount of prior notice of changes we will be expected to give will increase and we will be expected to announce planned changes to some of the smaller things, not just the big ones.
So lets look at the two changes currently being discussed on the mailing list.
Case 1: “Building colours in openstreetmap-carto”
This first change is to do with how the default map style on openstreetmap.org looks. It forms part of a larger piece of work to bring some standardisation to our default style. The changes come after a period of stagnation a few years ago during which it was often commented that our map style was a hotchpotch of colours, line styles and widths. The current changes bring standardisation and set the foundations for us to add new POIs (another often requested change). The general lightening of the style also makes it more suitable as a background layer to display overlaid data (again, often requested).
But who are the affected users? Well, OpenStreetMap is a data project – we create data and we distribute data – its right there on the wiki home page. The default map style, on the other hand, is provided as an additional extra: a bonus. We specifically limit the use of our default map through our ‘Tile Usage Policy’.
If you are an end user and are not happy with the change then you have an alternative. Simply grab our underlying data and render your own map using any style you wish. You could even use a previous openstreetmap.org default style!
Case 2: MEP – pipelines
This second change is a data change. It follows my example above where some work has been done to try to improve the tagging of a certain feature – in this case pipelines. The aim here is to create new use cases for our data. Although it hard to be certain, I would imagine that very few users are currently using our pipeline data. As such a notification of change, followed by a reasonable period of time for people to adapt is probably appropriate.
But was change even needed? Possibly yes – the aim is to improve both the quality and quantity of our data and to avoid potential conflicts with other tags. On the other hand, these conflicts are minor and most data users could work around them. So change may not be needed.
In this case I tend to look at the bigger picture. We have a group of contributors who are trying to help, and we probably don’t have many users of the pipeline data right now. If we block the change we won’t cause problems for our users (until they come to us and tell us that we’re not adapting to their needs!) but we risk putting a group of dedicated contributors off OpenStreetMap for good. In this case I believe the best solution is to support the change.
Your thoughts?
I’d love to hear your thoughts on this – where is OpenStreetMap in its maturity and what level of change is appropriate? Is there anything you would like to see changed? And is there anything that must stay the same?