Comparison Google services – OSM
First of all we must remind ourselves of the fundamental difference between OpenStreetMap and Google Maps, open access to raw underlying map data.
OpenStreetMap is an open data project. We release maps in their most raw form, free of charge, with an open license. The raw underlying data which makes up a map, is known as "vector" data. The coordinate positions of roads, classifications of linear and point features, known as Elements.
This is extremely powerful. Developers in large corporations, in universities, and in bedrooms are offering a exploding range of exciting products, services, and experiments which would simply not be possible without access to raw map data.
Google Maps is not open at the level of raw map data. Google, much like other data owners, keeps this locked away, in order to maintain a commercial advantage, while exposing only downstream products and services generated from the raw map data. They also protect their rights to the underlying map data with various copyright and terms of use restrictions.
There is a tendency, even among technical developer communities, to focus on downstream map services (particularly the rendered view of the map) as such, Google Maps is widely regarded as a very open mapping platform, but there is a growing realization that raw map data, and the ability to download the entire map can unleash a new wave of innovation not possible on Google's restricted platform. That is the point of OpenStreetMap.
Nonetheless, downstream services are important, particularly if a massive XML file is of no interest to you. OpenStreetMap has downstream services echoing many of those seen within google's offerings. Some are provided on "core" OpenStreetMap Foundation-funded servers, however, most are provided by third parties as part of a growing ecosystem. There are also many exciting and innovative map related services which have no parallel within Google's offerings.
The view of the map is a "downstream" service
The view of the map is a "downstream service". The map is generated through a process called rendering which is a one-way conversion, "vector" to "raster". Various style choices are baked into the image and it is chopped up into many square images called tiles, which are then served as a tiled map service out to the web and to mobile devices. This is the case in both OpenStreetMap and Google Maps.
You can make a direct comparison between Google's tile service and OpenStreetMap's tile service. OpenStreetMap's default map style is quite similar to Google's. Previously, it was based on UK mapping conventions which was quite similar to ordnance surveys. It shows some interesting features exhibiting our unique data set, rich with locally gathered information in some areas. Some find the style too cluttered. In fact, it's designed this way (at least partly) to show and encourage contributions from mappers. Our tile server (a single machine in a cupboard) renders map tiles on-the-fly, allowing contributors to see their changes on the final map within minutes, more often than any proprietary map service. This is quite a technical feat, and something you don't get when contributing to Google. Meanwhile, Google's tile service runs on many powerful servers in worldwide distributed data centres. Although we do benefit from a fast university internet connection, thanks to UCL and Imperial College, perhaps we're not going to out-do Google in terms of server horsepower any time soon. This might mean that our tile service is a little slower than Google's. See if you can notice the difference. It's not very noticeable most of the time). However, all of this is missing the point...
An alternative slowly being developed in the OSM community is to have others building alternate renderers and tile servers, with alternate styles too, and the freedom to any one, including organizations, to build their own tile server fast enough for their need; commercial tiles servers are also being developed with success without depending on the limited resources offered by the Foundation for OSM mappers' work. For the long term, the performance problem will be less sensitive if major users of these maps do play the OSM game fairly, and OSM helps them creating and maintaining their servers and the needed open software to run it; OSM is much less a map provider than a data agregator and a community where everyone can contribute instantly and get immediate returns that can fit what they need. Providing visual maps is an accessory (but not required) goal of the project in order to attract new contributors and allow more people to participate, even those individuals that cannot create their own server or need access from their small mobile devices, but still have some local data and knowledge, to share and feed into the global database.
The view of the map is a "downstream service" built on the underlying data. In the case of Google there is no reason you would be aware of this. The underlying data is hidden away. A closed-data system. In the case of OpenStreetMap, anyone and everyone has access to the underlying data, and anyone can run their own rendering and tile serving systems using free open source rendering software. In truth, running a popular worldwide on-the-fly rendering service will require a powerful server and fat bandwidth. This may not interest you if you just want to view a map, until you consider the nature of the open data ecosystem that OpenStreetMap is creating. There are an increasing number of other providers all running their own tile services and configuring custom rendering styles. See for example MapQuest OSM tiles, thunderforest.com, and MapBox. There's nothing unique about the "main" OpenStreetMap tile server. Although we are offering a tile service... it's not really the point.
Other downstream services
Google offers a raft of other services nicely bundled up as part of "Google Maps". Very slick. Very tidy. Very corporate. All of these stem from Google's underlying geodata. Did we mention that this is kept closed?
OpenStreetMap gives developers access to the data. In particular, it offers all data as a single Planet.osm download, and Planet.osm/diffs allow a tool to keep in sync with changes to the map every minute. It is usually these facilities which get used by developers. OpenStreetMap has a rich and varied (and perhaps a little confusing) developer ecosystem, with involvement from students and bedroom coders alongside companies large and small. All of their creations can be thought of as "downstream services" sprouting forth from the open data. Among these are some services which have parallels in the Google Maps arena. For example, an open source developer created a tool named Nominatim which consumes raw open data and provides search functionality. The open development and running of this service is now funded by a company, Mapquest, and it is this which powers the search box on the OpenStreetMap homepage. How does Nominatim search compare with Google Maps search? Try it for yourself, but remember... it's not really the point.
The point is, OpenStreetMap is open in ways Google Maps will never be. With access to the raw data, the developer ecosystem (particularly with the help of some forward thinking companies) can start to offer services matching those of Google, or perhaps more interestingly, services like Overpass API which present filtered map data in a way which Google never will.