Redmine

http://www.redmine.org/boards/1/topics/18986 has some good points.

Well... why should we try to rebuild all Jira Features?

We moved from Jira, as it uses many features which sounds like but were quite useless in production and just blow up the interface.

If users need more features than the base distribution, they can install plugins or build their own plugins on Redmine itself. This way users just have the features they really need and no bloatware (were a product is defined by its amount of functions not the amount of comfort).

Some features would be nice, this is true. But I don't get the point why a small group of persons should rebuild software from a big software company just to provide the same features for free?

It's a little bit like Photoshop and GIMP. I can use GIMP to get many features for free, but not all. If I need more, I can install a plugin for a specific function. But if I want to get blast off by an amount of functions, which I use in some small cases (maybe just 20-40% of the software), then I could move to a commercial software like Photoshop.

This is just my point. I'm not a fan of rebuilding something commercial one by one just to get into a competition which couldn't be handled with such a small user group. Jira has it's users and Redmine has it's users. If some Jira users won't stay at Jira, great, come to our product. If some Redmine users don't want to stay at Redmine, can't find a corresponding plugin and are not able to design their own plugin, well then invest some money to get a coder who will programm your plugin or move for even more money to Jira. :-)

Best regards,
Daniel

1. In my initial proposal, I stressed "either supporting it in core of Redmine, or through a plugin (set)". I'm surely against taking everything in core of Redmine. Even I think some of current core features of Redmine would be better organized as a plugin. (For example support for each VCS should be a plugin IMO.)
2. Developing features for a software and commercialization of the software help each other. I think of Redmine as a powerful competitor in its field that has the potential to be commercialized and compete aganist the best commercial products, such as Atlassian JIRA. I imagine great goals for Redmine. Of course if we don't set high expectations from our product, it will never fly high.
3. Setting great goals for Redmine and planning a roadmap to reach that goal, doesn't mean going through the whole roadmap at once. I'm aware that it is impractical to start developing all features of JIRA in Redmine right now. But we can explore features of high quality competitors and detect what Redmine has right now, what features it misses, and for each feature discuss and exchange ideas and decide if it should be developed or an existing alternative should be recommended to users, when to develop (popularity and priority of the feature), shall it go into core or developed as a plugin, ...
4. Keeping an eye on competitors lets you know your strengths and weaknesses. This knowledge is valuable in itself, for both developers and users, even if no new feature is going to be developed as a result.
5. I believe Redmine would have a brighter future, even commercially, with a real mid-term/long-term roadmap and a clear development process to revise the roadmap and develop Redmine based on that roadmap. Studying Atlassian JIRA features helps in developing a good roadmap IMO.