Re: roadmap status update/update request

Eugenia Loli-Queru wrote:
allow voluntary up front contributions but the user chooses which bounty to attach it to so popular stuff quickly builds up into big bounties

At first sounds good, but there is a problem here:
Quickly, a casual user will need to pay more than he would normally pay Apple or MS to buy their products every 1-2 years (and I must say here, I get way more new features each year with new Mac OS X versions than I get with Gnome's timed releases). For example, for my 20 feature requests I might need to pledge around $1000 for all of them. While this is still extremely cheap considering that consultant work is about $200 per hour in US, we still talking about OSS which should be cheaper and be more friendly to "customers", aka users. Also, this gets quickly very expensive for the users and the whole thing is bound to fail.

not at all because it would be volountary - bounties are optional but its always nice to say to a screaming user "put your money where your mouth is" :)

P.S. I expect the biggest contributions will come from businesses not users anyhow

And this brings me to the second point: I would not like to see a bounty be more than $2000, no matter the feature's complexity. If we get 5-6 features ending up having crazy amounts of money in them, even if they are trivial to implement, we end up with these two new problems: 1. Other features that might really need fixing will get "forgotten" because there are no bounties on them, or the bounties are too low. 2. Might create a new standard of how gnome works and developers would refuse to code for something without getting paid. It might sound stupid now, but if this bounty thing works, that's what will devs expect in the future, by default: money.

I agree an upper limit would be sensible - really complex tasks (stuff that would take more than a weeks dev time) should be split into seperate smaller tasks with seperate bounties.

I disagree with the money or nothing attitude that some devs might acquire (for a few it might be true) but I will happily fix something that personally bugs me or implement something I consider to be a must have for free and I expect thats true of most contributors. We already have paid and unpaid devs so I dont see anything bad happening as a result.

What I am trying to say is, that "auctioning bounties" are _dangerous_ to the Gnome project. Instead, if a fixed amount of money is given by people every year and then the Foundation distributes some of that money to most active developers, I think it would be most cost-efficient for both users and the project without the dangers of having the devs working for money alone. Every 3 months, the Foundation would release activity logs (in a "glorious top-20" kind of thing) and share the money accordingly. This would get the devs motivated instead of having them thinking "I don't want to work for annoying users for only 1000 bucks". Also, there would be the actual competition between developers, which can also keep them motivated.

It would be too predictable who would win here - the devs who are already paid to work full time on Gnome!

Anyhow it defeats the real purpose - we need to attract more developers casue the current ones are way too overloaded to implement tons of new features and yes budding young devs should be able to earn a living off user contributions afterall why should they have to find employment elsewhere when their skills could be utilised full time implementing your 20 features (I doubt the devs who are already paid to work on Gnome will have the time to claim these bounties)

To me the bounties are simply a contract to do some work and the value of that contract should be driven by market forces (ie user donations on specific bounties) and not by the Gnome Foundation which assigns money on how complex a task is and not how popular it is (which is why they have failed in the past).



desktop-devel-list mailing list
desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]