Mozilla has, in its over 9 years of existence, learned the community is there and it’s watching. If you start gaming, it will call your bluff recklessly, and even before you are shipping a product based on those games. You downgrade someone’s pet bug and he’ll shout out loudly. You ditch someone’s pet RFE from the list of things to ship and he’ll blog about it and tell others who might have wanted this. You can never indulge yourself in thinking the knowledge of that gamble will stay in-house. You know it won’t. And because you know that, you won’t dare to play the game. If you are ditching something, you first have to have a pretty strong argument for doing this. If you downgrade the priority of something, remove blocker status or such, you need a pretty good explanation or it’ll come back to you. You can’t just keep it in the team because you’re always in the public in some way. And the public, i.e. the community, won’t believe a cheap excuse.

I don’t even think that people in those software companies don’t know about their gaming, they just make theirselves believe that it’s OK to do so as the users won’t see this or that problem or won’t care about this or that feature. You only need to satisfy yourself, your team, your managers – for the moment.

In an open community, you need to account for every such step to actual users in the community, and not only after shipping but actually right when you take the step. Once you learn that, it changes your thinking. And Mozilla has learned that quite well over the years. We never would have been able to call what Netscape shipped as their 6.0 release a final release of Mozilla. Community members back then knew it was a nice testing version but not ready for the casual user. And Netscape6′s non-success told us once again that the community was right.

So, what companies can learn here is:
1) Make your processes open, have the community actively participate, and quality will profit.
2) Believe testers in the community. Sure, they are talking about their pet feature/bug, so take feedback with a grain of salt. But at least re-think if what you’re doing is really what you should do when the community disagrees. There’s some possibility that they are actually right.
3) Never ship on a fixed schedule and never rush a release. Only, ever, ship when it’s ready to be shipped, never before that point. It’s better to tell users you need to ship a month or two later to meet your high internal quality standards and have some press about people eagerly waiting on your release than to ship right on time and have even more press about how your product sucks.