In the open source world, a good project can't just die or become worse because such projects always have a community ready to support it or take it over. If something goes wrong with a project its community can always make a fork. But the reason for making a fork can be just a wish to make the project better. Usually the appearance of a fork also divides the community, however, this does not make the fork or the project worse. In fact with the fork the original project gets a solid competitor—itself. And competition is what makes project developers strive for the best.
The history of open source knows many examples of forking and rewriting software what ends with the appearance of a new, better, or just different project. We do not need to search for such examples: Joomla was forked from Mambo, Gforge from SourceForge, X.Org from XFree86, Apache from NCSA, LibreOffice from OpenOffice.org, and many more.
You perhaps noticed that every page of Redmine contains a line Powered by Redmine © 2006-2012 Jean-Philippe Lang at the bottom. Jean-Philippe is the author of Redmine and its project manager but there were more people involved in this great project and one of them was Eric Davis. In 2011, due to project management concerns and community patches inclusion policy Eric Davis with some other Redmine core developers (most of whom are finnlabs (www.finn.de) employees) forked Redmine into the ChiliProject. This is how forking is explained on the ChiliProject site (https://www.chiliproject.org/projects/chiliproject/wiki/Why_Fork):
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 were too sporadic, lacked a clear methodology, and was interfering with the effectiveness of the Redmine project for its users. Over the past two years, several members of Redmine's community worked to resolve management bottlenecks through clear suggestions and contributions. They also attempted to broaden and open up the development process to more contributors. But efforts via public and private forums to discuss the goals and future direction with the project manager of Redmine failed, as the current project manager 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 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 of ChiliProject in February 2011.
Luckily at the moment Redmine and ChiliProject do not differ much so almost everything written in this book applies to ChiliProject as well.
So which one to choose? Let's discuss the difference now:
Having mentioned theme changes in ChiliProject 3, let's see what its new default theme looks like:
Some up-to-date information about differences in Redmine and ChiliProject is also available on the website of the latter: https://www.chiliproject.org/projects/chiliproject/wiki/Differences_Between_Chiliproject_and_Redmine.
You might expect features comparison in this topic. But theoretically features of Redmine and ChiliProject can be merged relatively easily into each other. So any features comparison here can become outdated when this book comes into your hands. So instead I decided to review different approaches these projects are taking. I hope this information is enough for you to decide.
Overall, ChiliProject seems to be in "transitional" period when its features, look and feel, design, and so on are changed and at the end of this period ChiliProject will turn into a completely different project management solution. Maybe it worth waiting for this period to finish but maybe it's worth helping the ChiliProject guys to move.
On the other hand, Redmine is a proven, stable solution, well-known, and well-documented.