My Opinion on SourceForge Enterprise Edition

We've been evaluating new development tool-suites at my day job. On Tuesday, I attended a demo of SourceForge Enterprise Edition from VA Software. Someday soon I'm probably going to post about our development toolsuite because we've put a great deal of effort into getting it right. So why are we switching? That's a Shakesperian tragedy in itself, but the short version is simply "politics."

<Begin Interpolation on the history of SourceForge>
It’s important to note that SFEE is distinct from SourceForge.net. SF.net is the original, open-source project started by VA Linux way back in 2000. It was supposed to provide free project hosting and management for the open-source community. You could use their hosting service and keep your code & data on their servers, or you could download the project and run it in your own organization if you wished.

Sometime later (2001-ish?) VA Linux realized their hardware business wasn’t going anywhere and internet ad revenues had begun to dry up, so the forked SF.net and in order to create the internal, closed-source SFEE which they now sell at extortionary per-seat pricing.

Since forking the project, VA Software has rewritten most of the SF code, turning it into a J2EE application instead of a PHP app. The basic functionality is still reasonably similar. Since the fork, they’ve continued to run SF.net for the community and the community has continued to use it. However, there have been no visible improvements to SF.net since. It’s basically abandoned, from a software development standpoint.

Some brave souls took the old, open-source SF.net and created gForge. They’re attempting to continue the development of the system. It appears that they offer both project hosting and downloadable versions of gForge. However, I’ve never used either version, so I can’t comment on what features they may have added over and above SF.net. Though it does look somewhat prettier.
<End interpolation>

I actually had to argue with other people in my department to get VA Software in for a demo. My insistence was mostly a result of how god-awful the other products we’ve seen have been. But I was inclined to like SFEE from the beginning. I have a basically positive opinion of the company. First, it’s not Rational. Second, they develop the software using XP. (Check out this job description. Makes me want to work there.) Third, they own Slashdot, FreshMeat, et al. so they must have some understanding of the style of development that we want to do.

The demo itself was pretty good. We spent about two and a half hours going over the company and the software. The folks from VA were nice, and more knowledgable than some of the other salesfolk we’ve had in. They were mostly honest about what SFEE could and couldn’t do. I appreciate that. (The two answers I’ve come to hate most are “Let me get back to you about that” and “Well, using our API we can make that happen.”)

Here’s what I liked about SFEE:

1. It’s much prettier than SF.net. Indeed, the interface is better than all of the other tools we looked at. Given how much time I tend to spend in these tools, that’s a non-trivial consideration.
2. It integrates with CVS. Integration with SVN and P4 is on the way, apparently. I hate products that expect me to switch version control tools just because I want to use their bug-tracker. Buy a tool that does one thing well — small peices loosely joined.
3. They had a pretty good searching and filtering interface.
4. The had very granular notification preferences. That something our current tool is lacking.
5. The access controls were also very granular.
6. Versioned document management. Searchable binary docs.
7. Release archive with automatically generated release notes.
8. The release archive actually tied into the bug-tracker fields.
9. SFEE gives you unified user management. This is one of the big downfalls of a build-it-yourself system. With SF, I can create a user and magically he has a CVS account, a bug-tracker account, a documentation account, a mailing-list membership, &c.
10. It has a SOAP API. My earlier comment notwithstanding, I wouldn’t ever buy one of these tools without a web API.
11. MS Project integration. Personally, I think that, like PowerPoint, MSProject is a terrible tool that often does more harm than good to a software project. It encourages the wrong kind of thinking. It makes it easy to make bad assumptions or to trust fictitous data just because it’s in the GANNT chart. But nonetheless, other people like it and use it. And it’s pretty standard among project-management types.
12. VA is a small company. (~120 people). SFEE is created by small dev team (~20 people). Smaller companies tend to be more communicative, more flexible and more responsive.
13. SFEE seemed like it wouldn’t get in the way very much. This was a very process-light tool, unlike Rational. I would guess that we’d be able to continue using our current methodology with this new tool.

Here’s what I didn’t like about SFEE:

