However, dP is not without its flaws; indeed, I became so frustrated that late last week I asked my lead developer Ken Woodward to send me some examples of competitive systems that did not include BaseCamp. While BaseCamp is a great system, and probably amongst the top few project management tools out there, it’s not cheap, and we have a lot of projects running simultaneously. Plus, I am a constant advocate of OSS solutions, and in this situation, where many of my staff are student developers, having a locally-owned OSS platform that can be modified by my staff as they learn their trade is very attractive.

Let me note that I always feel guilty critiquing an OSS project, especially when I myself haven’t made any significant contributions to the code. At the same time, with increasing competition in OSS solutions, one has more liberty to leave behind that which doesn’t suit one’s needs. Further, reasonable explication of the features and failures of any system is valuable to developers who are committed to building and maintaining a quality system. So here’s a quick review of dotProject with some particular attention to the broken bits. My next post will introduce the alternatives that we are considering.

Here’s a list of dP’s strengths or notable features:

• user-based and password protected
• email integrated
• distinction between projects and tasks (you’d be surprised how many “project management” tools omit this!)
• robust data at the project level, with good hierarchical layout of tasks
• project tasks may be imported into other projects, thus “templates”
• calendaring
• task dependency
• good, flexible task logging and time tracking
• decent gant charts
• written in PHP
• themes

Now, a list of complaints:

No RSS. For my unit, RSS or Atom feeds are taken for granted. If I can’t put my task list on my Google home page, I’m not happy. RSS is easy to script, however, so we could add this feature to our To Do list.

Inconsistent task/to do list. I haven’t quite figured this out, but one’s “tasks” list is different from the “to do” list that dP presents. This appears to just be a bug, as the To Do list–which is actually harder to get to–is more accurate.

Some weird PHP scripting. For instance, project categories: one can create categories for projects, like “in planning” or “in progress” or “pilot” or “complete”. The problem seems to be that dP attaches a simple numeric id to each of these category names. It attaches the same numeric id to the projects in the category. Makes sense, right? Wrong. The category ids correspond to the order in which they appear as tabs in the dP interface; if you change the order, the numeric ids of the categories change, and thus no longer match the project categories. I’ve actually found several examples of similarly breakable scripting in the system (including a stubborn “masking” of certain projects related to this) but this was the most frustrating one.

Calendar/date entry is inadequate. In order to set a task due date to, say, December 2010, you can’t type 12/01/2010, you have to open the calendar GUI, then click, click, click, click through the months until you get to December 2010.

Little data available outside of gant charts. And the gant charts fail to react intelligently to clearly “inactive” projects, instead extending them perpetually as if someone were still working on it (even though no hours were logged). But really the main complaint here is that there is no simple, easy way to access data on staff or projects. For example, I can’t click a user’s name and determine how many hours they logged in dP this week. I can’t look at all projects of a type and get an average of hours spent to completion. I can get clear, individual project data from individual projects

Not embeddable, widgetizeable. Several project management systems have scripts, or embeddable widgets, or even desktop apps that help you monitor your tasks. dP does not yet. If they only had RSS, we’d be able to get somewhere. XML RPC? That’d be cool.

Average GUI. The graphical user interface in dP is average at best. It’s not horrible; it’s not elegant. It could be adjusted with a new CSS, but my experimentation with theming in dP is that too much can go wrong, and I’ve tried several themes that actually break basic features of the system! OK, so maybe I just need to spend more time on this, but compared to theming in Drupal or WordPress, dP theming is no fun.

Small community support. Though the quality of people involved in dP is great, the number of people developing, contributing, and using the system is a lot smaller than I’d hoped for. The last date of a major upgrade or bug fix was July 2008. I really want to add some of my staff to that community, but right now may not be the best time in the history of our organization.

So, we’re looking at other options–and I’ll review some of those next time–but I recognize that in the end we may stick with dP. If we do, it will have to be with a greater commitment to participate in the dP community, because several of these complaints I’ve listed simply can’t be allowed to stand, and its true we haven’t given much back.