Perfectionists need not apply

Summary: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.

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.

Topics: Open Source

About

Joe 'Zonker' Brockmeier is the community manager for openSUSE, a community Linux distro sponsored by Novell. Prior to joining Novell, Brockmeier worked as a technology journalist primarily covering the Linux and FOSS beat, and wrote for a number of publications, such as Linux Magazine, Linux.com, Sys Admin, UnixReview.com, IBM developer... Full Bio

Contact Disclosure

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.