1. There is NO workflow at all. This is inexcusable. I don’t know what they hell they’ve been doing for the last 2 years. This is a totally fundamental feature. This may end up being a deal-killer for other folks in the company. Our current tools started with a non-configurable workflow [they just released the configurability in the latest version], but it least it had a workflow. As far as I could tell from the SFEE demo, bugs can be “Open” or bugs can be “Closed” and that’s all.
2. They have these two types of items, “Tasks” and “Trackers.” I’m still not entirely sure what the difference is, or why you would want to use a Task (which is totally non-customizable) instead of a tracker (which is customizable). Although, tasks are apparently the thing you use to integrate with MS Project (see above) and thus they have hierarchy, while Trackers don’t.
3. Trackers don’t have intelligent relationships. Every item in the system (files, commits, tracker items, tasks, messages) can be “associated” with every other item in the system. However, the associations are just bi-directional links. There is no way to imply any sort of relationship, like parent/child, requirement/implementation, bug/commit, task/sub-task.
4. SFEE doesn’t have real mailing lists. It has threaded discussions, which will cc: to email. We could probably figure out a way to make this work, but a real mailing list (like mailman except with better archiving) is what I’d really like.
5. Despite the fact that they offer unified user management, they can’t integrate with any external user system, like LDAP or AD.
6. The URLs are not as user-friendly as I would like. For example, our current system gives us URLs that look like “www.bugtracker.com/show/PROJ-1234”. Much nicer.
7. No wiki functionality. (Though they claim this is on the way.) We’ve recently installed a wiki at my day job, and people love it.
8. They use CVSWeb. There are far better-designed interfaces to a CVS repository than CVSWeb.

Other things that SFEE can’t do (I don’t care about these but some people might):

1. It wouldn’t make a good Customer Service tool. Personally, I think that CS and Eng. should not use the same tool, but some might disagree.
2. SFEE doesn’t have build management or deployment features. I think these processes tend to be too specific to cram into a tool like this, but there have been attempts.
3. There is is no functionality for requirements management. You keep requirements in Word docs like you always have, and then keep the Word docs in the document management section. So at least the docs get versioned, but that’s all. I could write a whole treatise on requirements management and why it sucks (and I will someday). I KNOW there is a better solution out there waiting to be thought of.

The last issue I have with SF revolves around the open-source question. This turns out to a highly-charged issue that’s difficult for me to resolve.

On the one hand, SFEE is, by far, the most open-source friendly of the big development suites with which I’m familiar. A cursory comparison to Rational reveals the obvious advantage for a team that develops using open-source principles or agile practices. And VA Software still does a lot to support the community (see OSTG).

On the other hand, it sucks that VA took what had been a vibrant open-source project and destroyed it. It sucks that SF.net will never get any better. It sucks that they can’t draft off community development for their product, especially given how far SFEE still needs to go. It sucks that even when you buy a license to SFEE, you still don’t get the source.

But here’s what really pissed me off: The second slide of their presentation was all about their “open-source credentials.” There were bullet points about SF.net, and a chart of it’s user growth. They talked about open-source “best practices.” They claimed talked about how openness and information sharing could help our team. They pitched the “SorceForge Collaborative Development Process.” (Because these toolsuites aren’t complete without a methodlogy to go with them. Thanks, Rational.) It’s all so completely hypocritical. As I mentioned earlier, VA Software the company still supports the open-source community in several ways. But there is nothing about SFEE that even remotely resembles open-source any more. With regard to their business practices, their pricing and their licensing, they are no better than the old-school vendors like Rational. They don’t practice what they preach.

I am not an open-source zealot. I recognize that there are many ways to make money from software. VA has a right to make money. But I am sure about one thing. Open-source code makes your product better, makes your code more secure, makes using your software easier, makes your users more productive and makes your customer relationshops stronger. Our current tool vendor sells us a software license, but once we’ve bought the tool, they give us access to the source with full rights to modify it for our own use. They don’t support the mods, but if we’re willing to risk it, we can. And that’s what I want. Heck, I’d even pay more for that. Why doesn’t VA Software, of all companies, get that?