[Strategic] Fwd: Subject: Forks and such

TimSC mappinglists at sheerman-chase.org.uk
Sun Aug 29 20:01:15 BST 2010


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




More information about the Strategic mailing list