At a party, if you notice someone has food stuck in their teeth, you probably wouldn’t go “HEY! You have food stuck in your teeth and it looks GROSS! I hate it. I think you should go brush your teeth right now!”
But we do that all the time in open source.
Someone writes a new blog post or a new piece of code or forgets to post something … and we criticize them in public. Because it’s open source, right? Instead of emailing them we think their blog post is wrong, we leave a blunt, often rude comment. Instead of IMing them and asking if they’ve considered the privacy implications of their change, we write a public blog post that details how wrong their strategy is. Instead of congratulating them on their new product website and emailing them a few suggestions that would make usability better, we write a long critique in a blog post of our own.
When we do this, this public criticism, we change their ability to respond to it. Now they must respond in public, often defensively. If the feedback was private first, it would be easier for them to change quickly and nimbly. (Or maybe they don’t need to change at all. Maybe we missed something.)
There is a time and a place for public critique. But it’s often not the first place the critique should happen if we want to effectively influence projects.
Most effective people on open source projects communicate privately first.
They communicate via private emails, IMs and even public IRC channels, which are less public than web pages and public mailing lists because they aren’t archived.
So the next time you read something and have burning feedback, consider your audience and how you might most effectively drive the change you are looking for.