The Theory and Practice of the Software Forge

Share

One of the characteristic developments in the world of commercial open source has been the rise of the software forge. Here's one definition of what this entails:

A software forge is an extensible web-based platform that integrates best-of-breed software tools for collaborative software development. The best-known example of a software forge on the Internet is SourceForge, which hosts the largest collection of open source projects of any of the forges. Other examples are Berlios, Codehaus, and Tigris.

A software forge has two main views: a project portfolio view that lets a developer browse and find projects, and a project view that provides a developer with tools to work on a specific project.

This comes from an interesting paper exploring the benefits of using forges inside a company – in this case, the European software giant SAP.

It begins by laying out the three key characteristics of open source projects:

Open source is said to be based on the principle of meritocracy. We have found that the principle of meritocracy is used as an umbrella term for the following three more specific principles of open source:

Egalitarian. Everyone can contribute, because open source projects are accessible on the Internet and the project community is typically inclusive to anyone who wants to help.

Meritocratic. Contributions are judged transparently and based on their merits. All decisions are discussed publicly on mailing lists and can be looked up for reference.

Self-organizing. There is typically no defined process imposed from the outside so the project community itself determines how to go about its work.

A forge can be thought of as an attempt to formalise those three principles without constraining them – and hence losing their power.

These principles are in stark contrast to how most corporations manage their internal software development processes:

Assigned jobs. Top-down resource assignment determines who works on what project or which piece of the software. Thus, volunteer contributions to other projects are virtually unheard of.

Status rather than merit. A hierarchy of junior and senior developers and architects implies status and usually determines who has the final word in design and implementation decisions.

Imposed processes. A process definition department within the organization determines which software development process to follow and it is binding to all projects.

The bulk of the paper describes the SAP Forge project, comparing it with other large-scale forges, and providing some details of its constituent parts, and how it has worked in practice. It concludes by reflecting on what SAP has learned about the application of the three core principles listed above:

We have found that the open collaboration principles given earlier were crucial to making volunteers happen. In our communications, we emphasize the corresponding mindset:

Egalitarian. Project members need to be inclusive of whoever comes along to help rather than viewing them as a foreign element. Documenting the project with future readers in mind is a core aspect of this.

Meritocratic. Project members need to realize that important input and contributions can come from all across the organization based on perspectives that may be unfamiliar to the original developers.

Self-organizing. SAP has well-defined software development processes. Still, projects need to be accommodating of their volunteers and respectful of their time.

The paper is well-worth reading, both for its unusually rigorous approach, and for the hard facts that it presents about that still rather shadowy beast, the software forge.