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:
- Of course, Redmine is older. It has been proven to live, to survive and be successful, its developers were active over five years and continue to be (besides Jean-Philippe there are Toshi Maruyama, Etienne Massip and others), it's stable.
- Redmine has a bigger community than ChiliProject. But this does not mean that ChiliProject is worse though, most users have not moved to ChiliProject because they see no reason. Such a big community is mainly due to age. However, this means that most likely you will get support for Redmine faster.
- Redmine comes in Bitnami, Turnkey, it is available in official repositories of Debian and Ubuntu, it is available for hosting at Plan.io, HostedRedmine and more. But again it's mainly due to its age.
- Redmine does not get changed much, it feels like a well supported software with major changes coming rarely (except 2.0.x which moved to Rails 3 but it was a developers' headache, not a users'). By changes, here I meant functionality and UI changes, which required users to update their third-party tools or get used to.
- ChiliProject, on the contrary, introduces major changes with each major release. It feels like ChiliProject developers finally have a possibility to implement things they've wanted for a long time. However, these changes add much work for developers of third-party tools and many things should be learned by users.
- ChiliProject promotes openness of development process and readiness for contribution. If you or your organization plan to modify the core or you just feel you or your organization can do this and you are ready to share your modifications, you should consider using ChiliProject. To some extent ChiliProject is for enthusiasts and advanced users.
- ChiliProject lacks a good plugins registry which is available for Redmine, it has only a plugins compatibility list. However, Redmine plugins registry is far from being perfect (for example, it's incomplete and lacks some search capabilities).
- The situation with themes is even worse: Redmine has many themes but they are not compatible with ChiliProject anymore since Version 3.x of the latter. ChiliProject 3.x does not seem to have any third-party themes available (ChiliProject prior to 3.0 worked fine with Redmine themes).
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.