On Thursday, September 22, 2011 11:52:59 AM David Narvaez wrote: > On Thu, Sep 22, 2011 at 11:29 AM, Harri Porten <por...@froglogic.com> wrote: > > Don Sanders, one of the former KMail maintainers, had such a system set > > up many years ago btw. I couldn't find anything about it anymore > > online. But iirc it didn't work out too well... > > > > Harri. > > Just to clarify, I'm not strictly against bug bounties, I just > remembered I read that article recently and wanted to bring it to the > table. > > Now, here's an idea, I don't know if essentially different from > previous ones but we could discuss: What about funding bug squashing > parties and stabilization sprints? That's not exactly a "pay per fix" > model, but a way to sustain these activities which are very time > consuming. The main reason why I think this is a better approach than > plain "pay per fix" is that any given developer in the KDE project, or > any large FOSS project whatsoever, is not able to cope with the size > of bug lists and individual bugs (that is: some bug lists are larger > than life and some bugs are extremely hard to reproduce - and that all > comes before the fix) so I truly believe that if we don't attack > theses collaboratively, there's no way we can really try killing the > backlog. > > So what I'd love to see (and that's just me) are lots of distributed > bug squashing and stabilization sprints "Sponsored By SomeMediumSized > Co.", where funds can probably be managed through KDE e.V. or > something, but can ultimately be distributed by the organizer of the > sprint in the way she finds more useful. > > Notice that this is probably already happening, so I'm just maybe > pointing to an existing idea, because this seems to me like > https://sprints.kde.org/ with sponsors logos in each sprint box. > > David E. Narváez
This still is not necessarily transparent as you would still pay developers directly or at least induct money in the community. It is also a quick shot which doesn't solve the problem of maintainership as I understand you (maybe I got you wrong). I have seen the same problem (as many have done before me as well) some time ago (1). The mentioned problem is the lack of transparency or better the lack of separation of the community and payment. But payment exists already for enterprise clients with companies like KDAB or Collabora. Also SuSE and Redhat have introduced a service model which allows them to finance and cooperate with the community nicely. Yet they do that for the whole product and not for single applications. Maybe these or similar companies could create an subscription-model, where you take a subscription for the applications which are really important to you and can rate bugs and features as priorities. Since these companies are distinct from the community and developers working for them are identifiable as such, the drawbacks of a bounty model might soften. It would also guarantee that people finance a long term contribution (including maintainership of features) by subscriptions (each for a year for example). So for example I am a heavy photographer and I use digikam, I then will take a subscription of let's say 20$ monthly to get the features supported I need. I don't get an immediate guarantee that my features are done, but I can track what is done and the developers document their work and priorities. They have a strong interest to satisfy me, because otherwise I will stop my subscription. These companies can also hire either GSoC like junior developers or senior developers like Sebastian Trueg for some months and ensure maintainership with their own developers afterwards from the money. In contrary to single developers these companies have a strong interest in a good relationship to the community as they both employ developers from it as well as need collaboration to be successful. Christian (1) http://whilos.blogsite.org/?p=113 I don't back that position in this form anymore, yet a lot is still valid imo.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
