Developer payment/Arguments for and against payment

See also Gift or exchange for some thoughts.
See Developer payment poll for a poll proposed to developer on the topic.

A system for payment of MediaWiki developers was first proposed by User:Eloquence, to increase the motivation of editors to carry out some development tasks which they might otherwise not do or might do in a different order than desired by the Foundation (Coders have to pay the rent too). Supporters hope that such a system might help to get some essential development done. The term "bounty" has been used to describe this.

As of 24th of July, the bounty system is only a proposal, and this proposal is made for developers only. A meeting was held on IRC (see log and Foundation website meeting, July 2004), discussing the Wikimedia website. During that discussion, it was suggested to that editors be polled to help the board decide whether a bounty experiment should be tried.

During that meeting, Erik suggested that two key development tasks which could benefit from a bounty could be:

internationalization on unique website (meta and wikimediafoundation)
database redesigning

It has naturally been mentioned that bounties could expand to other tasks as well as development. Also that we could pay external people to do such tasks for us, if we did not have this expertise ourselves.

Though this page is under "bounty", I (user:Anthere) wish to expand it to more generally answer the question should there be a way to reward developers? If so, which are the possible ways ?

Three steps were suggested:

Everyone (developers included) will list here proposals for possible ways to reward developers. Developers will consolidate that list according to what would interest them.
A general public poll will be made to check public perception of bounty or other potential reward systems.
Developers will be privately polled and welcome to give their opinions on the matter.

Please list propositions and arguments below.

Anthere 01:03, 25 Jul 2004 (UTC)

See also the related threads on wikitech-l and foundation-l.

Summary of propositions

Employment (full time, or part time, one of the current developer or someone external to the project)

Bounty system. Wikimedia would advertise that it needs some task done, then interested parties would enter some kind of negotiation with Wikimedia with the aim of finding a mutually agreeable contract. Once a contract is formed between the developer and Wikimedia, payment is assured as long as the developer completes the task within the defined timescale. Wikimedia would not be able to terminate the contract at will without payment, for the purpose of giving the contract to someone else or otherwise.

Set an "about us" page listing all contributors to the code, especially the most active and prolific contributors. The page had short bios (written by programmers themselves). Make such a page linked from a prominent place. Let the opportunity for each developer to set a donation link from here.

Discussion

My position on this is that I'm not interested in coding for bounties. If the foundation wants me to do something, they can employ me. I know some people are attracted to the bounty idea for tax evasion reasons, or because it's exciting to be competing against other developers for a prize, but I'm not interested in the first and consider the second to be an inefficient use of developer time.

I'd go on to say that paying me to work for Wikimedia would only change my priorities, not encourage me to do more work overall. So I would spend less time on the performance and quality features requested in my feature poll and more time working on the Wikimedia website. For that reason it seems as if Wikimedia money would be better spent on someone other than me. Erik in particular has said that he would work on MediaWiki if he were paid for it.

I do a lot of work for Wikimedia projects and I have no moral qualms about receiving a financial reward. I can receive donations via paypal. But I'm not going to try to trick the Foundation into spending money on me when objectively I would consider this unwise. -- Tim Starling 04:49, 25 Jul 2004 (UTC)

"I would spend less time on the performance and quality features requested in my feature poll and more time working on the Wikimedia website"

@TimStarling: If a developer is getting paid by an employer, then the employer will set the priorities. -- User:Johnywhy

Disclaimer: I'm not a developer on MediaWiki so the outcome of this discussion doesn't affect me. On one hand it's good, because I'm partial. On the other hand it's bad, also because I'm partial.

I think it's a bad idea. There's a fine line to walk. On one hand it can be expected that some people will work on WikiPedia code only when paid therefore offering money will attract those people.

One question is: do you really want people whose only attachement to the project is money?

The other question is: how will you avoid alienating those that are willing to work for free (especially those that have already invested incredible amounts of time and effort into WikiPedia code)? What if more people working for free will leave the project than the amount that will join the project because of the money?

