Redmine

I don't think any of the "core" developers of Redmine are currently accepting any bounties or payments for developing features.

In general, this is quite a complicated topic for which a lot of text has been written already, covering various opinions across various projects. Some reasons however, why many people do not accept payments for open-source contributions (either within Redmine or in other projects) are:

• Taxes are complicated. As any form of meaningful payment quickly involves taxes, this can quickly spiral into being a full-time accounting job (esp. when involving international payments), besides the hobby of working on Redmine's code and the main bread-winning job of people.
• Working on Redmine is a hobby for most developers. Payments (and the associated expectations and pressure) can quickly suck all of the fun out of it, making it just another (badly paid) job.
• Each feature accepted into Redmine comes with the responsibility of having to maintain it indefinitely. This is often a lot more effort that just developing the feature in the first place. That's one of the main reasons why some features linger without being merged: they are complex, affect "inner" areas of Redmine, might have some side-effects or edge-cases which might cause issues for some users and result in a high maintenance effort, or a just too special or niche. Often, a usable workaround in this case can be to maintain a plugin instead.
• Accepting payments for certain features creates the (rightful) expectation of the people paying money for it that their pet-feature is actually finished, works, is maintained, and is well-integrated. This can quickly cause a conflict-of-interest where you have to decide between merging an (unfinished) feature to please your "customers" or holding back because the feature may be ill-advised, doesn't solve the actual problem, or results in additional problems on its own. This is a huge issue that many people try to strictly avoid, specifically by not accepting any money. This allows us to justifiable point to Section 11 of the GPL without accepting any undue responsibilities or expectations on our part for the time we happily provide for the benefit of the community in our spare time.

As such, while it is true that the Redmine project might appear to be slow or unresponsive at times, I don't think this is something which can be solved by throwing money at the problem. Instead, things are likely only to improve if people provide meaningful contributions on their own. Yes, I know that it can be very frustrating when things move slow or people appear unresponsive (I really do and have the "war stories" to back this up), but many of the people working on Redmine are already spread thin and are doing the best they can within their own constraints to improve Redmine. Redmine is not so different from other open-source projects in this regard after all, especially those projects which are actually supported by a community of people rather than some corporation which just uses their software as a sales tool for support contracts or shiny upsells.

With that being said, for the specific issue you have linked to here: this is one of the areas which would cause a lot of follow-up edge-cases to be resolved, e.g:

• to make preceded/follow relations time aware
• to make the reporting time aware
• add times to other areas (such as versions)
• adjust the Gantt chart to meaningfully display inter-day time-frames on tasks and versions
• how to handle moving issues between projects
• investigate how this changes the project work within Redmine and apply the necessary changes to support this
• investigate how this affects the software interfaces and possibly breaking plugins
• ...

As such, this is a prime example of a feature which looks simple and might even have a (rather) simple patch to implement a first working change. But there is a lot of follow-up work to be done here which would require a huge amount of work from the maintainers and would likely frustrate many users because of "unfinished" features.

And with that being said, I personally believe that this feature doesn't even add much value anyway. While some people believe they want to plan their tasks to the very minute, I think this is an anti-pattern and does not improve the project planing or ability to resolve tasks. Instead, it just adds another time-sink for micro-managing and running-behind-reality which doesn't improve real-world projects. Instead, it's generally a much better idea to have a list of tasks planned for the day (or even just upcoming days) and work on those. The specific time to solve those often doesn't matter or can't even be accurately planned.

In #5458, the original motivation was to validate service-level agreements which do often require a response within certain time frames. However, I believe this could be solved differently, e.g. by adding some rules to alert if an issue is not closed or resolved within a certain timeframe, or if there was a reply of some sort. With SLAs, an important aspect would be the reporting (i.e. which of the specific SLA rules were met, and which were not), as well as features for alerting and escalation, both of which is not attempted by the patches in #5458 at all.

Thus, I believe #5458 solves the wrong problem in a way which adds a lot of complexity to Redmine and project managers without providing meaningful benefits to warrant this complexity. The idea to provide some support to handle SLAs in Redmine should be solved differently in my opinion.

Thanks for the feedback.

I generally agree with all the points you make but I don't think that these arguments eliminate the case for bounties and crowdfunding. These points simply suggest that people should set a higher budget and maybe keep some money in reserve for regressions that appear within 3 to 6 months.

On the topic of plugins, I agree that creating a plugin is always better than modifying the core project. In turn, the plugin API needs to be extremely stable between major releases. Otherwise a whole bunch of plugins vanish each time the API changes.

However, I feel there are some specific cases where modifying the core project is necessary. For example, if there was agreement on the request to have deadlines that include both date and time probably needs to be a change in the core project. That feature could not be provided with a plugin. Doing this for a field that is used so widely may break some plugins, so it contradicts the point I made in the previous paragraph but nonetheless I feel it is important.

On the arguments you make regarding the need (or lack of need) for that feature, could you please include your comments as a comment in the ticket itself and I will respond to those points there?
https://www.redmine.org/issues/5458

The question that arises then is how to collect the right amount of money and share it around fairly