[OSM-talk] Are there any other projects in a similar fork situation? (Slightly OT)

Serge Wroclawski emacsen at gmail.com
Sat Oct 2 03:04:57 BST 2010


On Fri, Oct 1, 2010 at 8:45 PM, Dave F. <davefox at madasafish.com> wrote:
>  Hi
>
> With the various forks that could/are taking place within OSM I'm curious if
> there are any other examples?
>
> If so, what were their outcomes? Did any re-converge?

OSM is a somewhat unique in that it's not a software project. In that
way it's more like Wikipedia. At the same time, we have a larger
ecosystem of software than Wikipedia, and we have more groups using
our stack (including our data) externally than Wikipedia.

There are many reasons projects fork, and you can do searching on
forks and their success.

In general the reason a project forks is that the original project has
stagnated and the current maintainers are unresponsive. Or (as we're
seeing now with many of the Sun projects), the original maintainer is
no longer going to put resources toward the project.

Occasionally you see projects fork for personal reasons, often a mix
of personality conflict combined with some technical decision.

Here are some famous forks, and how I think they did over time:

EGCS and PGCC

There was a time when GCC development had become slow. During this
time, two new compilers were developed as forks to merge several
experimental features back in. The most well known compiler collection
was EGCS.

The GNU project eventually decided that ECGS was doing a better job at
handling the process, and ECGS was merged back into GCC.

This is a very purposeful fork, where the developers all shared the
hope that it would be merged back in, and and it was.

OpenBSD

OpenBSD originated as a fork of NetBSD in 1995, mostly due to
(rumored) personality clashes with Theo de Rault and the other NetBSD
developers.

OpenBSD is a very successful project overall, but then again, so is NetBSD.

I'd argue OpenBSD has been successful, but illustrative of one
commonality most forks have- which is that the original project
doesn't stop, and has a life of its own.

XEmacs

In the mid 90s a company called Lucid decided to develop a set of
tools to make Emacs easier to use for specialized editing
applications.

The result was Lucid Emacs.  GNU Emacs was still being maintained at
the time, and the fork was largely without notifying the larger Emacs
community, so what was left after Lucid folded was a large amount of
high quality code.

This became the basis of XEmacs, a fork of GNU Emacs. There was an
attempt at merging XEmacs back into GNU Emacs.

The reason the code couldn't be merged back is that the GNU project
has very strict requirements for code contributions. In order to
provide ongoing legal protection services and  facilitate things like
GPL migration, it requires all official GNU code to be signed over to
the FSF. XEmacs had dubious copyright issues. Some of the code was
written by Lucid (and thus owned by the company who bought the IP
rights), some by individual contributors, who were hard to find, and
some by companies.

After all was said and done, the FSF said that while the license was
okay, the copyright assignment never could be, and was forced not to
accept the changes back.

This meant there were two emacsen.

XEmacs was superior for a long time. The code was better and it was
more featureful. But now GNU Emacs has caught up on all the features
it cares about, and has exceeded XEmacs in terms of features.

Both communities seem to view the fork as a problem for the community,
spitting development efforts, and resulting in incompatible Elisp
code.

It took more than a decade for the original project to regain its prominence.

Citizendium

Most people may not even be aware that there's a competitor to
Wikipedia called Citizendium. Citizendium started off as a fork, based
on the idea that Wikipedia was unreliable and required experts to
certify the information was correct.

Citizendium decided before its launch that it couldn't fork WIkipedia
for the reasons above, and started from scratch. During this time, its
backers would speak to academics and others about why their project
was superior, arguing in favor of greater reliability and control by
knowledgeable officials.

My opinion on Citizendium is that even despite getting backing from
"old school academics" that the project hasn't really succeeded. Most
people haven't even heard of it, and despite its self imposed
editorial process, people go to Wikipedia more.


Now my opinion of any potential OpenStreetMap fork.

I think such a project would fail, and here are my reasons why:

1) OSM is in a growth phase

Most forks are triggered by a stagnation in the development process
and that's not happening with OSM. OSM is still in its exponential
growth phase. We have more users and developers than we've ever had
before.

2) The forkers don't agree on the reason to fork

The forkers don't seem to agree on why they want to fork. Some want to
fork because they want the database to remain CC-BY-SA. Others want a
whole new map that's (effectively) public domain (whether that's CC0
or CC-BY, or something else), while others, I think, just want a new
project for personality reasons.

The problem is that since their goals are incompatible, they won't be
able to organize effectively. If you believe strongly in "public
domain" geodata, you won't find BY-SA acceptable, nor will you be able
to use OSM data. If you're interested in CC-BY-SA, you won't have the
support of the public domainers, etc.

3) OSM has external organizational support

OSM now has organizational, government and commercial support. That's
something none of the forks will have. And for the pubic-domainers-
any organization who wants to use the OSM stack without the OSM
database can (and in some cases) already have done so.

4) No fork is offering any compelling reason to use it over OSM

I haven't seen anything from the forkers that gives the average user a
compelling reason to switch. The average contributor doesn't care
about whether the license is CC-BY-SA or ODbL. And since OSM has the
mindshare, developer mindshare and financial resources backing it,
it's likely to remain ahead.

There'd be a feature race, but OSM would always, or nearly always, be ahead.


This is why I believe strongly in OSM and its future.

- Serge



More information about the talk mailing list