<div dir="ltr"><div>In system management, success is reaching the next bottle neck.  My take away from Alex's concern is "What is the next bottle neck for OSM to focus on?"  We can already see some of the great successes that MapBox has created from the ideas used to make a slippy map.  I am so thankful for the whole idea of mbtiles.  What a wonderful idea.  I am so thankful for TileMill.  I show people TillMill and how they can use it to get into GIS with a limited budget. These people can save a ton of cash and learn the same important concepts behind GIS without more expensive tools.  However, I don't believe that the license is the next bottleneck.  The next bottleneck to face is something more like creating the iD editor.<br>

</div>
<div><br></div><div>I've just described the gift culture of the open source/data world. My dentist doesn't get it.  He thinks that I should make as much money as I can.  Why are you giving this away?  MapBox has gifted us some great things.  Part of my gift back is to use a project or tell other people about these gifts.  Corporations don't always get this idea.  We can look to the recent example of Oracle Corporation and the Jenkins/Hudson controversy.  In short, Oracle wanted to take complete control of the open source Hudson project.  The rift was so bad that Jenkins was forked out of Hudson so that the project could continue.   In a perfect world, I'd say Alex, let's change the license so that we can share things better with one another.  However, I can't.  Others don't understand that gift culture like you and I do.  From all bad things that I've seen, I wouldn't license the data under any other license than ODbl.</div>


<div><br></div><div>ODbl isn't the only license that causes legal heartburn.  I've transcribed part of Dr Richard Hipp's Google Tec talk, <a href="http://www.youtube.com/watch?v=giAMt8Tj-84#t=1703" target="_blank">http://www.youtube.com/watch?v=giAMt8Tj-84#t=1703</a>, concerning his experience with the public domain license:</div>


<div>"Observations from running the project...SQLite is in the Public Domain. I've learned over these six years that this is not necessarily a good thing from the point of the people who use it. I thought that when I was going to release SQLite source code into the public domain that this would make it easier for people to use it.  But big company engineers want to use it in a product.  The engineers talk to the lawyers.  The lawyers see the public domain and they panic. Oh what do we do?  We know how to deal with the GPL.  We know how to deal with the MIT license or the Berkley license.  People tell me that there is no public domain in Europe.  This is purely an American concept.  I have generated an enormous amount of billing for corporate lawyers by placing this in the public domain.  One company in Europe was not willing to accept that this was in the public domain. So they paid a small token fee to me and the other developers.  They made us sign professional use licenses so that they would be covered.  So I don't have an alternative what could be better. I think that this is a political thing.  It surprised me how difficult it would be to use public domain software." </div>


<div><br></div><div>Alex states a great ideal with, "Ideally the government of New York City would just copy changes from OpenStreetMap to help maintain their own datasets - but they can't. Many datasets managed by government behind closed doors today should just be managed by the same maintainers on OpenStreetMap tomorrow - with gains for everyone".  One of the problems with the OSM database is that there is no guarantee of a permanent primary key.  If I need to split a building, the original primary key does not stay with one of the two pieces of the building.  Two new buildings are created with two new primary keys.  I don't know of a way to bridge two systems when you lose a primary key.  One way would be to store the primary key in with the OSM data.  I believe this kind-of "meta" data is frowned on in the community.  The meta data that would be required for joint maintenance can always be deleted. A license change will not solve the government sharing problem.  They have to find a way to jump in with both feet.</div>


<div><br></div><div>Next problem with this ideal is that OSM cannot guarantee the integrity of the data once it has been placed into the OSM database.  I started to map pedestrian crossings. I am OK that a crossing is not rendered at this time because I use a node for a crossing, a node for a traffic light, and another crossing node to help line up intersections.  I also thought that it would be a great way to sell governments on the use of this kind-of data to maintain their annual restriping of crosswalks.  A new mapper comes along and starts deleting the crossing data because cartographers have not rendered the data.  The data were/are considered map clutter.  I guess the reason is that if I cannot see the data rendered, then why do I have to plow through it in an editor?</div>


