Drink was the first great leveller, as it brings everyone to the floor eventually. The second was the Internet. Everyone can be published, listened to, and promoted giving freedom of expression to the masses. Community-driven development is the third leveller, as it allows anyone to affect a project that's important to them, as either a programmer, artist, writer, or web designer. Alas, the leveller in this case engenders a flat uninteresting landscape because these self-assumed polymaths reduce everything to the best they could manage. And not the best that can be achieved.
Ok - so now you're foaming at the mouth because of the purposefully overzealous intro, let me qualify the last sentence: Free software enables some jack-of-all-trade developers to work within more parts of the development process than they should. Especially those with personal or small projects, where it begins as a necessity. They maintain a project and start believing their own hype, or continue to be precious. There are some truly multi-talented people in our field, but there are also some that really should stick to the day job, and concede control in some areas to others. If a project is worthwhile then people will help nurse its inadequacies... but only if you let them. My target is with those that don't.
Being precious with your project in the beginning becomes expensive in the end.
But this isn't just about coder art, or cheap-ass website design. It's more engrained and encompassing than this.
It's about documentation. Don't refuse politely made suggestions and alterations to your incomplete, ill-ordered, or broken, manual. If the project looks better because of it, you will look better as a result. There's no need to adopt a megalomaniacal approach. If the project is part of a CV or demo reel, then being able to work, and co-ordinate, with other people is more important than having written every single word yourself. Even professional writers have editors.
It's about delegation. And not just with the monkey work. Let others get involved, as they'll help spread the word.
It's about management. If you're a wiki administrator charged with removing porn, spam, and vandalism it doesn't necessarily follow that you understand the importance or significance of the topic discussed within the legitimate pages. Let peers within the field or community make those decisions.
It's about tutorials. The sample project included in your game editor might help promote your Pac-Man clone, but it doesn't help someone to learn all the necessary features of your tool. You need a special example for this. Sometimes it might appear contrived, or come from a third-party user creating a real-world project, but it's better than the self-aggrandisement example project included with the package that you're too precious to get rid of.
Note to project maintainers: Let us help - don't shoot yourselves in the foot.
In the end, it should be all about the project, not the developer of their ego. We should allow the best people in each field to create the best work they can for each particular project. That said, if you've read this far, you're open enough to consider the opinions of others and probably aren't the problem. So give a nudge to the nearest egocentric developer you know and see what they say...
