Two rules of scandals
I attended the graduation ceremony for the St. Olaf College class of 2007. The commencement speaker works for the US Government organization that oversees auditors of publicly-held companies. He shared something that I think is worth repeating:
There are two rules about scandals. Rule 1 is “it’s never the action, it’s the cover-up”; Rule 2 is “no one ever remembers Rule 1.”
This seems to be especially true in the technology community. Transparency is a valuable policy for any organization, but especially so if the organization’s customers and communities are the kind of detail-oriented individuals they are within the IT and development worlds.
Media frenzy notwithstanding, it’s always better to admit one’s mistakes openly than to try and hide them. The community rewards people and organizations that are trying to do the right thing, and will continue to stand behind them when they make mistakes — so long as the offending person or group is up-front about it. There will always be loud voices attacking someone for making a mistake, but if that mistake was admitted rather than discovered, those voices will quickly die down. Not only that, but goodwill is created in the process of openly admitting one’s mistakes before they are discovered by others. That goodwill, in turn, creates a kind of loyalty and trust among the customers and community that is truly second to none.
The mechanism for this is pretty straightforward for public figures and organizations: have a press release, tell people how you messed up and what you’ll do to make things right. It gets a little more complicated for those of us who are private individuals.
For developers, the most common opportunity to “‘fess up” to mistakes is in code comments and documentation. A developer who releases a bit of software with docs that say, in effect, “there’s this nasty little bug in the database code I wrote — I’ve worked around it for now, but it’s really slow. I know about it, and will be fixing it in a future release.” does a great service to her customers.
If I acquire software — free or otherwise — and I have a negative experience with a feature or component, I have to make a decision. Do I keep using the software despite the flaw, or do I look elsewhere? If a developer tells me up front that he knows there that flaw exists and plans to fix it, I’m more likely to stick with that package than to move on, because I have trust that the flaw will be fixed.
Transparency is of paramount importance. This, to me, is one of the great strengths of Open Source — it enables transparency in a way that proprietary software never can.