"My buddy Fitz and I have long preached about best practices in open source software development--how one should be open and transparent with one's work, accept code reviews, give constructive criticism, and generally communicate as actively as possible with peers. One of the main community 'anti-patterns' we've talked about is people writing '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.
"And yet over and over, I'm gathering stories that point to the fact that programmers do not want to write code out in the open..."
