X
Tech

Perfectionists need not apply

If you're a perfectionist, or prefer to solve problems alone, you're going to have some problems working with community projects. Individual contributors and companies need to get used to working in the open, and be willing to work towards perfection rather than trying to nail it the first time.
Written by Joe Brockmeier, Contributor

If you're a perfectionist, or prefer to solve problems alone, you're going to have some problems working with community projects. Individual contributors and companies need to get used to working in the open, and be willing to work towards perfection rather than trying to nail it the first time.

I was reminded of this after stumbling on this brilliant post by Drupal maintainer Angie Byron. Byron does a character study of two potential contributors, and their approach to submitting a patch to the project. The lesson? The perfectionist isn't the most desirable contributor.

While Drupal itself is clearly an open, Bazaar-style project, many individuals in the Drupal community tend to take the perfectionist approach to development. After all, *thousands* of people will be using this code, and likely *hundreds* of developers carefully inspecting its inner-workings. How embarrassing would it be for another developer to stumble across a "no-brainer" bug in your code? Best to sit on things until you know it's really solid before putting it out there in front of people. Right?

Sure, that sounds logical. But in my experience, people who take this approach to development in an open source community, and especially the Drupal community, are at a severe disadvantage to those who embrace the chaos and put their changes out in front of everyone as they're going along, warts and all.

The lesson here is that the open source model is a collaborative effort. That doesn't mean that a lot of communication will make up for really lousy code -- but the people who succeed are usually those who are in the thick of it day in and day out, and who work well with other developers.

This is a hard lesson for developers with a proprietary background to overcome. For corporate-sponsored projects, the first impulse seems to be releasing code when it's "ready" for a release. Then perhaps releasing features to a public code repository when the features are ready.

But really, the only way to do it right is to work in step with the community -- meaning, making the public code repository the official repository, rather than doing work behind closed doors and then sending it out to the world.

Editorial standards