There are psychological studies showing that extrinsic rewards (i.e. money) aren't very good way to motivate people to do a good job, especially on creative work (as opposed to purely physical work). Basically the message is: people aren't as motivated by money as we think. See [1], [2]

It's also bad because it sets a bad precedent. Open-source and WikiPedia work quite well because people involved understand that all their work and contribution won't be rewarded with money. A self-selected community of unpaid volounteers emerges. The moment you start offering money to selected few, you pollute the community and risk damaging it forever. You have to think about that risk.

And finally: isn't there a better way to attract contributors?

One idea: increase ego-dollars to developers. On some open-source project (don't remember which one) I remember seeing a prominent "About us" page listing all contributors to the code, especially the most active and prolific contributors. The page had short bios (written by programmers themselves, I suppose) along with a picture (also supplied by a developer). Make such a page linked from a prominent place. It certainly won't hurt.

Another idea: improve development process and make it easier for new people to join the project. e.g. have an up-to-date list of things to do and (i.e. roadmap).

In summary: do not create a bounty system. It's a risk. Currently things aren't that bad to accept that risk. Krzysztof Kowalczyk 05:23, 25 Jul 2004 (UTC)

Let's assume talking about editors instead of developers. I offer an award of 10€ to the person that writes an article for every red link on http://de.wikipedia.org/wiki/Liste_der_Burgen_in_Deutschland . You'll say "This won't work, one person can't write all those articles, it's a community project."

The same is true for MediaWiki. One can split the bounty, but there's no fair way of doing so. People might become jealous. People might submit code that is not usable (e.g. due to performance issues) but is solving the task the bounty was offered for. Will you pay or not?

Our editors work on Wikipedia for fun. The coders do so, too. Most people can't see the fun in writing encyclopedia articles. And even more people apparently can't see the fun in coding.

Speaking for myself, I've a good job and am well funded. I know some of our other coders are still students and are probably rather short on money. Due to this, I would not work on a bounty task, if bounties were offered.

How big would a bounty need to be to attract new coders? One needs 6-8 hours to learn how the code works. 10 hours to implement a feature, 8 hours to fix bugs. At 20$/h this would be about 500$.

Spend the money for servers. That's a better use of our funds. -- JeLuF 10:12, 25 Jul 2004 (UTC)

Agree with Krzysztof Kowalczyk and JeLuF. I've been coding for Wikipedia for well over a year almost daily and long hours, spent probably more time on it as on my day job, which is 28 hours per week. (International Statistics, TomeRaider version, EasyTimeline). All of this out of sheer enthusiasm for a community which proved that idealism still can still get things done. With a bounty system we will get on a slippery slope, in the foreseeable future wages can only be of symbolic value (unless we outsource to India of course), and that symbolism can turn against Wikipedia. It might turn coders from "if nobody else took up this job I might make a difference here" to "if nobody seems to value this enough to put a bounty on it, why should I bother?". In the past Maverick even proposed to pay for improving articles or for boosting a startup language. Why not ask Brittanica for a copy of their business model? (OK exaggerating here for rhetoric purposes). Erik Zachte 13:41, Jul 25, 2004 (UTC)

Bounty → Call for tenders

After talking with Erik Möller on IRC about his payment idea, it became clear that most of my objections to the idea of a bounty were derived from the connotations of the word itself, rather than anythng more specific Erik had said. It turns out these connotations were unintended, and what Erik had in mind was much closer to a call for tenders, as seen in civil engineering, than an amount of money publically offerred to catch a criminal. The basic principle is that Wikimedia would advertise that it needs some task done, then interested parties would enter some kind of negotiation with Wikimedia with the aim of finding a mutually agreeable contract. Once a contract is formed between the developer and Wikimedia, payment is assured as long as the developer completes the task within the defined timescale. Wikimedia would not be able to terminate the contract at will without payment, for the purpose of giving the contract to someone else or otherwise.

That takes care of one of my two objections, the other being that I can't spend any extra time on MediaWiki regardless of payment. I'll comment more on this issue later, but for now I'm not committing to a position either for or against it. -- Tim Starling 13:44, 25 Jul 2004 (UTC)

Use development contracts where no volunteers can be found

I'd like to clarify why I think a payment system is necessary, and how I believe the possible pitfalls of such an approach can be avoided.

The MediaWiki development team in the past 3 years has accomplished many wonderful things and has made MediaWiki one of the most powerful wiki engines around which is internationally used by companies, institutions and private individuals for projects large and small. It is without question that it would be so without my own modest contributions which pale in comparison to those of Brion, Gabriel, Tim, and Magnus. People like Erik Zachte have also invested countless hours of their free time to build extensions and analyze our database. Any payment system which we come up with must not in any way impair these voluntary processes.

On the other hand, there are tasks which are just not very much fun to tackle -- redesigning our database scheme from the ground up (which everyone acknowledges is necessary), properly internationalizing the software, implementing single sign-on for all projects, optimizing slow queries, systematically debugging the parser, etc. These tasks will probably get done sooner or later. But it would be in the interest of our users to have some way to steer and prioritize development without trying to exercise control over volunteers. It is also worth noting that you cannot turn a O(n²) problem into a O(n) problem by throwing hardware at it; i.e. a software implementation that doesn't scale can eat up near-infinite amounts of hardware. The call for "servers, servers, servers" is not unreasonable, but alone can never be enough.

I envision a process where a committee appointed by the board can single out certain important tasks, and open a call for proposals on these tasks. During the proposal period - say, 7 days - all developers will get an opportunity to make offers. Tim might say: "I will develop this task at $20/hour, I will probably take 20 hours to complete it." Jens might say: "I will do this for free, but I can only start in February next year." I might say: "I will do this if you give me $400 once I deliver the code." The committee then makes a decision on which proposal to accept. That decision would in large part be based on past experiences.

If there are volunteers who can complete the task within a timeframe acceptable to the steering committee, then there would be no need to pay anyone. Hence, payment is only an option to be used when necessary in order to accomplish the goals of the foundation.

Would free development be impaired by this process? I do not believe so. There might be developers who would say "Well, I could code this feature, but I'd prefer to get paid for it, so I'll propose to the committee to make a CfP, and then apply for implementing it." But they would not only have to convince the committee that the feature in question is necessary, they would also have to make a better offer to implement it than anyone else. If they can do both, then surely they deserve to get a certain amount of payment.

I propose to set aside a limited amount of money from the Prix Ars Electronica award - say, EUR 2500 - to try out this system over a period of two or three months. After that period, we can then assess if we need this system, and if it might have any obvious negative side effects. Right now the WMF has very little influence over the direction of development. I believe this step is necessary to give users (hopefully represented by the WMF and the development committee) a voice without causing harm to the established open source development process, and I believe that it will have a positive impact on overall MediaWiki development. Some things sound good on paper and work terribly in practice, and vice versa - I say we should give it a try and then evaluate the outcome.--Eloquence 19:00, 25 Jul 2004 (UTC)

I think this proposal under-estimates collatoral damages it creates.

As I wrote before, it does change the dynamics of the development process. For those interested in bouties it creates incentive to not do things in hopes that those features will finally be bountified.

Read the proposal. A tender alone hardly creates an incentive for people to delay implementation of anything they're working on, as they're not guaranteed to get the contract and it isn't even sure if some other volunteer would step up to do it for free.--Eloquence

It creates significant overhead:

a steering commitee that has to decide what needs to be done, write it down in enough detail to be implementable by a third-party (not an easy task in software)

That's exactly where a wiki shines, as the specs can be written collaboratively by the committee and the developers.--Eloquence

the negotiation process (which will inevitably have to be done in a way that disturbes all developers including thoase that are not interested in bounty. All participant of the developement process on any project have to be aware of what things are being done by other people)

The negotitations are public, and that's it. Developers interested in what projects are being taken on will keep an eye on the respective page. A decision can be made within a few hours, based on previous experiences and on which developer offers the best conditions.--Eloquence

the evaluation phase (i.e. deciding if delivered work was good enough). This will have to be done by a skilled developer i.e. either you'll use a time of unpaid volounteer who could be coding instead or you'll pay someone to do it (and then pay someone to oversee that guy etc.)

That's why there should be a developer on the steering committee. This would be a volunteer role, but like any other official position could eventually turn into a paid position. There's nothing wrong with that.--Eloquence

The idea of "steering commitee" is also troubling.

Why?--Eloquence

"Right now the WMF has very little influence over the direction of development. I believe this step is necessary to give users (hopefully represented by the WMF and the development committee) a voice without causing harm to the established open source development process, and I believe that it will have a positive impact on overall MediaWiki development."

That is another can of warms - a body that wants influence over development, doesn't feel it has it given current relationship with core developers and wants more influence by paying random people to pay for implementing stuff they think is important? It's bound to cause problems and wrestling about control over code.

"Random people" is a straw man. Nobody suggested that. The CfP process is completely open and encourages volunteer development. It is the best of both worlds.--Eloquence

Bounty system is not a new idea. It has been tried before in similar context of open-source projects (apologies for not remembering the name of the projects). As far as I know, they were not successful.

See my response on wikitech-l.--Eloquence

Even commercial sities operating on principle described above like [3] can hardly be called a success - they seem to be mostly used for completing trivial development tasks of low value.

There's a reason for that: outsourcing programming work is inherently difficult. Documented successes are scarce, failures abound.

You still don't understand the proposal. The equivalent of "outsourcing" in MediaWiki development is taking random people from outside the current circle of developers and assigning them tasks. That should be avoided if at all possible. The SC should prefer people who have a record working on MW for obvious reasons.--Eloquence

"Some things sound good on paper and work terribly in practice, and vice versa - I say we should give it a try and then evaluate the outcome."

The problem is that some things are irreversible. Give a try sticking your hand into the fire. This idea doesn't even look good on paper - it only looks good if you're willing to gloss over all the possible problems it creates. I've outlined multiple risks. In general, risks are worth taking only if (potential) reward is big enough. Is it?

So far you haven't made a single solid argument that it isn't.--Eloquence

I'll also point out that there is an alternative: do everything you propose with the exception of offering money. Instead do it the WikiPedia way: evangelize those priority features among developers. It's a better way to pursuade people and doesn't create all those collateral problems. -- Krzysztof Kowalczyk 21:12, 25 Jul 2004 (UTC)

The CfP idea combines both - if people are willing to do it for free, they can do it for free; if that fails, we resort to contracts.--Eloquence

Do WikiMedia administrators work for a "bounty"? I doubt it. Day to day, bugs and features are not addressed due to not enough developers. Expecting devs to build this thing as volunteers is plain exploitation. And the result is a lesser product. -- User:Johnywhy

Bounty is not necessary for success

To present yet another perspective on things.

Summary: bounty systems are (provably) not necessary for the sucess of open-source projects. Discussion about whether bounty is good or bad distracts from the discussion on more important topic: what are our options to improve mediawiki software.

Open-source is 20 years old. There are thousands of open-source projects. Some are successful, most are not. The development of open-source projects is on public record. There are mailing list archives, project web sites, history of CVS commits.

We don't have to guess or invent new ways of making open-source projects succesful. Much safer strategy is to analyze past, which is rich with examples, and identify processes that lead to success. Those who forget the past...

I've followed my share of open-source projects. Big and small, succesful and failed.

I've seen attempts to apply "bounty" systems to open-source (sorry for lack of reference, I forgot the names of the projects). They all failed (as in: didn't produce a lot of new, good code).

