[Strategic] Fwd: Subject: Forks and such

[Jim Brown]

A general observation on this topic:

If the data is forked, the two (or more) forks will continue to diverge over time...  Dual contributions are possible of course of new data into both forks, but any kind of editing will increasingly be impossible to apply to both sets.

The primary driver for this difficulty is the cascading effect when an object is changed in one fork and not the other, from that point only the lowest common denominator can be edited (a pre fork version, or the last common edit) in a common fashion.  Any edits that use the non-dual information can only be applied to the data set that it came from.

This will continue to escalate one object at a time...  over time as each object is edited in only one fork it will have a distinct identity per fork.  

In essence, unless I am missing the point (and I may be) the ability for any individual mapper to edit upon, and contribute to, multiple forks decreases as the forks diverge.

So specifically, the impact of forked data sets is substantially different from " multiple editors, renderers, loggers, navigation apps, routing Applications" that are acting on the same data set.

My opinion only of course.


Jim



-----Original Message-----
From: strategic-bounces at openstreetmap.org [mailto:strategic-bounces at openstreetmap.org] On Behalf Of TimSC
Sent: 29 August 2010 20:01
To: strategic at openstreetmap.org
Subject: Re: [Strategic] Fwd: Subject: Forks and such


Hi all,

First, a general question. Is it useful for the strategic working group 
if the pros and cons of OSM administered forks are listed? Or is this 
obvious? (I doubt that somehow...) We can put something together if 
necessary.

Secondly, I guess I don't really know anything about any existing OSM 
strategy and I don't go to SOTM. I like your page about the values of 
the working group [1]. It would be a good idea to try to get as much 
community buy in as possible on this (in contrast with certain other 
activities of OSMF, but that is another story). Hadn't we better nail 
down the values before discussing this fork issue? I guess the values 
are mature enough for a preliminary stab at what OSM might be like in 5 
years. As far as I can tell, OSM has always valued being a "do-ocracy". 
This makes forking at least compatible with present  (if not future) OSM 
values?

On 29/08/10 00:25, Grant Slater wrote:
>
> Managing OSM's existing growing infrustructure and servers is already
> a complicated and time consuming task and I have no personal desire to
> complicate my job further by supporting forks on OSM's infrustructure
> and servers.
>    
A good point. OSMs resources (specifically money and sysadmin time) are 
finite. In fact, the lack of sysadmin resources is the biggest obstacle 
to forking IMHO. But to rule forks out on this objection seems rather 
reactionary. You would obviously expend effort on ideas that you think 
are worth while. You don't think a PD/CC-BY-SA fork is worth spending 
your effort supporting. Many in the mapping and user communities prefer 
PD-like or other licensed data and think it is worth while. It's fine to 
refuse to cater for their desires based on personal priorities, but then 
please don't claim OSM is run by consensus.

Hypothetical question: if more volunteer sysadmins stepped forward, 
would this remove your objection? Having different licensed forks might 
open funding doors and cooperation that previously is blocked. The USGS 
might be more friendly if we shared our data back in a form they could 
use. People on the OSM fork google group seem to be planning to raise 
funds and personally administrating their servers. I feel the resources 
issue is very much an open question.

> I believe OSM's strength is its community and supporting the
> fracturing of its own community into distinct forks is unwise in my
> opinion.
>    
OSM has multiple editors, renderers, loggers, navigation apps, routing 
applications. This has only illustrated how diversity is a good thing. 
By analogy, different licenses might improve the project. It's hardly 
like the community will be cut in half. I would be happy to contribute 
my data to both and spend time manually integrating my surveying. A 
potential problem is increasing complexity for users. The learning curve 
to begin mapping is already pretty steep but I don't think this is 
insurmountable.

Regards,

TimSC

[1] 
http://wiki.openstreetmap.org/wiki/Strategic_working_group/VisionMissionValues


_______________________________________________
Strategic mailing list
Strategic at openstreetmap.org
http://lists.openstreetmap.org/listinfo/strategic