Ben Collins-Sussman from Google’s Open Source Project Hosting project shares his view on why you should allow early collaboration on your project, even when it means releasing a low-quality product to the public:
Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them. (As they say at Google, “don’t run from failure — fail often, fail quickly, and learn.”) Cherish your history, both the successes and mistakes. All of these behaviors are the way to get better at programming. If you don’t follow them, you’re cheating your own personal development.
One of the key reasons for publishing your work in the early stages is to allow community to get acquainted with it and provide feedback. This is like LISTEN behavior, as opposed to TELL behavior, where you come to the community with a polished product and ask them to accept it. Bob mentions here the open source programming “anti-pattern” of code bombs:
That is, what do you do when somebody shows up to an open source project with a gigantic new feature that took months to write? Who has the time to review thousands of lines of code? What if there was a bad design decision made early in the process — does it even make sense to point it out? Dropping code-bombs on communities is rarely good for the project: the team is either forced to reject it outright, or accept it and deal with a giant opaque blob that is hard to understand, change, or maintain. It moves the project decidedly in one direction without much discussion or consensus.
I think this is a great piece of advice not only for programmers, but for any project in the social networking space. If you’re a blogger, write your posts without striving for completeness and allow readers to provide their feedback via comments.