oreilly.comSafari Books Online.Conferences.


Tools for Geographically Distributed Software Development
Pages: 1, 2

Once the framework for day-to-day collaboration is established, the next challenge to face is temporal. The time zone difference between the members of a GDD team can give the team an edge, or it can be an obstacle that confuses the workflow. An excellent tool that will be constantly useful is This web site allows quick access to time zone information and also has a Meeting Planner application which makes it easy to visualize time zone differences while scheduling a meeting. There are also a number of other on the site that are related to date and time which, will be helpful as the GDD team adjusts to their coworkers' days and nights.

Once the GDD team is set up to deal with linguistic, temporal, and distance-related challenges, the next challenge is to find a suite of tools will facilitate the workflow of the development. Again, many of these tools are core internet collaboration technologies. They include:

  1. Mailing lists: A tried-and-true complement to real-time interaction. Mailing lists allow for a different type of discussion which is (in theory) more reasoned and thought-out than real-time exchanges. We use Mailman.
  2. Version control: Most developers are familiar with CVS and Subversion, two traditional client-server versioning systems that keep track of source code that many people are working on simultaenously. A new family of versioning systems are emerging, though, which favor a distributed repository model over the client-server type. What distributed CVS boils down to are smarter mechanisms for merging code that give the developer more freedom (for example, with a distributed versioning system you can check code into the repository without being connected to the internet). Examples of distributed versioning systems are Bazaar and Mercurial.
  3. Bug tracking: The specific bug tracking system used often sets the pace for the phases of the software development cycle, to the extent that it is convenient to use the bug statuses in the system. This component hasn't changed much over the years: bugs are entered, a developer confirms or rejects the bug, the bug status changes as the developer works on the fix, checks it into the CVS repository, and then pushes the code to production. We still use Bugzilla for this.
  4. Document management: Collaborative document management is a key part of long-distance working relationships. The advantages of a wiki is well-known by now; it permits document versioning and rollbacks, it is easy to see who made what change, and its very simple for anyone to jump in and participate on the wiki. There are some "Web 2.0" offerings that make an improvement on the group editing functionality of wikis. An example that we've used is, for each document you can establish a workflow, there is an easy-to-use history and notes section and there is a nice desktop-like interface for editing the current revision. However, is not a wiki and so the way we've integrated these types of tools are that we'll create the initial version of the document on the more advanced tool like writewith. And once we've worked through the entire process and arrived at a final draft, we'll move it to the wiki which is good for organizing all of our documents.

The problem with using all these different tools are that they're scattered around different places on the internet, require multiple logins, and any risk of confusion about which tool to use should be avoided. We don't have this problem because we've evolved to a stable point in our development process and each tool we use is used because it worked out the best for us in our workflow. It isn't hard for new developers to catch up with our suite of tools.

It is possible to upgrade your different tools to accept a single login, using new software packages coming out such as aMember. aMember is actually used for creating paid membership areas of a web site but that functionality is also useful for having a single point-of-login for many different web applications. We are currently in the process of building an aMember-like meta-login for the various groupware tools we use for GDD.

For teams that are just starting out with GDD, there are commercial services that provide an integrated platform of all these tools. One example is CollabNet's SourceCast, billed as everything you need for geographically-distant software development. Essentially, it provides all the tools discussed above in one place for each software project. While it is certainly possible to construct a GDD environment using free software tools, there is some value in having it all organized in one central location. It is unclear how SourceCast approaches the need for real-time communication and the "virtual workplace."

Similar offerings closer to the hearts of free software advocates are the GNU Project's Savannah and VA Software's SourceForge. SourceCast, SourceForge, and Savannah offer mailing lists, CVS repositories, issue trackers, file stores, and document sharing in one central location for software projects.

An interesting feature that is now being deployed in offshore development applications are VNC "watch windows." Intended to address the discomfort that state-side engineering managers have with offshore engineers being productive, these applications force the developer to "clock in" on his development machine and then everything that happens on his desktop is viewable in a VNC window from the administrator/manager's control panel. While this technology could be useful, it probably will do more harm in the type of relationship the manager is forming with the engineer.

The final application to discuss here for GDD is technology for advanced conferencing. While IRC and e-mail are sufficient for most day-to-day tasks, it is useful now and again to have a face-to-face meeting where the team members can see and hear each other. The new generation of internet conferencing is making all of this possible. We use Skype for audio conferencing, as well as cross-platform audio and video conferencing when we need to have a more sophisticated discussion.

So, although there are commercial services available for outsourcing and long-distance development projects, most of them are packaged versions of technologies that open source and free software projects have used for years. With some careful setup, any group of developers can compete with the budgets used by multinational software development firms to distribute their application engineering and quickly realize significant gains in efficiency and speed. For us, we keep our international team of developers running smoothly and what we get out of that is the ability to bid on jobs on three different continents and in three different languages, we can outsource when appropriate for cost savings, and we get a lot of personal fulfillment out of bridging cultural barriers as part of doing our jobs every day.

Ryan Bagueros builds internet technologies in San Francisco, California and Sao Paulo, Brazil with his company,

Return to

Sponsored by: