osm.gryph.de

The Ostrich Principle

Let me get one thing out of the way: Ostriches don’t really do this. They do not bury their heads in the sand, hoping that whatever it is that causes them unease will just go away.

Clever animals.

But in this post, I will show how in some respects the OSM project as a whole tends to do exactly that.

These thoughts were first posted on the mailing list (titled “looking forward”) on Christmas day 2011. The post was prompted largely by the publication of a list of “top ten tasks”, technical things that our admin team would like to see implemented sooner rather than later. Most of it makes perfect sense to me. But looking at that list, one thinks: If those are the biggest problems facing OSM then the project must be working quite well!

The truth is, nobody claimed that these are the biggest problems. They are just the lowest hanging fruit, those with a straightforward technical solution.

When it comes to big issues in OSM, things that affect a majority of people working on or with OSM, I can identify two groups that have the potential to drive change. One of them is the OSM Foundation – tasked with “supporting but not controlling” the project, but nonetheless ultimately in charge of running the servers and owning domain names and trademarks -, and the other is the core of the technical community, i.e. those who make the API code and the major editors. The latest major decision to come out of the OSM Foundation is of course the license change; the latest major decision taken by the technical community is probably the API and, related, the details of the data model we’re using.

The OSM Foundation board are very much concerned with making sure that OSM user experience is improved and that it becomes easier for everybody to contribute to OSM, shedding our image of being a project for geeks and enthusiasts. I’ve contested that idea in the past because I believe it’s too early for that, but I’ll save that for another post. The underlying idea with OSMF board seems to be that of any web startup: Once we achieve growth, everything else will fall into place. And who’s to blame them – it has worked for OSM for quite a while.

Among the more technically-minded people in OSM, the making of big plans is often, somewhat cynically, frowned upon as “astronautism”. Again that’s understandable; I have personally witnessed OSM attracting a fair number of people who think that even without any OSM experience, they know just the right cloud no-sql web scale message queue technology that we absolutely have to use to avoid meltdown. I’m probably guilty of several counts of astronautism myself, starting with suggesting a new data model for OSM five years ago, not long after having joined the project.

Another typical response you’ll get from the technical community when you choose to let them partake of your superior wisdom is “working code or STFU” (trans: “We really appreciate your suggestions but they would make an even greater impact if you could bother to provide an implementation of your ideas that we could test.”) – That, too, is a perfectly pragmatic reaction because these people simply don’t have the time to code a prototype for every idea thrown at them even if it looks worth pursuing. But at the same time the hurdle of actually creating a working implementation of, say, a new API and matching editor, is certainly not something that a single person can do on the side.

All this together means that most people in OSM are more or less sticking their heads in the sand when it comes to the real big issues – issues for which we not only lack a solution, but where it is even unclear how we could arrive at one and implement it. Even though the project has myriad communication channels for its members, we seem to lack either the willingness or the tools to form and implement a “community opinion”. Neither does the OSMF have a mandate to rule the project, nor can we simply call for a vote (who decides what is voted on, and who gets to vote anway?). We say that we’re a doocracy – those who do the work get to decide how it is done. But of course that’s only a half-truth, since everyone who “does something” operates within an unwritten envelope of acceptable actions. Try to single-handedly implement a new data model and we’ll see how doocracy works out for you!

But what are those big issues of which I’m talking? I’ll get to them in the posts to follow.