I recently read an article on Scott Hanselman’s blog saying “Open Source is a thankless job, we do it anyway”. This post will not be an answer to that. I will tell you when open source is not a thankless job and ways to discourage other people from getting involved in your company’s open source project.

There are times you do open source for the public good and times you do it for yourself and at the same time unavoidably for the public good anyway. You could enjoy the time you spent doing open source, you might get yourself some reputation and possibly respect doing it and sometimes, even better, you get a paycheck to do it full time.

Until today, I somehow got involved in open source work at different levels, some of which I consider myself very lucky and still brag about it. Recently, I started to look at other corporations’ projects instead of hobbyist hackers’ repos. This is when I noticed what corporations actually do with open source.

Now I will take time to explain more what companies mostly do by open sourcing things. Note, I’m certainly not a corporate open source specialist, but it doesn’t take much to observe this at all.

  1. Enhance their ecosystem. They release libraries to make their products and APIs more usable or create examples using their products and APIs. (a) The API is open, there is no point at hiding the code, (b) customers would like to know what the shipped library (jar/dll) is actually doing.
 This is mostly for company’s own good and for marketing reasons. Examples: google/google-api-nodejs-client, aws/aws-cli.
  2. Share things they have built that might be useful to others: This is for the public good as well as their good. They are mostly using that in their business and they will be happy to get fixes or suggestions for free. Examples: netflix/RxJava, twitter/finagle.
  3. Share their fork of another open source project: Similar to 2, they adopted a project from open source domain and now their systems rely on it. They give their contribution back to the public domain, their fork might not get merged with the original project, but that’s fine. Examples: azure/redis, google/dagger.

There’s probably more than that but that’s the outline of it. Here is where things can go wrong. You are using some open source work from a company in the shoes of a customer (ideally, it should not matter if you are an internal customer, a paying one or a free tier guy). As always, no open source work comes with any sort of warranty, yet it is easy to find flaws in the code. That is when you want to fix it or improve it in a way. That’s when you make your attempt to fix it with just by opening an issue or perhaps by sending a pull request on GitHub. You are doing this because it could be breaking your workflow, affecting your business operations or it could be an innocent feedback to the maintainer(s) of the open source project, which could be corporate entities (teams) as well.

Now, the chances of the suggestion or issue report getting considered by the company is a different story than submitting a suggestion for an open source project casually maintained by a few hobbyist people. Some companies are well infamous for not taking issue reports seriously. But that’s not the point.

The moment you press the “Submit” button on the New Issue page of a company repository, there is not much you can do about it. Companies have their own internal ways to operate and fixing public requests and suggestions might not be their highest priority. The moment you hit that button you should say “I did my part” and be done with it (unless you are a VP of Engineering in that company or managing and the maintainers are reporting to you). The rest is up to them and you should lower your expectations.

Here is what that company can do when they receive an issue for their open source work on GitHub. Again, I am not an expert, I just use common sense to come up with these:

  1. Acknowledge the issue.
  2. Use the magic word. Say “Thank you”, it does not take as many keystrokes.
  3. Do whatever you want to do with it. But if it ends up getting fixed/merged (means they just improved your project), say “Thank you” again, it’s free.

Again, just by using common sense and a bit of experience, probably what that company should not do when they receive an issue on GitHub:

  1. Do not bother acknowledging it. Do not say “thank you”, ever.
  2. Close issues opened by customers without providing any reason, better, mark them as wontfix.
  3. Do not recognize any sort of contribution made by other people in the company internally. Especially if they are not paid for it and it is not in their job description; but hey, they just made your team a favor, how silly of them.

Open source is a voluntary job (unless it is paid job). Companies can be quite successful at their projects by leveraging the power of open source; but they can also be very good at discouraging contributions (both internal and external). We all know it is a thankless job anyway; but certainly not when you have unappreciated and unorganized contributions and yet it is giving you trouble.

People managing the open source programs at the companies? They should be the welcoming ones who know how to show appreciation, respect and kindness better than anybody else. It doesn’t take much to discourage people from contributing whereas getting them involved in your company’s open source project is much harder. So please, don’t be an a**hole.

(What is written above is just my perspective and opinions and not my employer’s. It would be silly to think so.)