Executive summary
To avoid confusion with the proprietary versions of GForge (known as
GForge Advanced Server, GForge Express Edition and GForge Community
Edition), the free/libre/opensource codebase will from now on be
separately maintained under the name FusionForge by the main
developers of the free GForge 4.x codebase. Since this is mostly a
renaming, the migration path for existing users will be smooth.
Longer version, with details
After the initial forking from the Sourceforge codebase, the
development of GForge has long been hosted, and many enhancements
directly developed, by the GForge Group (GForge, LLC), with regular
contributions from outsiders. The results of these evolutions were
public and free, subject to the GNU GPL.
In parallel, the GForge Group wrote a proprietary re-implementation of
GForge, which it sold under the name "GForge Advanced Server", or
"GForge AS" for short. This re-implementation added some features for
"the enterprise", but was not contributed wholesale to the GForge
codebase under a free license. Although some of the features were
contributed to the public, the GForge Group concentrated its efforts
on its (proprietary software) business model, with more versions
appearing, such as "GForge Express Edition" and more recently "GForge
Community Edition". As a result, it became increasingly harder for
the public to know which version was which without doing extensive
research (indeed, some users mistakenly installed one version instead
of the other). A consequence was that the free software codebase
suffered from a loss in visibility, which lowered its momentum to the
point that there haven't been any moderately important releases since
the (currently stable) 4.5.x series was announced in late 2005.
So, in order to clarify things, avoid further confusion, and regain
some of the lost momentum, it was decided by a group of leading
contributors that the free software version of the GForge codebase
would from now on be developed under the FusionForge name, and its
development would be hosted on FusionForge.org.
So is this a fork?
Well, we don't know yet. It could arguably be called one, since we're
taking the code and running away with it under a new name. However,
we believe it's not a fork unless both roads continue their own way
(more of a oddly-shaped bend). What happens to the GForge codebase
developed by the GForge Group at gforge.org remains to be seen,
although for the sake of our users we will backport security fixes to
the gforge.org Subversion repository (at least for the 4.5.x series
and the unreleased 4.6 and 4.7 pre-series) for some time. The bulk of
the development will move on to FusionForge and the repositories at
FusionForge.org, though, and users are encouraged to migrate at their
own pace. Since we're basically continuing the evolution rather than
starting from scratch, the migration path should be rather smooth.
So why the FusionForge name?
Because there were actually lots of locally-patched versions of GForge
(and Sourceforge), and we felt it was a waste of resources that should
be fixed. It seems many people and organisations took these codebases
at some point in time and evolved them for their own needs. Sadly,
many of the changes were not contributed back or even published, so
lots of efforts were duplicated. Fortunately, many of the people
managing these locally-patched forges are now realising that
"out-of-tree" patches and features require quite some manpower to
maintain. Some formal inter-project discussion is already taking
place, and we hope to achieve actual merging of most of the
interesting features that have been developed here and there into a
common base that can be reused locally with minimal changes. We'd
like to "un-fork" as much as possible.
We also expect that, by using standard components and tools, we'll
facilitate the work of potential contributors, thereby reducing the
risk of a new era of fragmentation.
And who are we anyway?
We're Christian Bayle, Roland Mas and Alain Peyrat, long-time
contributors to GForge and responsible for over 95% of the commits
over the past two years, as well as a few relative newcomers.
Christian and Roland have been maintaining the Debian packaging since
the "Debian-SF" era, and Alain has been focusing on code quality. The
three of us have, for various reasons, a vested interest in
maintaining a lively codebase in a healthy ecosystem.
What are our plans?
Our short-term goals, as currently planned, include:
- pushing a stable FusionForge release out of the door;
- cleaning up and auditing the database schema to ensure consistency
and increased performance;
- merging in new plugins, in particular for new version control
systems;
- continuing streamlining the installation process to make it more
portable across distributions.
Longer term goals are less well defined, but we're thinking about the
following:
- increasing code quality by the use of modern automated tools;
- encouraging a lively stream of external contributions, to reduce the
gap between the official version and the locally-patched ones;
- defining an explicit governance model and release process for the
FusionForge project;
- as a consequence, a more frequent and predictable release schedule;
- increasing data portability and interoperability with other forges,
to reduce lock-in for users and projects.
Some of these items should be facilitated by our switch to a
distributed version control system and a new coordinated workflow.
Also, the Debian i18n team has been kind enough to offer to host our
translation effort on their Pootle server, which means translators
will have a much easier time doing their job.
We hope to hear from users and contributors alike in the near future.
For more information, we can be reached via our fusionforge-general
mailing-list (see our lists), which is
also suitable for general discussions. We can also be found on IRC
(#fusionforge on the Freenode network).
Bookmark this on Delicious