I don't know a single succesful open-source project that implements bounty system. Even less one that can claim that its success is caused by bounty system.

I've seen projects that flourish despite not having any external rewards systems in place (mono is a recent example, but there are of course plenty of them: GNOME and KDE projects, subversion, eclipse, gcc and I would consider wikimedia to be quite successful so far as it works well enough to support a massive undertaking as WikiPedia).

It's safe to conclude that you don't need bounty system to have succesful project.

The real question is: what is?

I think the discussion "is bounty system good or bad" is premature, stems from a haphzard idea of an individual (as opposed to systematic exploration of possible options to improve mediawiki project).

It diverts attention from much more important question: "what are the ways to improve mediawiki".

-- Krzysztof Kowalczyk 23:33, 25 Jul 2004 (UTC)

Nobody ever claimed that "bounties are necessary for success". The argument is that bounties are necessary for steering development in a certain direction and accelerating desired implementations. It's a big difference if i18n is implemented in 3 years or 3 months, but you can still call it a success in both cases.

As I pointed out on wikitech-l, both GNOME and Mozilla use bounties already. The open source development process is rapidly changing and as a leader in adopting innovative models we should experiment with promising strategies to achieve the desired outcomes. --Eloquence

As Krzysztof pointed out on the mailing list the GNOME bounty system did fail and I do agree with his analysis. Citing from the mailing list:

