blog

archives

The Discourse Encouragement Fund

Erlend Sogge Heggen February 16, 2017

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:

  1. 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.

  2. Make it a bite-sized task. All tasks pay between $150-$1000. 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.

  3. 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.

  4. 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.

  5. 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?”

  6. 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.

  7. 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!

8 comments

Discourse’s Fourth Birthday

Jeff Atwood February 6, 2017

As of today*, it’s been four years of Discourse!

four cake with light

It feels like only only yesterday that we launched Discourse as an open source project. We’ve certainly been busy for the last four years:

I’m happy to announce that in our fourth year, we’ve just added two team members:

@falco aka Rafael dos Santos Silva from Brazil

Rafael

@oblakeerickson aka wait for it.. O. Blake Erickson from Idaho, USA

Blake

This brings the total Discourse team size up from 9 to 11 souls.

Where do we go from here? Everywhere! Can’t stop. Won’t stop.

More Discourses, more features, more plugins, more integrations. Maybe throw a few new Emoji in there for good measure while we’re at it. And all of it, always, 100% free and open source for you, forever.

* OK technically yesterday but come on that was a Sunday!

7 comments

Discourse for Private Communities

Erlend Sogge Heggen January 27, 2017

There are many reasons why a community might be private: Paid memberships; a company intranet; a sensitive subject matter; beta testers; a grassroots movement building momentum before going public.

Whatever the reason, we want Discourse to function well in private contexts. We reached out to 23 private Discourse communities to learn more about their use cases, and 10 of them got back to us with some great answers.

How does your organisation use Discourse?

(…) we’re spread around the world and we’re also organized fairly traditionally into fairly independent silos. Email and chat were not helping us share knowledge and solve problems across geographical, organizational, and temporal boundaries. So we’re trying to move lots of discussions to Discourse. It’s working, and it’s helping.

~ Avi Flax, Park Assist

 

Traditionally, most of our communication has been done via mailing lists, but as our community has grown over the past few years the mailing list model has increasingly become a hurdle for us for many types of communication, for a variety of reasons. This topic on Meta gives a nice overview of why a particular sub-community inside Frostbite really prefers Discourse over mailing lists.

~ Jake Shadle, Frostbite

 

It’s a space for all coworkers to discuss, be it current methodology, philosophy, vision or strategy. We also love shared knowledge through best practices, new tools and the best ideas around. (…)

All the conversation that matters and deserves a calm space to be on lives in Discourse. Everything else, the quick and inconsequential things, go to Slack.

~ David García, GoodRebels

 

What are your favourite things about Discourse?

The top 5, ordered by how many respondents mentioned it:

  • Replies via email
    “The ability for users to participate by both web and email was probably the biggest benefit for us.”
  • Intuitive and usable interface
    “You always know where you are, no distractions, it allows you to focus on what you want. It’s very easy learn to use and fun to discover new features.”
  • Markdown support
    “Including code highlighting and inline image (and other) attachments, gives much more readable and beautiful posts compared to email defaults”
  • Customizability & configurability
  • Mobile friendly
    “Discourse responsiveness and adaptability is a best practice, it doesn’t matter what device you use for reading, even for writing, if you start a topic in one device the content saves automatically and you can continue in another! In addition, native apps are a plus due to providing push notifications.”

Also mentioned were many of the usual suspects:

  • “SSO & Google login support is great.”
  • “the multimedia and low-latency notifications that enable low-latency discussions”
  • “The assistance we got in enabling “threaded” emails was fantastic (so the support is amazing!).”
  • “gamification”
  • “[it’s] quick”
  • “Being able to assign categories & groups emails addresses has been extremely valuable.”
  • “Moving, splitting, merging topics. Overall, moderation tools are very good”
  • “Banner: we use it constantly.”
  • “Superb search, and pervasive human-readable links makes sharing Discourse content on other communication channels easy”
  • “Love text preview when creating a post”

What are some things Discourse could do better?

 

  • links and some formatting don’t carry over when you copy+paste from google docs.
  • private categories — the ability to have closed categories with a specific set of people allowed to access.
    This is already possible by limiting a category to certain Groups. Please send us an email or make a #support topic if you need further assistance with this.
  • deeper integration with slack — specifically the ability to quickly and easily migrate an existing/ongoing discussion from slack to Discourse, with history
    This is coming! You can track the plugin’s development here.
  • better on-boarding docs, help, tutorials, etc — ideally targeted to organizations’ internal communities, maybe also something specific to those trying to replace email
    We have a “Discourse vs Email & Mailing Lists” comparison that might be of interest to you. Feel free to ask for advice on how to replace email there. As for better docs in general, this is an ongoing endeavour. We recently restructured our #howto section to prepare for further doc improvements soon to come.
  • Having an area where anyone can post/mail in, but only certain groups can read/respond would be helpful.
    Sounds like what you’re looking for is Incoming Mail. Discourse lets you configure a (usually private) category or group to receive from an ordinary email address.
  • Having an area which our management group could post “announcements” to and guarantee every member receives the post.
    Just add your announcements category to the “List of categories that are watched by default.” in the default categories watching setting.
  • Allowing members to have multiple email addresses registered against a single account, so they could post from multiple email addresses (but only receive emails to their “primary” address.
  • It would be nice if people who don’t know the first thing about coding could customize the look, feel, and functions of Discourse more easily.
    Well the functions of Discourse are already highly customisable via the admin backend. Themes on the other hand do require some HTML&CSS knowledge. We’ll be addressing this later this year with the introduction of Native Themes.
  • ability to send new automated emails triggered by events
    This is usually very doable using our API or Webhooks.
  • A nicely formatted changelog for the current version, oriented to normal users, linked from the About page would be nice.
    We always post a comprehensive changelog as well as a blog announcement with shiny objects. What changelog format are you missing?
  • The native metrics don’t really cut it.
    We know! First order of business will be to pull the Admin Statistics Report plugin into core. After that we’ll turn our attention to our general stats dashboard.
  • You guys have SO much data on communities and what makes them successful. From a Community Management perspective, it would be awesome if you could leverage that and create case studies or white papers.
    Great idea! We’ll be giving this some thought.
  • Customizable profile fields / links to social media
    We explain how to do this in our Link custom user field to external website tutorial, but we could definitely take that a step further with some pre-set social media fields.

Many thanks to our survey participants!

1 Comment