GForge

GForge is a fork of the original SourceForge.net code. SourceForge, in addition to being a site hosting open source projects, was an open source project in and of itself. That is, in theory you could download the SourceForge code and set up your own personal SourceForge-ish site. I say in theory because in practicality it was extremely difficult. The code was not very clean and not very friendly, especially if you wanted to vary at all from the setup SourceForge.net used.

A couple of years ago VA Linux, who owned and supported SourceForge, decided to stop making releases to the open source version and instead start working on a proprietary SourceForge Enterprise product. When the code closed, a couple of forks were created with the intent to keep the project alive. Most notably, the FSF created Savannah and while Tim Perdue (an original SourceForge developer) created GForge. The goal of GForge was to clean up the code base and make the installation procedure much less painfull. In addition, Tim launched the GForge Group to provide professional commercial support, enhancements and installation.

My part of the this story begins with a reorganized IT group that needed some way to manage our workload and incoming requests. Since I didn’t want to see yet another set of Excel templates or an Access database become our request and bug tracking system, I volunteered to find a better solution. My initial candidates were JIRA, Scarab and GForge. I also looked at Trac and in retrospect that might have been the better solution, but we’ll get to that later.

After an initial demoing of the candidates, the managers and project leads preferred GForge, so I set out to set up the server and move forward. It was at that point that I began to run into several hurdles:

1. Installing GForge is not trivial 2. Site-wide administrative features and reporting in GForge is weak 3. Enhancing or customizing GForge often involves ugly hacks

Installing GForge, while simpler than SourceForge, was no cake walk. If you’re running Debian Linux, then it’s not too bad, but if you’re running anything else, it can be very tricky. One of the great features of GForge is that it leverages so many other technologies (Apache, MailMan, CVS/SVN, ...) but that’s also its downfall. During installation you need to make sure that all of these other software components are properly installed and working well together. This means you’re bouncing around the net looking for documentation, installation procedures, and troubleshooting. GForge does not have a simple “out-of-the-box” solution (you have to go to the GForge Group for that).

Once I got past the installation issues, the next issue that popped up was actual administration and usage of GForge. You see, GForge’s project management features are all at the level of the individual projects. Each project is sort of its own island. Of course, we as an IT group have several projects active at any one time. At first we attempted to create new GForge project spaces for each IT project. While this provided a great set of tools for the developers and immediate project leads, it provided almost no tools for the IT managers who need aggregated reporting and administration of all the project spaces. This sort of site-wide management isn’t really available in GForge yet.

Moreover, we wanted to create a simple customer front end. The idea being that users and other managers could submit requests or issues into a single simple web interface that would be a sort of gatekeeper to GForge. Once the issue or request was reviewed and approved, it could be transferred to the appropriate GForge project.

Our first attempt was to create an new GForge project for this front end. Users could enter requests into this project’s trackers. But we needed a way to cross the project boundaries in order to transfer and link these items to other projects where they would ultimately be handled.

Bridging the gap between projects is not a trivial enhancement to GForge and now we had two requirements to do so (reporting and administration and issue linking or transfers). While we could create a completely separate application to funnel issues into GForge, that wouldn’t also solve our site wide reporting and administration issues, so we decided on an new approach.

It’s at this point I began to realize that GForge wasn’t quite the right fit for us and I admit that was a failing on my part in both requirements gathering and product evaluation. However, GForge could still work for us with a few changes in how we were using it.

We decided that instead of mapping GForge projects to actual IT projects, we would map GForge projects to managers and organizations. This meant that essentially we would have one single project for our IT group. No need for transferring or linking between projects. All the project administration and reporting works on the project level too. At first there was some concern that this solution would lead to overcrowding within the project space, but that hasn’t turned out to be true. A GForge project is flexible enough to scale to our needs. Each IT project can have it’s own set of trackers and subprojects, mailing lists, forums and other features. The only truely shared resource is the Subversion repository, but since svn is so flexible in its structure, this hasn’t proven to be a problem either.

Additionally, this strategy leaves GForge available for other organizations in our company. Each team or group or manager could have their own GForge space to manage their own tasks and projects. We haven’t started to expand GForge in this way yet, but the opportunity is there.

Now, there is another aspect to my adventure with GForge worth sharing. Once the IT group got all cosy in the new unified project space, there were a number of enhancements we wanted to make. For example, we wanted some sort of approval cycle with email notifications. We wanted some enhanced reporting and maybe a simpler front end for customers to one of the issue trackers. This involved getting into the GForge source code and making modifications.

GForge is written in PHP and I am not a PHP developer. However, I’ve found an appreciation for the language but I can also see how managing a large PHP codebase can quickly become a mess. The GForge developers have done an admirable job in cleaning up much of the original SourceForge code, making it more object oriented and modular, but, to be perfectly and brutally honest, it’s still a mess. A really big, often hard coded, tangled and twisted, why aren’t you using CSS mess.

I’ll leave a code review for another day and you’re free to check out the latest version from GForge to see for yourself. A classic example is the skin or template features. It’s essentially one large PHP class (Layout.class) that includes all the CSS inside the class itself. Yep, no external CSS sheets to edit, only PHP. The actual layout is mostly table based, few use of divs. And of course, there’s plenty of other style information and page structure scattered through the rest of the code.

Hacking GForge (for that is certainly how it feels) while at the same time playing with other CMS frameworks has given me some ideas about how GForge could be structured: a basic CMS core, a simple project space object model, and each project feature (trackers, task manager, mailing lists) a plugin with extension points. I’ve half a mind to someday start my own fork and use python or ruby to “do it right.” :-)

And all of this gets me to my final point in reviewing GForge. Our enhancements have come along and we’ve got a working system now that we’re rather pleased with. Trying to be a good citizen, I’ve attempted to contribute some of those patches back to the GForge team. This has introduced me to in interesting dynamics of the GForge community. Tim Perdue is the “dictator” of the project, but he’s not always very benevolent. For example, this morning he called somebody an a**hole and disabled his account because he had reopenned a patch request Tim had closed. Okay, so he shouldn’t have reopenned the patch, but insulting users who are actually trying to contribute to the project doesn’t alway engender good feelings. And it isn’t the first time.

Consequently, the user community is a bit fragmented. You’ll find quite a few GForge sites out there (so there are users), but asking a question in the user forum doesn’t always soliciate a response and when it does, it’s usually from Tim or one of the main developers. Users tend not to stick around long enough to start helping one another. Perhaps that’s because of the community dynamics. Perhaps that’s because of the learning curve (and state) of the GForge code base. It’s such a monolithic application that there’s really no room for adding modular enhancements, plugins, or features without committing directly to the core source code. In any case, you may find it worth your while to turn to the commerical support instead of the community.

I mentioned Trac earlier. In retrospect, that may have been all we needed. It probably would have been easier to plug Trac into a larger IT management solution than contort GForge into our management solution. That said, there is certainly a lot of potential for GForge or any similar open source project like it which can overcome the installation, modularity, and community issues.