Friday, November 20, 2009

Why open-source project management tools do not flourish?

Unlike other open source tools, the open-source project management (PM) tools are miles behind from their commercial counter parts. I have always wondered why? Most of the projects have very low development activity, if at all. Did you wonder why too? Recently, I attended a DC Scrum user group meeting where we were discussing why we chose the tools that we are using to manage our Agile projects. Suddenly, I had this "aha" moment.

If we think about it for a moment, we will realize that we all have different ideas as to what to expect from a PM tool. We all know what some of the core features should be, but we most likely would disagree on how to go about implementing them. These differences are not technical in nature. We can be very opinionated about the details of these requirements. It is like choosing what to ware. As a result, most project management tools embody the view of the development team, the product owner to be specific. As a user, we choose the one that most closely matches our view of the world. Even if we somewhat like one, we would move on to something else and would not have the patience to wait for the tool to catch up to our taste. We act like we have ADD when it is about choosing a PM tool.

Since these open-source projects do not have a passionate product owner, there is no single ownership of a cohesive view to pursue. As a result, a developer will start working on implementing one because he has this unique idea about what this PM tool should look like, but will find it difficult to have other developers to agree with that view. Worse, he will find it even more difficult to find users who will like his view and support his effort by actively using the tool. Heck, even the developers would not use their own tool to manage their project. We know an open-source project would need an active user base to sustain and flourish.

The only way to have a project management tool to survive is a team's persistence with the tool in the early stage of the development. This is only possible in the commercial world. Each of these companies are pursuing their unique vison of what a PM tool should be in the hope that there is a large enough user base (who subscribes to this vision) to sustain their development. Thanks to all these companies sticking to their guns irrespective of the diverse nature of a very discerning users group (that is us).


  1. You brought up a very important point, developers develop such tools based on the how the perceive the PM tool, and not how it should be.

    Additionally, and more importantly IMO, support and trust. Companies need to deal with a software that they now it's supported, and they don't care about paying money for having this service.

  2. if you constantly transform your world of work, I suggest you'd keep the basic framework (Agile) but adapt your tools as well. So either you evolve them on your own or have an excellent tie to your flexible tool supplier.