That's a bit like saying if you want Linux to be a success on servers, mobile phones, game consoles, routers etc. then you need to have a single distribution that they can all use.
Instead, there's room for Valve's SteamOS, Google's Android, Google's ChromeOS, Canonical's Ubuntu and many more, both commercial and community focused, competing in some ways, collaborating in others.
This announcement is one company that did exactly that, and provided a consumer-facing product built on OSM, who just got bought by a bigger producer of consumer-facing products who intend to do the same on an even bigger scale.
Not really. But Linux would not be what it is today if not for Red Hat historically and Ubuntu today. There needs to be a canonical (no pun intended) use case.
libpcap has tcpdump. linux has ubuntu. http has nginx (and previously, apache).
It would be great if there were a canonical frontend stack for OSM that we could all hack on to make as usable as Google Maps. It should be hosted somewhere central but also ship with easy chef or puppet configs to deploy a stack yourself easily.
I'd get tons of use out of something like that, and I'd contribute to the code, too.
Having used a few map services and utility libraries, I prefer that we aim towards more modular and distributed territory with geospatial technologies.
Monolithic engines are great for getting 80% of what your exact requirements are, then you're stuck with a bulky system that you're probably only using 10% of, and it doesn't do the other 10% of what you need.
Something like leaflet.js is nice because it gives you a simple way to present layers on a device, and it's modular meaning you can plug in extra behaviors or develop your own easily.
If a similar approach were taken for the other problem areas, like route finding, traffic monitoring, etc, I'd much prefer that over a bulky platform I'd never want to use the entirety of for any one project.
Of course once these modular components mature enough, no doubt soon, they will be packaged into some service that with a few simple clicks of a button generates the right combination to suit your requirement.
tl;dr OSM should do the data collation and serving and be good at that. Other services should spring up to do their magic with that data. And yet other services should provide easy ways to thread it altogether for a whole world of possible use-cases. (all IMHO of course...)
There are already several javascript libraries that use OSM tiles out there, most popular being OpenLayers[0] which offers an comprehensive API and Cloudmade's Leaflet[1]
I disagree. Wikipedia is a similar effort, and yet they have a highly polished look. I agree with the fact that OSM doesn't look as nice as GMaps, and I also agree that a better color/font scheme needs to be implemented if they want 7 billion users.
I don't know if I'd agree that Wikipedia has a highly polished look, but my point was more that you can have multiple polished looks, and it's actually easier to have a polished Linux for mobile phones and a seperate polished Linux for server usage (and so on), than to try to be all things to everyone. Wikipedia for example has multiple skins, multiple clients (including totally offline ones, similar to one of OSMs key differentiators).
And this article is the equivalent of say, Canonical taking Debian and saying they're going to make an easy to use desktop linux from it. It will almost certainly be more "polished" and end-user focused than openstreetmap.org, because they serve two different types of users.
Interestingly Wikipedia are actually a user facing front-end for OpenStreetmap data, in fact they have at least 4 projects using slightly different tech to put different front-ends on OSM as appropriate for their usage, e.g. the official Android app uses MapQuest OSM tiles to show articles that relate to your physical surroundings:
Again, not always what I'd call polished, but they're making creative use of map data, rather than putting some pins on Google Maps (or on an OSM based clone) and that's a good thing.
Instead, there's room for Valve's SteamOS, Google's Android, Google's ChromeOS, Canonical's Ubuntu and many more, both commercial and community focused, competing in some ways, collaborating in others.
This announcement is one company that did exactly that, and provided a consumer-facing product built on OSM, who just got bought by a bigger producer of consumer-facing products who intend to do the same on an even bigger scale.