I've had a lot of talk at work, and speculated recently on the usefulness of a tool that would help manage projects for a single developer or small development shops.

It seems to me that there is a great business need for a tool that provides three fundamental characteristics that I have so far been unable to locate in project management software:

• Free and open source
• Effective without imposing itself
• Slick as we are

The first attribute is obvious. While there are tons of applications available on the web from service providers, they all seem to come with a price tag. Every web developer I know runs his or her own web site, and has a host that could probably run their project management tools -- if only an adequate open source tool existed that could be installed. Most of the hosted tools also have a stranglehold on your data, so if you wanted to move to a new tool, you'd likely need to start over completely.

The worst part of being closed source is that no generic hosted project management tool perfectly fits the bill for any freelancer or small company, and it's very unlikely that you can integrate changes into those hosted systems that would better affect your company's management style. This is related somewhat to being effective and not imposing.

I think that being effective without imposing is an important aspect of any project management tool. While there are probably some tasks in project management that everyone can identify as universal - estimation and issue tracking, for example - there are some tools that require you to commit to their own procedure to accomplish those tasks.

For example, FogBugz requires that every task has an owner. There are no tasks that are not owned by someone at any point in the project lifetime. This may not work well for development shops that want to use the Agile method, and pull stories out of the backlog (read "become the owner") to work on, because every task already has an owner. Another example of how this fails is when a client creates new tickets for a development team. The client typically does not know to whom a task should be assigned, yet by entering a new task and requiring an assignment of ownership, this burden falls on the client. And yet, if your process requires that stringent assignment of tasks to owners at all points in the task lifetime, your system should still have the flexibility to offer that. That's part of being effective.

On the "effective" side of things, there are a handful of project management tools that exist that have the basic requisite features, but no interconnection between them. For example, there is no direct correlation between estimated time, actual completion time, and reporting that brings those values back around for use in estimation.

In some of the open source projects I've seen for project management, they strive to emulate paid services, like 37 Signal's Basecamp, which could be sledgehammered into the mold of web project management process, but really don't seem to have been designed with that in mind. Good tools, all, but potentially not directly effective for the task of managing web development projects (especially in my opinion, which I'm sure some don't share). I think that emulation of 37 Signals speaks a lot to the "slick factor" of a product.

We web developers like our knobs and doodads. If I could reasonably code every UI to require the use of javascript (screw that "graceful degradation") I would definitely do so. So there are certainly things that we developers like to see: In-line editing and Ajax being foremost in my mind. And sure, while an application should concentrate on working for its least common denominator, there are some niceties that are required for ease of use.

I think it's not exactly easy to produce project management software no matter if you use cool stuff like Comet or Canvas, but it's certainly easier to produce something without it. I think that's why teams with payrolls (hosted project management) can afford to produce lavish interfaces, and why the open source offerings generally don't look as spiffy. Really, I don't know the real cause. Nonetheless, the fact exists that I've appreciated the design of for-pay sites much more than those of their open source brethren. I'm not just talking about the aesthetic appeal, but the usability; the interface engineering.

If it were for these three reasons alone, I think that would be enough to call for a new plan for a project management tool. I could probably rattle off a few more reasons that a new tool is a good idea. Moreover, I'm not concerned that the marketplace is competitive, simply because even after searching seeming forever (recalling my initial posts about Copper Project four years ago) I haven't found one that works the way I like.

Project Objective

I doubt this part will stick completely, because I have some things I need to do first to make it work (attract working hands and produce user personas, for a start), but I'll record it here because it needs to be done as a diving point.

The objective of Stonepath is to produce a free, open-source project management system for individuals or small companies, with the following advantages:

• Provides a centralized, searchable system for storing project-related materials - including initiation documents, specifications, wireframes, graphic designs, etc. - accessible to any stakeholder with deference to security.
• Allows all stakeholders in a project to track progress of the project according to their needs. (These needs will need to be spelled out after the user personas are created.)
  • Issue tracking
  • Time tracking
• Centralizes communication regarding a project into itself so that it can be scheduled (if required), recorded (if possible), and searched.


• Schedules and coalesces dates across projects for a bird's-eye view of all required milestones.


• Presents a view of capacity for production that is useful in planning for both developers and managers.


• Passes high standards of usability in terms of the ease of accomplishing tasks.


• Produces reports that are useful for accounting, and also for contributing developers to see their own progress and enhance their abilities.


• Hints at a flexible, intended procedure for accomplishing project management using the tool -- one that can be strictly enforced or completely ignored without degrading the product execution.

There are two additional components to this initiation document. First, is a timeline. Timelines on open source projects are hard to say. I'm not going to skip it, but I'm going to wait for the next post.

The second component includes the list of stakeholders and their roles. This part should be interesting, and I'll also be holding this one for a future post, since it will likely incorporate some of the ideas I have had lately about the management of a new open source project.

This document is open for comment. I've probably missed some very important points, so indicate where I've gone wrong and I'll see about updating it.