[OSM-talk] OSM the mediocre alternative (was: don't like you etc.)

[Frederik Ramm]

Hi,

 > Wikipedia had to create their mediawiki software too. Wiki's are so
 > normal now that you can't even think about a web without them, but
 > when wikipedia started this wasn't the case. In the same sense we've
 > to develop our own software and compared to wikipedia, I think we've
 > got a more complex problem. I don't think that it's very hard to do,
 > but it will cost a lot of time to write. And I think that's a problem
 > at the moment, we need more developers with time to write that
 > software.

And we would also need a climate where such developers are actually 
encouraged to think ahead and design the software they want to write.

In is blog post at http://www.opengeodata.org/?p=198, Steve defends the 
simplicity - or naivety, as others might have it - of OSM, saying it was 
designed to be so, and that at the heart of the project there are not 
technical issues, but community issues.

I have mixed feelings about this.

As a programmer, I am frustrated with may aspects of OSM. Neither the 
data nor the software measure up to what I would like. I would like to 
write a renderer that can draw bridges properly, but for that I'd need a 
data model that supports this *and* the editor that allows people to 
actually feed that kind of information into OSM *and* I would also have 
to educate people to actually use that feature and not draw two distinct 
bridges (or no bridges at all, which is the most common way to deal with 
it).

I would like to write routing software that knows about turn 
restrictions, but for that I'd need a data model that supports this 
*and* the editor *and* people who actually enter the information...

Arguably the "people" part is the most difficult in all these 
situations. I can rewrite the ruby server and the major editors to 
support a new data model on my own in the space of a few weeks - there's 
not really that much code at the core of OSM. But never ever can I visit 
even a fraction of junctions already in our database and check them for 
turn restrictions!

So in a way, Steve is right, the community is the more important aspect.

On the other hand you won't attract capable programmers if the only use 
you have for their talent is writing workarounds and fixes for problems 
that arise from the technical simplicity of the core - the very same 
simplicity that may attract community members. It's like sitting in a 
ramshackle boat and saying: "Look, all the other stupid guys are still 
on shore building their mega ships, and we're already miles out! Ha! By 
the way, we'll need more capable seamen with buckets to get rid of the 
water in here..."

So maybe OSM is in fact destined to be the project that creates a lot of 
free data in a short amount of time and brings a lot of people into the 
fold of free geodata, and at some later time, one of the mega ships with 
ISO standards, headstrong design and hordes of programmers overtakes us, 
imports our data and lures our community away with faster servers and 
cooler features. But then again - while that could spell the end of OSM 
the project, we'd still have produced a lot of seed data for them to 
use, in the end helping the cause of free geodata a lot more than if we 
were just sitting idle and waiting for one of those mega ships to leave 
dry dock.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'