<div><br></div><div>Next problem with this ideal is tagging mistakes. The idea of iD editor was to bring in new editors.  Invariably, mistakes are made.  I thanked a mapper for his contributions in the metro Phoenix area.  Recently, I've seen chunks of road disappear. Well come to find out that an extensive part of his work was rolled back because he changed the highway value to something else.  I thought the changes in the Phoenix area were OK and welcomed his help in an actual thank you note.  The same view must not have been seen the same in other areas of the US.  The missing data from the rollback reminded me of what happened during the license change to ODbl.  There were lot's of nodes no longer connected to ways.  The community needs to be more welcoming in these cases than rolling back the data.  If we want to encourage new mappers, then how to we do a better job guiding the new mappers along?  A physical meetup model isn't always possible.  The new mappers will more than likely be armchair mappers.  Licensing has nothing to do with the new mapper problem.  Unwelcoming articles like the Armchair Mapping page are not the solution either <a href="http://wiki.openstreetmap.org/wiki/Armchair_mapping" target="_blank">http://wiki.openstreetmap.org/wiki/Armchair_mapping</a>.  There are areas of Phoenix I will not survey for safety reasons.</div>


<div><br></div><div>ARNOLD, <a href="http://www.fhwa.dot.gov/policyinformation/hpms/arnold.cfm" target="_blank">http://www.fhwa.dot.gov/policyinformation/hpms/arnold.cfm</a>, would be a perfect use case for Alex' ideal. I had an interesting talk with an individual involved with the State of Arizona's compliance.  License issues were not even a concern.  The state decided to use all of the municipalities 911 data for the road network over both TIGER and OSM data.  The governor of each state has to sign off on the report. Imagine the governor signing off on OSM data where data has been deleted because it is map clutter or changes being rolled back because of highway values being changed.  The state's project knew all about both TIGER and OSM data availability.  The license question did not enter the discussion.  The concern was what the governor would have to signon.</div>


<div><br></div><div>OSM is a unique project. OSM is even more unique that, say, Wikipedia that also has a database.  In other projects, the gift culture of contributions are split over forums, mailing lists, bug trackers, testing, build systems, and the most important piece of the project is the code.  A "normal open source" project  has no real easy way to aggregate all of these contributions together like what can be done with OSM data.  The very nature of a database login means that you can track it all.   Don't get me wrong here but the OSM source code is not as important to the project as it is to other projects. </div>


<div><br></div><div>My opinion is that many OSMers having been reading the OSM data wrong for years.  All projects have attrition.  All the projects have lurkers.  In the case of OSM, a lurker might be an OSM account that has not contributed a change set to the database. Other projects struggle with losing mind share to other projects or how to get the lurkers to contribute.  The recent iD editor has been another attempt to get the OSM lurkers out of the corners or attract new contributors.  Pascal Neis has a wonderful summary of how well that solution has paid off by looking at each mapper's editor use.  We can quantify lurkers and top contributors with the OSM database as well as map the world.  I have no problem with the attrition rate or the lurkers.  These attributes are part of an open source project. 30,000 active contributors is a great number.  As for lurkers in any project, it takes guts to make the first public contribution.  Some contributors fear making a mistake more than others.  In the case of OSM, my fear of making a mistake on the data was irrespective of if the data was imported, armchair mapped, GPSed, surveyed or what not.   I tell new mappers don't fear the edit.  There's always OSM Inspector or KeepRight to help correct any mistakes later.</div>


<div><br></div><div>And now for something completely different: It's the cartographers that are limiting the project adoption and burnout rate for contributors.   Here's your next bottle neck to work on.</div><div>


<br></div><div>I understand how difficult it is to render the world.  However, I consider that the current method of data distribution and the rendering chain is broken.  I don't have a better solution yet but here's a problem that is right in MapBox's wheel house that can be fixed without a costly and damaging license change. When Alex says, "OpenStreetMap's purpose is to democratize who decides what's on the map" that's not true based on what is actually rendered.  It is an oligarchy of cartographers that determine what is on the map and not the democracy of what the mappers have placed in the database.</div>


