ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Feedback on Why Fork (Task #107)

Added by Eric Davis at 2011-01-24 10:17 pm. Updated at 2011-01-29 06:35 pm.

Status:Closed Start date:2011-01-24
Priority:Normal Due date:
Assignee:Eric Davis % Done:


Category:ChiliProject - Organization
Target version:Public Launch
Remote issue URL:


I got some feedback on our Why Fork statement and I wanted to see what everyone thinks before I edit the wiki page. The main reason for the changes was that the reviewer noticed "a bit of personal frustration still came through, and while that's true, it distracts from your message that you guys forked because you are highly committed to as set of principles."

In the last few years, the free and open source project management system Redmine has grown in popularity. Its user-friendly, extensible and flexible nature has attracted thousands of projects, companies, organizations, and individuals all around the world.

However, in the view of some of Redmine's leading developers, the maintenance and evolution of Redmine has not been as predictable and responsive as its developer community is capable of. Integration of community-created patches was has been too sporadic, lacked a clear methodology, and was interfering with effectiveness of the Redmine project for clients. Over the past two years, several members of the developer community tried to resolve management bottlenecks through clear suggestions and contributions. They also attempted to broaden the development process. But efforts via public and private forums to discuss the goals and future direction with the project manager of Redmine met with no success. Unfortunately, this reform effort failed, as the current project manager apparently did not share these priorities.

A group of developers from the Redmine community has therefore concluded that the only way to ensure continued, sustained and stable development of and around our favorite project management solution is to fork it. We, long-standing community members and contributors, pledge to uphold the ideals of Free and Open Source Software ethics, governance and development practices in order to produce a reliable project management system released under the name Chiliproject in February 2011. The principal founders of ChiliProject are:

  • Names of signers...

We firmly believe in having a fully transparent and open governance and development process aligned with the ideals of free and open source software as outlined by both the Free Software Foundation and the Open Source Initiative. In particular we that a free and open source project:

  • Depends upon people producing useful software and supporting documentation, contributing as a team for the benefit of the community.
  • Reflects a spirit of collaboration and fun while garnering community feedback and providing good governance that allows for businesses to confidently invest in further development.
  • Is open to the participation of anyone who can contribute value and who is willing to work with the community.


Updated by Niels Lindenthal at 2011-01-24 10:47 pm

It is not easy for me to express this English but I try:

I know that everybody who gave so much to the Redmine community like you guys did are more than frustrated about JPL. Esspecially you Eric, who gave so much to the community. I am convinced that the reader should understand that we are disapppointed about the current situation.

Why don't we start by saying something nice about JPL and his achievements? He did a remarkable job. We are honest if state that in the beginning of the statement. We go on in the argumentation with the critics on the current situation and how we will improve the situation. The reasons why we fork are still the same but the critics might become a little more weight.

Updated by Wieland Lindenthal at 2011-01-25 11:15 am

I personally do not care about at all. What I want to achieve with ChiliProject is to get more contributions, more installations, more users, higher development speed etc. than we experienced with We believe that an open development process will help achieving these goals.

If you really want to talk about JPL then I would vote for Niels' suggestion to say something respectful about JPL's job first. He is not a bad guy.

Actually, we need to update our Wiki pages on goals, strategy and Mission as these are the key points people will discuss about.

  • I believe that these important statements are still hard to find and
  • that they are confusing, as they focus on the launch and not on the next year(s).
  • I believe that we should rename Mission by Vision. At least in Germany Vision is a more commonly used word than Mission. The latter sounds like a military term.
  • I believe we should separate Vision from Strategy and only link them, as the strategy follows the vision.

Let me know about your opinion. If you generally agree I will start changing the wiki accordingly to propose a new structure.

Further, I believe we should put some first feature suggestions for the 1.2 release to fill visitors of the with enthusiasm for the first hot release ("That's cool. Can I help?"). If we do not propose anything, then they might ask themselves "You fork but what do you actually want to develop so much better than before?"

Why not proposing feature candidates? The fist that came up to my mind:

  • Permissions
  • Usability and theme
  • Versioning
  • Updates to wiki functionalities such as media integration...
  • Maybe reporting on time entries and custom fields.

Ok, I better stop here. Let me know your opinion.

Updated by Joseph Potvin at 2011-01-25 04:15 pm

I think adding some respectful words about JPL is an excellent idea.

Perhaps delete: "But efforts via public and private forums to discuss the goals and future direction with the project manager of Redmine met with no success."

But keep: "Unfortunately, this reform effort failed, as the current project manager apparently did not share these priorities."

RE: Why not proposing feature candidates?

I was temped to add some here, but each should really be a ticket entry. I will try to add some suggestions soon based on our experiences with Redmine.

Updated by Eric Davis at 2011-01-26 01:25 am

Wieland Lindenthal wrote:

Actually, we need to update our Wiki pages on goals, strategy and Mission as these are the key points people will discuss about. ...snip...

Can you post these in a forum thread or issue? I want to keep this one on the topic of the Why Fork page. Thanks.

Updated by Eric Davis at 2011-01-26 01:36 am

Niels and Joseph:

I really don't think praising JPL in Why Fork is needed. Why Fork is a statement about the problem(s) with Redmine and why forking is the solution. We all appreciate JPL's work on Redmine but I don't think Why Fork is the place for it.


I'm reviewing a diff of your changes to the page now to see if some of the frustration can be removed from the original document.

Updated by Eric Davis at 2011-01-26 01:47 am

I've reviewed the revisions and applied to the Why Fork page. I think it's a lot less "frustrated" and feels more like the background history it should be.

Can everyone review the page now and see if it's any better? The original page was edit 5

  • Status deleted (In Progress)

Updated by Felix Schäfer at 2011-01-27 02:18 pm

Mmh, we had already tried to defuse things as much as possible, but I can live with the current version (version 7).

Updated by Holger Just at 2011-01-27 03:07 pm

I'm fine with the new version (as I were with the old). I only just fixed a few minor quirks which didn't change anything substantial.

Updated by Eric Davis at 2011-01-29 06:35 pm

Marking as complete.

  • Status set to Closed

Also available in: Atom PDF