Section 3.1. Preconstructed Development Environments

3.1. Preconstructed Development Environments

Preconstructed development environments (PDEs) are what I have chosen to call software development environments that are provided as a single set of software applications. (Whether or not they are practical development environments, as in the title of this book, is a separate issue for each PDE.) Another name sometimes used for them is collaborative development environments, but it seems to me that development environments are always collaborative, and what sets these environments apart is that they come ready-made, prefabricatedin short, preconstructed.

If you are setting up a development environment and one of these environments works for you, maybe you won't have to choose every tool to use in your environment. Still, the other chapters in this book contain much more than just which tool to choose, so read on.

One well-known example of a PDE is SourceForge (http://www.sourceforge.net), which uses the term "software development website" to describe itself. A typical PDE provides an SCM tool, a bug tracking tool, a project home page, and somewhere to download released files from. Some PDEs also provide online discussion forums, weblogs, and "farms" of different machines for developing ports of the project to multiple platforms and for running tests. Some even provide databases ready for use by the different projects. Still others have usage statistics for each project and places to post requests for help or jobs. The various parts of the PDE should all work together and, as much as possible, already be configured to make hosting your project quick and easy.

PDEs are rather like preconstructed houses. They are quick to set up and start living in, but they can be harder to change later on. One benefit is that once you have used a particular PDE for one project, it becomes easy to find your way around other projects that are using the same PDE. Once you have found the statistics for one SourceForge project, you know where to look for the statistics for every other SourceForge project.

Another analogy is to writing a document. You can choose to either use a text editor to create the document locally on your own machine exactly as you want it, or enter the text on a remote machine (as with weblogs and Wiki entries), leaving the effort of formatting and publishing the document to someone else. (Wikis are web sites that can be modified by anyone.)

Some of the potential benefits of PDEs are:

Ease of integration and use: All the necessary parts of the environment should work together in a standard, straightforward way, which should make them easier to use.
Lower administrative costs: If the environment is a remote one, then the environment provider may be able to spread the costs of toolsmiths (or whoever supports the necessary applications) over multiple projects. If the environment is installed locally, then having fewer knobs to twiddle may mean that there is less custom work to be done by toolsmiths.

However, the benefits of preconstructed environments should be tempered with the following potential problems:

Customization: Many software development teams are used to being able to tweak their development environment. Part of this may be due to the Unix philosophy of using lots of smaller tools rather than one big tool. Preconstructed environments are often not really designed to be modified beyond some carefully exposed portions of the existing APIs of their underlying tools.
Security: If an open source remote environment is used, the project's source files and data may become publicly available. If an environment that supports closed projects is used, one where the source files and data are not public, then separate projects have to be very carefully insulated from each other. This is possible (for instance, by using virtual machines), but it does require careful configuration and monitoring to be truly secure.
Backups: Many environments will regularly provide each project with a collection of files suitable for backups, but it is still up to some project member to make sure that the backups actually occur. Testing the recovery of backups is also hard to do in some preconstructed environments.
Portability: One concern that is also related to backups is how to extract a project's source files along with all its history, bugs, mailing list archives, and documentation from a particular environment. For instance, what happens if the environment provider goes out of business, or changes its terms of usage? It generally helps if the backups are in a standard, open format that can be imported by other tools. Just as with office software suites, it's usually much easier to import projects into PDEs than to export projects from them.

Outsourcing your Environment

The idea of outsourced development environments, which is akin to the idea of an application service provider, seems to have grown up with the Internet in the late 1990s. Perhaps part of the reason is that various services such as search engines are provided remotely, but there is also great interest in how the same development environments can be provided for use within companies. After all, if a company can outsource its IT department or developers, it may also make sense to outsource the creation and maintenance of the tools used to develop the software.

Before you outsource your development environment, make sure that you have good answers about how much you can customize the environment, how secure it is, how backups are performed and tested, and how you would extract your project from the environment to move it somewhere else.

The differences between many PDEs are whether the source code that integrates the various parts of the PDE is open or closed source, and which tools are supported. If you want an exhaustive comparison of various open source PDEs, see the thorough "Comparison of Free/Open Source Project Hosting Sites," by Haggen So (http://www.ibiblio.org/fosphost). For now, I'll focus on the most popular PDEs: SourceForge, GForge, CollabNet, Savane, and BerliOS. These five PDEs are compared briefly in Table 3-1. The values for the number of projects and number of users are taken from each PDE's web site in August 2005. A plus sign (+) indicates a strength and a minus sign (-) indicates a relative weakness, either in features or usability.

Table 3-1. Comparison of PDEs
Feature	SourceForge	GForge	CollabNet	Savane	BerliOS
Location	sourceforge.net	Various	tigris.org	savannah.gnu.org	developer.berlios.de
Number of projects	100,000	5,000	500	2,200	2,200
Number of users	1,000,000	130,000	Thousands	32,000	11,000
SCM tools	CVS, ViewCVS	CVS, ViewCVS, Subversion	CVS, ViewCVS, Subversion	CVS, ViewCVS	CVS, Subversion
Bug tracking	-	+	+	-	-
Other tools	Databases, compile farm, donations, and more	Time tracking, themes	Better searching	Overall site statistics	Multiple languages supported
PDE source open/closed	Closed	Open	Closed	Open	Open
Cost	$0; $40/year for better searching and support; or $2,750 for the commercial version	$0	$0; or $2,400 for the commercial version	$0	$0

3.1.1. SourceForge

SourceForge (http://www.sourceforge.net) is the original PDE, dating back to early 2000. The software to run the web site was originally open source but was then closed when the SourceForge web site was announced. As of 2005, it remains the largest PDE, both by number of registered projects (over 100,000) and users (over 1 million), though many of the projects are inactive. SourceForge is designed for open source projects and has mechanisms for donating to projects. Each project has access to a wide range of (mostly standalone) tools linked by a central project home page. There is also an option to subscribe to SourceForge for around $40/year, which gives you better searching abilities over all the projects, higher-priority technical support, and direct downloading of files. The bug tracking system is fairly basic. For example, you can add categories for your project's bugs but can't remove old categories.

There is also a commercial version of SourceForge, SourceForge Enterprise Edition, which is available from http://www.vasoftware.com for around $2,750 per user. Some advantages of the commercial product are that it was designed for integrating with a wider range of different applications; security and access control is better supported; and it has a greater ability to search the project's source files and documentation.

3.1.2. GForge

GForge (http://www.gforge.com) is an open source PDE, though the GForge Group calls it a "collaborative development environment." The source code for GForge is a fork of the last open source version of SourceForge's source code. Numerous changes, including support for Subversion, have been made since then. Commercial support and even "plug and play" machines with GForge preinstalled are provided by the GForge Group, which includes some of the core GForge developers. The GForge Group itself does not provide any public project space using GForge, but it estimates that there are around 5,000 projects and 130,000 users of GForge. GForge 4.0 was released in October 2004.

While GForge is open source, there are compelling arguments for using a preconfigured server or commercial support if GForge is being used in a corporate environment. For one, GForge has many different software components to be installed and configured. Customization of GForge in such a way that future upgrades will be possible is always going to be easier if the core developers do it.

3.1.3. CollabNet

CollabNet Enterprise Edition (formerly SourceCast) from CollabNet (http://www.collab.net) is a commercial "collaborative software development environment." CollabNet was founded in 1999 by Brian Behelendorf and O'Reilly & Associates. As of 2005, the product costs around $2,400 per developer per year. Unlike the commercial PDEs from GForge or SourceForge, CollabNet maintains its system as a managed service for its customers. The development of CollabNet is itself distributed around the world and coordinated using CollabNet. The open source NetBeans IDE project (http://www.netbeans.org) is a good example of CollabNet in action, as is Sun's Java community at http://java.net.

Tigris (http://www.tigris.org) is a free web site run by CollabNet to encourage the development of better open source software tools for collaborative software development. There are hundreds of relatively active projects hosted at Tigris, and the projects are carefully chosen to match the goals of the Tigris community. One of the best-known Tigris projects is Subversion, the SCM tool intended as a replacement for CVS (see Section 4.6.1 and Section 4.6.2). CollabNet offers Subversion as one option for its SCM tool. CollabNet also provides hosting and the development environment for the SCM tool CVS at http://www.cvshome.org.

3.1.4. Savane

Savane (https://gna.org/projects/savane) is the open source software package used to run GNU's Savannah PDE, which is where GNU software is developed (http://savannah.gnu.org). It also runs http://savannah.nongnu.org for other non-GNU free software development. Savane is also used to run the GNA! PDE at https://gna.org. The source code for Savane is a fork of the last open source version of SourceForge's source code. As of 2005, there are over 2,000 projects and nearly 30,000 registered users. Support for Savane is informal, but enthusiastic.

3.1.5. BerliOS

BerliOS is a service funded by the German government and industry to encourage the development and use of open source software. Services are available in German, English, and Spanish. As of 2005, around 2,200 projects with just over 10,000 users are active at BerliOS Developer (http://developer.berlios.de), the PDE provided by Berlios. BerliOS also provides DocsWell, a database for open source-related documentation; SourceWell, a news service for open source projects; SourceLines, a best-practice database for successful open source projects; SourceBiz, a list of open source companies; DevCounter, a database of open source developer profiles; and OpenFacts, a Wiki-based open source knowledge database.

Just like Savane and GForge, BerliOS Developer is based on early SourceForge source code and is still open source. Installation documentation for BerliOS Developer is rather scarce, probably since it is similar to SourceForge installation.

3.1.6. Improving PDEs

It's one thing to use a remote preconstructed environment such as SourceForge, where you're depending upon a remote group of toolsmiths to develop and maintain your development environment for you. It's quite another to expect to be able to run a single installation command and have a working SCM tool, a bug tracking tool, a web server, and so on. No PDE that I'm aware of is there yet, but I think that this is where PDEs should be heading. The alternative is to have a consulting company such as the aforementioned GForge Group do it all for you.

Another area where PDEs could be improved is in the integration of their different partsfor instance, having SCM commits for a bug automatically add links in the bug entry to web pages that show the changes in the appropriate files. One approach taken by many large integration tools is to use a common data format for exchanging data between different parts of the application. This makes adding different SCM and bug tracking tools easier in the future, at the cost of having to add another access layer to every tool. This idea can be taken a step further: imagine a common data format to describe the services such as the SCM tool and bug tracking system that a project is using. Such a format would make it easier to import and export projects from different PDEs.

Something to watch for in the future will be PDEs that come complete with automation environments, which are tools that perform lots of different automated tasks for you (see Section 3.4, later in this chapter). Automation environments that regularly check out your source code and then build and test the product can really help to bring a project together. Expect to see this appear as part of PDEs in the near future.