[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