<div><br></div><div>Vector tiles are not the solution if the resulting tiles are the just more of the same minimalist map tiles.  We need a real mapper's map again.  We need tiles that are so butt ugly only a mother would hang the project tiles on her fridge because that's what little Johnny did in school today.  The type of butt ugly tiles I am talking about are something like Tiles@Home, <a href="http://wiki.openstreetmap.org/wiki/Tiles@Home" target="_blank">http://wiki.openstreetmap.org/wiki/Tiles@Home</a>.  The magic of T@H was that I was rewarded as a young mapper.  It was magic when I saw the first traffic=hump that I added to the database show up on the map.  From there, it was an Easter egg hunt to find traffic calming humps as I could while I fixed tiger data. </div>


<div><br></div><div>The cartographers are creating beautiful maps. I show people MapBox maps, Stamin Design, or Andy Allen's work.  However all these are just minimalist maps that do not show what the database is capable of and the type of data that the database contains.  Many people have to see it to believe it. Just as the iD editor has been viewed as an important piece of the puzzle, I view a mapper's map like Tiles@Home equally if not more important than the iD editor. Here's an example. I mapped a ta ta bar, <a href="http://www.openstreetmap.org/node/1801776750" target="_blank">http://www.openstreetmap.org/node/1801776750</a>, It doesn't render. Another mapper put a poi of a nightclub, <a href="http://www.openstreetmap.org/node/2354317861" target="_blank">http://www.openstreetmap.org/node/2354317861</a>.  It doesn't render.  That was part of that mapper's first and last contribution.  The OSM process appears broken.  In Google maps, however, a mapper using map maker is rewarded with their efforts.  You can go to this same location and at least see what I call a "Google Donut" <a href="https://www.google.com/maps/place/The+Candy+Store/@33.6555233,-112.0307235,20z" target="_blank">https://www.google.com/maps/place/The+Candy+Store/@33.6555233,-112.0307235,20z</a>.   The perception is that map maker works while iD, Potlatch, JOSM, Mercator are all broken.  Moreover, the mapper's map tiles can't be some side project that goes away like T@H did.  The butt ugly tiles need to be in the second slot on the OSM site and managed by OSM servers.  In a sense, I have off-boarded part of my mapping just like this mapper did.  I no longer map data of this type.  Why should I even put a sport tag with a leisure=pitch when all the the current tile set needs is is pitch to show a green blob? T@H would reward me with an icon that showed the actual type of playing field.  Being rewarded for mapping efforts encourages additional growth of the database.   Does nearing completion of the map mean showing highways only as all the current pretty map tiles show?  </div>


<div><br></div><div>A license change is not what OSM needs.  The Linux project held firm to their license even though businesses complained.  Corporations are contributing to the project now.  Even Microsoft has contributed to the kernel after years of calling the GPL a cancer.  OSM needs to hold firm to the license that we have.  As people have pointed out a permissive license would allow companies to just sweep the OSM data into their database without gifting back.  I've spent a great deal of my resources in the way of enjoyable time exploring and mapping my part of the world.  That has been my gift to the project and fellow mappers.  Businesses need to figure out how to join in and what they can regift to the project.  If they can't, then there are always other paid alternatives to OSM data.  They have to weight the perceived cost of giving up data verses the cost of paying a service provider like Google to keep their IP.<br>

</div>
<div><br></div><div>I hope this helps,</div><div>Greg</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 7:26 AM, Alex Barth <span dir="ltr"><<a href="mailto:alex@mapbox.com" target="_blank">alex@mapbox.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello everyone -</div><div><br></div><div>I've been sitting on writing about the detrimental effects of OpenStreetMap's share-alike license (ODbL) for a while and finally decided to, um, share. I've been listening long to many OpenStreetMappers I respect a ton telling me it's not so bad and it's just what we're stuck with right now. But given how bad share alike is for OpenStreetMap I don't think we should give up for pushing for a more open license. Here's why I think share-alike hurts OpenStreetMap and how this keeps OpenStreetMap from having the full impact it could have:</div>




<div><br></div><div><a href="http://www.openstreetmap.org/user/lxbarth/diary/21221" target="_blank">http://www.openstreetmap.org/user/lxbarth/diary/21221</a><br></div><div><br></div><div>Looking forward to your comments,</div>


<div><br></div>

<div>Alex</div><div><br></div></div>
<br>_______________________________________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org" target="_blank">Talk-us@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" target="_blank">https://lists.openstreetmap.org/listinfo/talk-us</a><br>
<br></blockquote></div><br></div></div>