https://www.redmine.org/https://www.redmine.org/favicon.ico?16793021292018-10-12T00:47:40ZRedmineRedmine - Feature #29758: Introduce optional pay per feature model of Redmine developmenthttps://www.redmine.org/issues/29758?journal_id=879612018-10-12T00:47:40ZGo MAEDA
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/13853">Feature #13853</a>: Is it possible to sponsor the implementation of features?</i> added</li></ul> Redmine - Feature #29758: Introduce optional pay per feature model of Redmine developmenthttps://www.redmine.org/issues/29758?journal_id=879762018-10-12T23:54:54Zcrypto gopher
<ul></ul><p>Regarding the related <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Is it possible to sponsor the implementation of features? (Closed)" href="https://www.redmine.org/issues/13853">#13853</a> I would like to emphasize crucial differences between idea explained here and the answer given in <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Is it possible to sponsor the implementation of features? (Closed)" href="https://www.redmine.org/issues/13853#note-5">#13853#note-5</a></p>
Solution proposed in <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Is it possible to sponsor the implementation of features? (Closed)" href="https://www.redmine.org/issues/13853#note-5">#13853#note-5</a> mentions hiring Ruby consultant by interested entity (user or company) and going through the process of implementing feature by himself. While it is a valid solution it suffers at least these 2 <strong>weaknesses</strong>:
<ul>
<li>the <strong>cost of creating feature is placed on single entity</strong>. The problem I see here is that many times cost (in terms of money, but also time required to go through the process) for the single entity can significantly exceed potential profits. Thus such solution may be economically unjustified.</li>
<li>particular <strong>needs of single entities that could finance development of some features may not overlap with the needs of wide community</strong>. That's why I think that there is significant risk, that such code will not be accepted into Redmine. That in turn will encourage entities to either keep their code for themselves or put it into plugins. Problem with vital features implemented in plugin is that one cannot safely rely upon them in longer term (maintainability).</li>
</ul>
Proposed solution has following <strong>advantages</strong>:
<ul>
<li><strong>allows to distribute cost between many interested entities</strong>. Some of the most wanted features have tens of proponents. Just 10 of enities willing to support particular feature make entry barrier one order of magnitute smaller.</li>
<li>besides providing financial incentive, <strong>voting with tokens will provide information regarding popularity</strong> of particular feature. This way developers can both optimize for most frequently wanted features and avoid implementing those least requested.</li>
<li><strong>freedom of choice of what to implement and what not is retained</strong> in the hands of Redmine developers. All votes on unimplemented features go back to voter sooner or later.</li>
<li>most of the development <strong>work can be done by competent people</strong>, already knowing Redmine internals best.</li>
<li>last but not least I predict it may introduce some <strong>gamification</strong> elements into development process. It may be not only rewarding, but also fun.</li>
</ul>