Good question. It really depends what how Redmine is currently used. I consider the project's roadmap to be one important reason. This community is working hard on several promising features such as additional permissions, reporting-engine, UI and usability improvements, additional data security and privacy settings, milestone journal just to name a few.

Well, currently the answer would probably be that our primary goal is to opening up the project to the community. We are working on having a much more open governance and decision process and try to actually talk about what we do and have planned. That way we want to have a faster and more focused development process.

As we have not yet started to work on the actual code, we don't have to show much in this regard yet. The major goal for the 1.1.0 — Bell release is to pull most of the changes between Redmine 1.0.5 and Redmine 1.1 into ChiliProject while reviewing them. That first release will be very compatible to Redmine itself and will act as a starting point for the project. In fact, we are going to provide a broad migration support.

The next releases (see the Release Schedule) are going to be the first incorporating major new features. Currently, we are still working out what those features are (Niels named a few of them) and how they fit into a proper roadmap. But we have many promising ideas and code in our backlog that is eagerly awaiting to be merged into a great product.

What this all means is that we try to listen to people and use community contributions of code, documentation, or support to advance the project. We want to be open with our goals and decisions. Everyone is invited to participate. That is also the essence of the first FAQ entry to that topic. So if you have an idea how ChiliProject could become really awesome, just let us know :)

--Holger

why can't this be done within Redmine project boundaries? splitting efforts between two projects is never a good idea. it's not like there's a whole bunch of developers who 1) know Ruby 2) are willing to work on these open-source projects...

I disagree that it's never a good idea; the reasons for this fork seem almost identical to those stated by LibreOffice. Considering that the core developers here seem to have "retired" from Redmine due to differences w/ JPL, I doubt there was much more in the way of significant contribution they would have made to the original project anyway.

well, maybe it's possible to just change the license, replace the original developers with the new ones and keep working on Redmine?
if the original developers don't have interest in this product anymore, why would they object against this?

my concern is simple: let's say, there are 6 developers total who want to work on Redmine on a regular basis (others don't matter). if half of them start a new fork, the development for both Redmine and the new project will be slow.

Alexey Java wrote:

well, maybe it's possible to just change the license, replace the original developers with the new ones and keep working on Redmine?

That would have been an option but some of the original developers on Redmine still wanted to work with it.

my concern is simple: let's say, there are 6 developers total who want to work on Redmine on a regular basis (others don't matter). if half of them is starting a new fork, the development for both Redmine and the new project will be slow.

That seems logical but speaking as myself: since I had to leave Redmine my choices were to either:

1. work on a fork of Redmine
2. start a new project from scratch
3. stop contributing to Open Source completely

Since I didn't want to stop working on Open Source (3) and I didn't want to reinvent something that already exists (2), participating in a fork was the best option for me.

So it's not a matter of splitting developers, it's a matter of developers leaving completely or developers working on something else (that is also compatible).

Eric Davis

I just moved my redmine work to AWS, which I am pretty new to. Will I be able to install Chili to aws? I will go look for howtos on pulling git into aws , since I like the way you guys are headed . . .

Alexey Java wrote:

well, maybe it's possible to just change the license,

"Just" changing the license is not possible because there is no clear track of all contributors over time nor a clear rights transfer to a single entity. Anyway, we're not unhappy with the GPLv2 (current license), so that's not the issue here.

replace the original developers with the new ones and keep working on Redmine?
if the original developers don't have interest in this product anymore, why would they object against this?

Again, the point is not to replace anybody, neither is anyone's interest in the product an issue. We believe the development and communication of an open source project should be open and have tried building a community around Redmine (which succeeded to some extent or we wouldn't be here), the original developers/project lead didn't seem interested in interacting with the community or increasing the community participation in the project though, so we decided to fork to be able to work on it the way we think is best for us and the community.

I'll watch with great interest the evolution of Chili.
We're not at all dissatisfied with Redmine and we believe it is a great software but I've started to think that Redmine needed a different management style. Let's see how Chili evolves.

• Existing plugins, compatibility with Redmine plugin base
• How the project deals with community feedback and contributions. Redmine project has not been specially strong on this.
• How buggy the stable versions happen to be. Recent Redmine versions were too buggy for my taste
• How it addresses specific needs our project leaders have:
  • Better notification system
  • Wiki-Editor that offers WYSIWYG
  • Integration with document management products such as Alfresco
  • A better, more powerful administration interface
  • And a more flexible way of granting access to issues. Already discussed in Redmine issues: 2653 and 337
• How it evolves to address scenarios like ours: a large base of interrelated projects under the responsibility of different departments delivering/maintaining software applications for internal customers. Because I think the main focus in Redmine is managing non-interrelated projects

Pedro Gutierrez

I work for the software department of a local public institution and we've been using Redmine, in production, for a year now hosting 100+ internal projects, contributed with plugins (well, only one: Xapian search), patches, collaboration in the fora... the usual stuff. We have 1.0.5 stable installed right now