SourceForge has reached a crossroads in its journey. The software 
that powered the SourceForge.net website has thus far been entirely 
Open Source, and in the future will become part of a more complicated 
story.

VA, the company behind SourceForge, must find a way to meet the needs 
of enterprise customers of SourceForge Enterprise Edition who have
significant proprietary software installations, and need software 
that can easily coexist with those installations. VA must also deploy 
an engine behind SourceForge.net that will support an ever-growing 
number of users and projects, currently 300,000 and 30,000 respectively. 
This is an unprecedented load, that strains the limits of what any 
software can handle.

VA must provide all this software in the context of a sustainable 
and profitable business model. So SourceForge now faces a multitude 
of challenges:
- can the software meet the needs of its users?
- can the software stay true to its Open Source philosophical heritage?
- can VA pass this referendum on Open Source as a business model?

We hope the answer to these questions will be overwhelmingly affirmative. 
To understand why, we have to remember why we value Open Source, and 
what Open Source accomplishes that's so special.

Open Source is a broad term that encompasses both a distribution model, 
and a software development model.

In the distribution model, you attempt to make a software platform 
ubiquitous by making it freely available, and then look to earn money 
off of software and services on top of the now ubiquitous platform. 
Within the Open Source world this is the model that Cygnus originally 
and now Red Hat have pursued with reasonable success. Nothing about 
this model, however, is unique to Open Source. Netscape pursued this 
model by making its (proprietary) browser freely available, and 
Microsoft still pursues this model on the client side by bundling
software with its operating system and on the server side by making
Internet Information Server freely available.

VA has pursued this model with SourceForge, and had tremendous
success. The services provided by SourceForge.net are freely available, 
and now used by an astonishing 300,000 Open Source developers. 
The platform SourceForge.net represents has truly become ubiquitous. 
Even "copy cat" installations like Savannah serve only to validate 
the original, much as Cheapbytes only extended the reach of Red Hat 
by selling cheap Red Hat CDs.

There is no reason why this distribution model should change. VA 
has always been committed to supporting the Open Source community. 
That support comes at a hefty price (the bandwidth bills and personnel 
costs for SourceForge.net are significant), but VA benefits from 
providing this support. SourceForge.net is the company's best 
reference account, clear proof that the software can scale to
meet the needs of even Fortune 500 companies. Without SourceForge.net,
SourceForge Enterprise Edition would be a much tougher sell.

What's unique about Open Source, however, is not this distribution
model, but the software development model. VA has championed Open 
Source first and foremost because we believe Open Source methods 
produce better software. This seems like such a simple point, but it 
is rich in implications.

This is the issue, for example, that divides Free Software from Open
Source. Richard Stallman and the devotees of the Free Software 
movement pursue their cause out of a sense of moral purpose. They 
believe that we should all feel some sort of ethical obligation to 
make software free. In fact they care very little about _how_ the 
software gets created, and they care little about whether those
methods of creation are superior to other methods. Indeed much of 
the early GNU software was written "cathedral style", the monumental 
work of a single brilliant programmer like Stallman. While such 
efforts are admirable, they don't embody a practice that scales 
well, nor can be replicated as a general software development 
methodology. For Stallman that's perfectly acceptable, because his
crusade has never been about software development methods.

Open Source devotees, by contrast, are complete pragmatists. There 
is a moral dimension to their work only in the sense that pursuing 
a course of enlightened self-interest tends to correlate with 
ethically positive outcomes. But self-interest it is: Open Source 
fascinates its developers not because it's right, but because it 
produces better software.

However, the conditions to facilitate successful Open Source
development are not easy to achieve. Many companies have casually 
open-sourced legacy code in the hopes that sprinkling a little 
magic Open Source dust on it will miraculously breathe new life 
into it. Many developers with great technology have launched
Open Source projects only to founder on their inability to manage 
the project in a proper Open Source fashion.

Let's look at the consequences of these principles:
Open Source developers are ruthlessly pragmatic.
The conditions for successful Open Source development are difficult 
to achieve.
Only when those conditions do obtain can Open Source be a powerful
accelerator of software development.

The natural outcome is this: Open Source developers will insist 
on an Open Source solution only when the conditions are right. 
While they will always look for an opportunity to bring those 
conditions about, they will in fact use whatever tools and 
software are best for the job at the moment. That's just what
pragmatism means.

