How to get members of any open source community to be interested in helping you

There’s an old “ha ha, only serious” joke. If you go to a Linux forum and ask for help fixing your WiFi driver, everyone will ignore you. If, instead, you say “Linux sucks, you can’t even get a f*&$ing WiFi driver working!” thousands of people will solve the problem for you.

This story is a great example of manipulating people, but it’s obviously a negative take on it. I’d like to share some thoughts on this from a much more positive standpoint, which will help you get people to pay more attention, be more helpful, and—perhaps most importantly—create a healthier open source community over all.

Ask HN: Why don’t more open-source projects monetize?

Because monetizing your open-source project means you take on a second job.

Here are your choices:

  • Turn your OSS project into a company (Docker). The pro is that you can capture a lot of the value, the con is that you’re splitting your project into CE/EE and also now you’re a CEO
  • Give the software away for free and charge for the hosting (Gitlab). Pro here is that you get recurring revenue, but the con is that now you’re in DevOps and wear a pager. Also this model doesn’t work well for libraries, only “apps”.
  • Charge for support (Ubuntu, Nginx-ish). Pro here is that by helping folks implement your software, you’ll have a long line of success stories. Con here is that it isn’t scalable – your upside is bounded by the hours you can bill
  • Get a job at a company that will fund you to work on it (React, Angular). Pro here is that you can make tons of money with a job you love. Nice work, if you can get it. Con is that now you work for that company and you’re subject to whatever whims they have.
  • Run a Kickstarter (Light Table, Diaspora). Pro: you can gauge demand and you don’t have a boss. Cons: it’s one-time revenue, you have potentially inflated expectations, and just kidding, now you have 1,000 bosses.
  • Run a Patreon (Vue). Pro: you have autonomy and recurring revenue (yay!). Con: now you’re a personality. This is limited to celebs who are good at marketing _themselves_ as much as their software
  • Ask for donations (Babel, Webpack). Pro: this works for tools and libraries (not just apps) and you can keep your mission. Con: Companies feel these donations have ambiguous deliverables. There’s a lot of mental overhead too (How many projects can one company fund per month?)
  • Sell documentation, books, videos (React Training, my current gig). Pro: JavaScript fatigue makes you money! Con: Writing the docs isn’t as satisfying as writing software (for many developers)

So to answer your question: monetizing your open-source project means you take on another job _besides writing software_.

In an ideal world if you write software and it gets used, you’d be able to capture some share of that value. But we’re not there yet.

Writing a Great README 

A great README file helps your project to stand out from the sea of open-source software on GitHub. In this article I go over the key elements every README for an open-source project should contain. It also includes a README.md template for use in your own projects.