"GNOME bounty resulted in fixing 11 bugs

(http://www.gnome.org/bounties/Winners.html). 32 bugs for which a bounty was offered were *not* fixed (http://bugzilla.gnome.org/buglist.cgi?product=bounties&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED) despite the fact that there were 5 months to do the work.

That's for a system that has around 700 new bugs opened weekly and as much bugs fixed (http://bugzilla.gnome.org/reports/weekly-bug-summary.html) and is approaching 150.000 bugs in total. Do you consider that a sucess? Especially if you factor in all the work that went into nominating bugs for bounties, creating web pages, evaluating the patches.

--Marco Krohn 09:56, 26 Jul 2004 (UTC) (for the record: I'm against the proposed kind of bounty system)

People tend to be competitive. Turn it into a game.

Those making requests should be given a certain number of "points" per day that they're allowed to assign to their requests (or to already existing requests). When a developer completes a task, they're awarded all the points for that task.

Then you need a scoreboard that shows which developers are "winning".

This is basically the same thing Ashar was talking about (making users happy) except that it's easier to quantify.

-Bill Clark

I'm competitive but I hate games, especially ones involving points. w:Wikipedia:WikiMoney is a good example of this. Since WikiMoney began, my objective has been to destroy it. I never took up an account. My gut reaction is the same to this proposal. I would need to do some psychological self-analysis to work out why, but it may be because it trivialises the motivations I have for doing this, and jeopardises the appearance of generosity. Currently one of the reasons I work on MediaWiki is because I like to make people happy. For people to interpret my generous actions as competition for some shallow point system would be a disaster. Paying money for some specific task is not so bad, because it still allows me to work from altruism and satisfaction in other areas. A point system would co-opt my entire sphere of work. Simply refusing points is not enough either, since it would sour my opinion towards developers who take up the game. -- Tim Starling 02:06, 26 Jul 2004 (UTC)

Make good works and strong communities

I don't know about the other MediaWiki developers, but the only reward I'd ask is that people work hard to make great articles and a strong, friendly communities with this software.

If I could ask for anything else, I'd ask that people treat each other with the gratitude and respect they deserve. Everyone who puts work into these projects -- editorial, technical, community-building -- deserves our appreciation and kudos. --Evan 04:29, 26 Jul 2004 (UTC)

@Evan Day to day, bugs and features are not addressed due to not enough developers. "Community" will not pay anyone's rent.

Database Redesign

I'm quite surprised that this is something that we'd consider paying someone to do. It's really not that difficult of a task, it just needs someone in charge of doing it. I think better organization would solve most of these problems. Maybe there's no one willing to be in charge without getting paid, but I doubt it. 4.63.108.33 20:46, 30 Jul 2004 (UTC)

@4.63.108.33 do you buy food? Pay rent? Are you independently wealthy? Or just live at home with your parents, rent-free. --User:Johnywhy

Are WikiMedia administrators volunteers?

Or, do they work for a "bounty"? I doubt it.

Day to day, bugs and features are not addressed due to not enough developers. Expecting devs to build this thing as volunteers is plain exploitation. And the result is a lesser product.

User:Johnywhy