With this perspective in mind, let's look realistically at where 
the SourceForge code stands today.

In fact, the SourceForge code has been Open Source in name only. 
While one can download it and use it under an accepted Open Source 
license, the development effort has not resembled classic Open 
Source development. No one outside of VA has made significant 
contributions to the code base. Relatively few developers within 
VA have worked on the code. Relatively few bug fixes have come
in from outside sources. Concern that the code might be "taken 
proprietary" is a little disingenous, then, given that the community 
has never rallied to support the development effort in true Open 
Source fashion.

The fault is by no means that of the users, however. The current 
code base simply doesn't meet the requirements for Open Source 
success. Let's contrast two very different Open Source projects, 
and then see how SourceForge fares by comparison.

Linux, on the face of it, stands as a counter-example to all the
lessons of software engineering dating back to Fred Brooks' "The 
Mythical Man-Month". Brooks famously noted that beyond about 6 or 
so, adding more developers to a project doesn't shorten its time 
to completion and can, in fact, have the opposite effect. How is 
it, then, that thousands of people can contribute to Linux, and 
yet the development effort not grind to a halt? The answer,
of course, is that Linux is not a single project. It is a highly 
modular code base, enabling developers to work on modules 
independently without interfering with each other.

Now, Brooks noted that modularity alone does not assure 
scalability. Modules must interface, and as interfaces proliferate 
so too does the need for manpower resources to manage interfaces. 
So Linux is not just a highly modular project, it is one in which 
the interface between its component parts
- are open and clearly documented
- change slowly
- change only under the careful consideration and guidance of a
central team.

Contrast this experience with that of the Mozilla project. 
Mozilla started as a poorly documented monolithic code base. The 
leadership at Mozilla.org changed hands numerous times in the first 
year or so of the project. As a result, the Mozilla project got off 
to a disastrously slow start.  

SourceForge could easily emulate the Mozilla example rather than 
the Linux example. Fortunately, VA has the benefit of learning from 
the experience of others.

The SourceForge code base evolved in typical, but not ideal 
fashion. The initial release was done in a hurry, and done to 
accomodate hosting for a limited number of projects. Additional 
features and functionality were added, but always added on the fly, 
without taking time to step back to consider the basic architecture.
This wasn't a choice, it was simply a necessity. The community's
appetite for what SourceForge offered was ravenous. Remember, the 
entire project is only two years old and has gone from 0 to 300,000 
users in that time.

The result is admirable, but much like Space Station Mir was
admirable: the original design outlived and outperformed all 
original expectations, but in the end the crew spends far too much 
time putting out fires that could affect mission critical services. 
It is time to move from Mir to Freedom.

There's an ideal we'd all like to get to. At some point we'd like to
have a highly modular code base, with clearly documented and carefully
managed interfaces, that would enable small teams of developers to tackle
particular modules in genuine Open Source fashion. This would be a 
win-win situation.

The community would get a more scalable, more stable platform, and 
one it could more easily contribute to. VA would get a core structure 
in which it could continue to offer Open Source modules to support 
the community, but could also offer proprietary modules to serve its 
business needs and the needs of its customers with large proprietary 
installations. The proprietary business would, in turn, provide the 
financial support to continue the free service of SourceForge.net 
that the community so clearly desires.

We aren't at that ideal yet. VA hasn't taken the time yet to
rearchitect the SourceForge engine. The community hasn't made 
substantial contributions to the code base. So we're entering a tough 
interim period where the rearchitecting of SourceForge will go on, 
cathedral-style for a while, until a core modular code base is ready 
for contributions. To pursue any other development strategy would
be to make the Mozilla mistake all over again, and we won't do that.

This interim period may also see proprietary software used to support
the SourceForge.net service. The reality is that SourceForge.net 
demands today functionality that Open Source software today doesn't 
have (fast, scalable, full text searching would be one example). The 
only pragmatic choice is to use the tools that will get the job done.

How long will this interim period go on? Any specific answer would 
be dishonest. We don't really know. This is the moment when Open 
Source, as a development practice, as a business model, and as a 
community, will be put to the test.

Do we expect Open Source to win out in the end? Do we expect to be
using Open Source behind SourceForge.net in the end? Of course we 
do; we're pragmatists.