Open source project management tools: is "free" worth it?

Why do not to try some project with free acounts? Something like this - http://www.5pmweb.com - the web based project management tools.

I tried a lot open-source project tools but no one I like it. I suggest to try on free accounts on web based project management.

I would caution with Frensis's comment. There is a huge difference between "free services" and OSS or FLOSS solutions. "Free services" make money in other ways. These ways may or may not be in line with your organizations interests. OSS/FLOSS solutions enable an organization to manage and control their information the way they wish.

These are two very different points. The "free solutions" are sometimes good - especially the demonstration versions that are fully functional. The 5PMweb solution, for instance, is based on 37signals tools. I cannot download that and run it on my Linux servers.

CJ points out, in my mind at least, project management needs to be better defined. It has different meanings to different people. What are YOU trying to do? What are the needs of the users?

My usual base requirement for choosing an open-source (or commercial) tool is that it you should be able to get the data out of it for use in other tools (or for later migration to better tools). Projects using an open database (e.g. MySql) for data storage are good because you can add your own data and queries. I like the web-based stuff because it works for clients on all platforms. Requirements will change over time so avoid painting yourself into a corner.

My last company had no project management tools in place, and didn't seem to see the need, so free and easy-to-use (web based) made it easier to roll out a demo. The company prior to that spent a lot of time on buying a new CRM system, but failed to consider integrating it with bug-tracking and project management.

I understand the question to be "How can I best manage the project of evaluating these options?"

My answer is "You do it the same way you do any product evaluation."

1. Know what your requirements are first. (If you don't know enough about the state of the art and practice in this area, then you have a whole other task to undertake before you get to product eval and selection.) Don't forget to include your users' input in developing the requirements, and don't forget to include soft issues (like learning curve, availability of training and support, product maturity, time to deploy and ease of migration from your current system, a believable roadmap for continued development of the product) in addition to hard issues (like available feature set and cost).

One way we try to make sure our requirements are well-thought-out is to write them up as if they were a Request For Bid. Any solution that meets the written requirements is, by definition, an acceptable solution. If you can imagine a product that meets your stated requirements but doesn't satisfy you, then the requirements aren't good enough yet.

2. Prioritize your requirements. We use simple priority categories: Critical, Valuable and Nice.

Critical includes "must-have" and "must-not-have" items; Valuable are "really want to have but could live without if we have to"; Nice are things we like, but that aren't deal-breakers. "Critical" is our initial acceptability filter; whatever doesn't meet our critical requirements doesn't make the short list. "Valuable" items are where most products try to distinguish themselves from one another, and where we spend the most time deciding what we like best or want most. "Nice" items come into play when choosing between otherwise equivalent offerings, and when selling the user community on our choice.

If you've got too many items in a category, prioritize them numerically, or subdivide the category. For instance, "Valuable" might be divided into "Valuable to PMs" and "Valuable to IT" or "Valuable / Ease of Use", "Valuable / Reporting" and "Valuable / Maintainability".

3. Survey the marketplace, find out what's available, and use your prioritized requirements to narrow the list to a set you're willing and able to evaluate. Make sure your survey includes commercial offerings, open source solutions, commercially supported open source. If your requirements don't specify one way or another, try to include in-house as well as externally-hosted solutions. I know you asked about open source, but determining if an OSS solution is "worth it" only makes sense if you're comparing it to the alternatives.

4. Develop a test plan to determine how well or poorly each offering rates on each of your requirements, and devise a rating scale for each feature so you can do side-by-side comparison of apples to apples.

Execute the test plan for each offering, and fill out your matrix of feature ratings.

6. If there's a clear winner, you're done. If there's no clear winner, then either:

a) break the tie with further testing and/or letting the vendors compete to make the best offer, or

b) it doesn't really matter, and you can safely pick any one of the tying winners. In this case, I recommend going with the one your user community seems to like best.

In all this, don't forget to involve your user community in the evaluation and to keep your management informed. Otherwise, you may face an uphill battle selling the decision, or worse, have to recapitulate the whole exercise because somebody in a position of power doesn't trust the outcome of your process.

I'm probably not telling you anything you don't already know, but perhaps this will help put things in perspective.