Commercial Open Source and Ethical (and practical) Community Engagement

I’m a big fan of commercially supported open source. I’m biased, of course, in that it’s how I get my paycheck. However, having worked on OSS without getting paid to do so, I think there are better outcomes for everyone when a project has financial backing.

A few jobs ago, when I was still working on my degree, I wrote a workflow engine for my capstone project. I was able to open-source it and used it at my work. I felt comfortable making improvements that were relevant to work on my paid time, but any community support or maintenance fell on my free time. When I moved to a new company, the project slowly bit-rotted into uselessness. I tried to find a new maintainer and I moved it to GitHub from code.google.com, to keep it on life support, but it’s functionally dead. If someone tried to adopt it today, I wouldn’t have the time to support them.

Compare that to my current project. If I got hit by a bus tomorrow, the project would carry on. Not only do I get to work on OSS, but I have time to spend with my family. In addition to writing code, I’m not just allowed, but expected to write docs, ensure we have a solid build process, respond to user questions and, in general, engage with the community to make sure users are successful and improve the project based on user needs. It feels like a sustainable approach to developing open-source software, at least for large projects.

Commercial backing does complicate community engagement somewhat. As soon as there’s a profit motive involved, people look at what you’re offering them with some suspicion. I would argue that when you’re engaging with the community, it’s not only ethical but more effective, to follow a few simple rules.

1. Be honest

2. Respect people’s time

3. Be nice

These rules should apply to everyone, of course, but people tend to be more forgiving when you’re not associated with a company.

Be Honest

First, when posting anything related to your project, where it’s not immediately obvious from the context, let people know that you are affiliated with the project. Second, let people know why you’re posting. If you’re sharing technical learnings, great! If you’re announcing a new feature, amazing! If you’re showing how your project can be used to do something interesting, neat! Don’t try to disguise one thing as another, though. What you’re sharing should have a clear purpose, with a specific audience that might be interested. Don’t waste people’s time by trying to trick people into reading it. It will just annoy them.

This brings us to:

Respect People’s Time

When you’re posting something, I’m assuming that you think it’s interesting, useful or (at a minimum) entertaining to somebody out there. If not, stop. Why would you bother?

The important thing to keep in mind when you post is that you’re asking for someone’s time, which is a limited resource. The faster you can help them decide whether what you’ve posted is valuable to them, the better.

It’s also important to know your audience. Don’t post about Golang memory optimization techniques on a Rust message board. It’s highly unlikely to be relevant and will just waste people’s time. Don’t post about every minor version release to a general programming language forum. Don’t post about your project in every conversation that is even tangentially related. There are times when people are likely to be interested. There are other times when you’re just interrupting a conversation that doesn’t need you.

This brings us to:

Be Nice

Don’t be rude about other people’s hard work to promote yourself. Don’t insult others. It’s not only harmful to them, it’s harmful to you. Most people don’t like bullies and you probably don’t want to attract the ones that do to your project. It can be OK to compare your work with that of others if you do so factually and in a way that someone who works on the other project would agree with.

Summary

Most people who work on open source are passionate about their work. It’s natural to be excited to share your work and what you’ve learned with the world. Following these rules will not guarantee universal love and adoration, but they will go a long way toward making sure your words are received in the spirit that they’re meant.

I still think fondly about my workflow engine, but I don’t miss the anxiety and stress that came with trying to advance it in my free time. Maybe when I have some free time again, I’ll write up the interesting bits and post them to an appropriate forum. Until then, I’m going to keep enjoying the privilege of being able to work on open source full time, share things that I learn and hopefully give back a little to the open source community from which I’ve benefited so much.