Please opensource Pivotal Tracker

Thanks for replying, Mike.

This suggestion isn't about any one particular feature that is missing. It's more about putting my company's trust on a product I have no control over. So if, for some reason, Pivotal discontinues Tracker, I have no hope that the community (along with myself) will be able to continue its development. That would be a great handicap to my development process. Data portability is more than being able to export and backup my stories. It's being sure that I can take it anywhere and still have the software to use it. That I won't have to shoehorn the data into a similar-but-different tracker, adapt my development process around the new tool, retrain my staff and rewrite all custom extensions I'd written for Tracker. So for me it would be a big economical liability.

As for features, even though I can suggest them here and I know you guys pay attention and do your best to implement them, it's another thing I'd have to be dependent on. If I need to change the API myself or do any sort of adaptation, I'd have to suggest it, wait for it to be considered and implemented before I had it, assuming it would in fact be accepted. And, since your resources are limited, I can't have any guarantee on how long that would take. I'd rather implement it myself or have someone do it for me and contribute my changes back.

These are concerns I've heard from many people, and addressing them by opensourcing PT would greatly increase adoption, while keeping many viable and very lucrative business models open to Pivotal. ( Delete or Edit)

Helder, we want to secure your trust and get your company using Tracker, so here's the situation.

First off, Tracker means a lot to us and it's not going anywhere. We use it for essentially all of our Pivotal client work.

Secondly, there are indeed a lot of features that people want to build, and we're wary of that. Products with too many features quickly become unusable, confusing, or even counterproductive. Developers may be able to use Tracker well; but remember that we're aiming to make it also work comfortably for team members with considerably less technical experience.

Take an example like story dependencies. There are several ways we could implement this use case. If we choose one and establish it, then we can go ahead and add a couple convenience features to further enable that pattern. If, on the other hand, three to five alternatives were produced by the open source community, the burden of figuring out which was least likely to hurt you in the long run would be distributed to all our users rather than handled by us.

We appreciate the suggestion and it is in many ways a good and exciting idea, but it's not appropriate for this product right now. ( Delete or Edit)