On Fri, Oct 1, 2010 at 8:45 PM, Dave F. <[email protected]> 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 _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
