Introducing ChiliProject – A community fork of Redmine

Long-term members of the Redmine community have launched ChiliProject, a fork of Redmine. Redmine is a widely-used open source web-based and project management system built with Ruby on Rails. The ChiliProject objectives are to provide innovative new features, extend interoperability, and build a broad user community. This new project also strives to be responsive to user requests, have a transparent development and governance process, and to grow a diverse developer community.

ChiliProject will be fully compatible with its predecessor at launch and will continue to be released under the GPLv2 license. It will retain all the existing features of Redmine and add new features requested by the Redmine and ChiliProject user communities. ChiliProject recognizes extensibility to be a core-strength of the project. Therefore the project is aiming to build a modular and extensible core while providing strong support for integration with third party products using a standardized application programming interface (API). ChiliProject will also focus on improving the usage experience for large and complex environments.

The first stable release is scheduled for the end of February and is expected to be fully compatible with Redmine 1.0.5.

ChiliProject is actively looking for additional contributors and community members.

For more information about the project, go to, email, or join us on our IRC channel on Freenode #chiliproject. If you are interested in finding out more about why the ChiliProject has forked Redmine, please refer to our Why Fork page.

About ChiliProject

ChiliProject is an open source web-based project management system. It supports your team throughout the project life cycle: from setting up and discussing a project plan, tracking issues to reporting work progress and collaboratively sharing knowledge.


  1. Guest says:

    But why?

    What are the reasons for the fork? I thought forks were usually used to continue a project where the original maintainers had abandoned it or there was a large difference of opinion between members of the community.

    You are one of the main devs of Redmine with commit access and I don’t know of any problems. Could you explain your reasoning for the fork?

    • Guest says:

      Have re-read the post properly this time and found the link at the end. In all honesty I am not sure these problems were worth a fork since it seemed mostly like administrative and management which is, well…you guys ARE the administrators and managers aren’t you?

      • edavis10 says:

        Two of us were part of the core group of Redmine but even we didn’t have full access or the ability to make many of the changes that we are doing with ChiliProject.

  2. Dustin Rue says:

    I actually don’t get the fork either and as an end user I’m surprised to see it. It would be great to have further explanation as to why it was forked because right now I’m not getting it and it makes me wonder which project to track.

  3. Guest says:

    Just yesterday, I was reading about the history of RSS and Atom formats. I definitely think forking is the right way to go.

  4. Damien says:

    Well I dare to give you an advice that could help the Chiliproject to succeed.
    Search for Redmine issues that have not been resolved but which have lots of +1 (the best I remind are the ones I’m watching like: assign issue to a group, templates for issues, etc).

    Most of them have already patches to fix the problem, easy work.
    Most of them are features that companies and real large projects want.

    If you keep following Redmine mainstream by adding code for the named issues for some time, I bet you’ll have a lot of switchers ;-]
    If you differ too quickly from Redmine, switching will be harder …

    Good luck !


    • edavis10 says:

      Exactly. I myself have a few open issues on that I have patches for that I never got enough feedback to integrate (assign issue to group) and a few that were only partially added (subtasks). We have a field on to track if there is a matching Redmine issue, that way both projects can share the code.

      As far as changing things from Redmine to quickly: our first release is planned for the end of the month and should be very compatible with Redmine. We will maintain that release for about 6 months so there will be plenty of time to migrate and switch over. Our next big release will get all of the major features and that will have actual differences (though we might add some compatibility layers too).

Comments are closed.