For almost a year now, we’ve been doing something that’s considered quite risky for an open source project: Paying contributors. Communities like ours are fundamentally built on intrinsic motivation. Getting money involved can jeopardize the whole ecosystem, but for the past year we’ve been experimenting with a model that lets us pay contributors for mission-critical work, while maintaining a culture of volunteerism.

It all started with the Mozilla Open Source grant* about a year ago. This grant effectively enabled us to pay our own developers to work on features that were strategic to our business, as long as these features were also aligned with the “common good” mission statement set forth in our MOSS roadmap (which was to improve our email capabilities). So with some of our company’s developer time being paid for by this grant, we decided to pay it forward by using an equivalent amount of our own money on some more experimental ventures for developers from our community to take on.

To date we’ve paid 16 different developers a total of $17’000 to work on bite-sized tasks. All of the work is open source, and two of the developers we’ve worked on paid assignments with are now core members of our team!

A process for rewarding contributors

For the past year, we’ve been fine-tuning the process of handling paid contributor work. These are the key lessons we’ve learned:

Define a rough spec. A one-pager with bullet points, posted as a public discussion topic on meta.discourse.org, would usually suffice. The important part is to move past any implementation controversy. Unlike in-house development where we sometimes start work while the spec is still being defined and talk, argue and finally agree through code, this is not ideal for outsourced work. The spec can still be rough as long as there is 100% consensus on the key ideas among the core developers. Make it a bite-sized task. All tasks pay between $150-$1500. Any less and it’s usually better to leave it as a pro-bono contribution opportunity. Any more and it’s gonna become a project (i.e. dependencies, deadlines) instead of a one-off task. No hourly rate. A fixed fee simplifies the transaction. We say “would you be interested in doing Task-X for Y$?”; the contributor assesses the scope; after cutting out a couple stretch goals we’re in business. This payment is not so much a freelance assignment as it is an acknowledgement of a valued contributor. We choose who, what and when. At first we tried to put tasks “up for grabs”, but this method didn’t work too well. You end up with multiple takers and you have to pick one and let others down. Instead, we approach developers individually, one at a time. Since we’re an open source project we know fairly well who’s capable of what, so we’ll tap our top prospect, present the task & “bounty”, and get a yes or no. If no, we move on to the next good prospect. If we run out of good prospects for a specific task, we’ll either do it ourselves or put it on hold. Tasks are mostly strategic. As in, directly or indirectly, this improvement is gonna save or earn CDCK Inc. money. This is the easiest way to draw a line between “what type of job deserves funding?” Tasks are mostly time insensitive and free of dependencies. Doesn’t really matter to us if it’s done tomorrow or next month as long as it gets done. It’s not a good idea to expect part-time contributors to jump on to the speeding train that is core development. Spread it out. We’ve tried to not play favorites. Most volunteer contributors appreciate the opportunity to work closely with the core team at a more professional level – as do we with them – so we want to have that experience with as many regulars in our community as possible: programmers, designers and technical writers alike. What’s more, as a sporadic call-to-action it doesn’t appear to disrupt the give & take spirit of open source volunteerism.

This is a process that will continue indefinitely, as we are extremely happy with the outcome for both our product and community.

For a long time this was just something we were doing, but eventually it became “The Discourse Encouragement Fund”. As much as we’d like to, we can’t put every one of our contributors on a steady payroll. What we can do is remind them that the work they’re doing is valuable, in every sense of the word, and that there is money to be made from specialising in Discourse. For the truly committed, the opportunities are out there. A bigger ecosystem benefits us all, so if you’re entertaining the thought of generating a steady income through Discourse work, we’d love to talk about it.

p.s. we recognise that having the time to volunteer in the first place is a privilege. In conjunction with the Encouragement Fund, we are also experimenting with contracting gigs and paid internships, but that’s a different post for another time!