In the vein of other great “how to help in FOSS projects” emails, presentations, and so forth, the Fedora developer list saw another one from Richard ‘hughsie’ Hughes, titled “Sending a sensible email“.  It begins:

There appears to be a trend on this list where a random user just posts an inflammatory email with “ACME SOFTWARE IS RUBBISH”. Now, if the maintainer of that software is scanning the email list, bear in mind he (or she) has likely spent a significant amount of time and energy getting the software into the state you see it now. They probably spend evenings and weekend closing duplicate bugs and fixing trivial typos that people notice. If you title an email with such rubbish then the maintainer is simply going to ignore it or spam it. I’ll explain why:

The way open source software works is you get the software for free. If you don’t like it, you get your money back. If you want an additional feature, or a bug fixing really fast you either pay a Linux company like Red Hat or Suse some money and they assign a developer to work on it. If it’s a big feature it’s going to cost lots of money.

The other way is to join the software mailing list, and suggest the new feature, and “sell” it to the maintainer.

Believe me, this works.  It may be easier to do it yourself if you are a programmer.  But if you are a normal mortal like the rest of us, you have to get creative and find ways to get it done anyway.  If you aren’t going to pay someone, you have to make it compelling for them to work on it, and it really helps when you contribute something back to the effort.

Free/open source software (FOSS) has a way to do that.  Ordinary users have the power to affect change that matters to them in the software they use.

Wield the power wisely.

Tip one, ask questions and make arguments in a nice and respectful manner.

I’m thinking there needs to be an appendix or section or something in The Open Source Way about how to interact with a community to get things done.  That is arguably the scope for the entire book, but perhaps a good story or two would help illustrate.

As one good story of how an organization has learned from community interaction mistakes and turned that learning in to valuable contributor creating and scaling, check out Dr. Dan Frye’s keynote from the Linux Foundation Collaboration Summit.