Open Source Development: Quality Assurance or Community?

Can we have both?

Open Source projects are built on the notion that a bunch of programmers who don’t know each other (at least initially) can work together to build software that will potentially be useful for as many people as possible (consider apache, samba, ubuntu and smtp). Open Source projects are usually made up of dedicated volunteers who want to change the world. So where does, “we want to change the world” move to “we want to change the world but only if certain criteria is met”.

Open Source projects are a lot like neighborhood play when I was a young (oh so long ago).

consider this scenario:

It’s Saturday, all the neighborhood kids are outside trying to find something fun to do.

David (the leader) says, “OK we are going to build a fort!”
Everyone jumps up and down and yells, ‘Yeah! Yeah! let’s build a fort!”
David decides, with agreement from the group, “OK this fort will be 2 stories high and…”
George pipes up and says, “I don’t think any of the trees can hold a 2 story high fort, daaavid” and rolls his eyes
“Fine, 1 story fort then” David says slightly dejected.

A slight pause and then with renewed excitement David yells, “ok? OK!! So Tommy you go get the sticks, Susie go get some sheets from your mom’s closet and Chris didn’t you have like tools or something in your garage? I’m sure your dad won’t mind!”

Just as the kids were about to rush off to get materials Billie, David’s very best friend, strolls over to the group.
“Uh oh” Susie whispers to George
“Yeah remember last time he helped us! He fell down and broke the fort, we had to start all over!” remarked George
“yeah but when we rebuilt it we had a tv and fridge and stuff in there that Billie setup, it was the coolest fort ever” Susie whispered.

So what did we do when the kid who ‘ruined’ everything came by? We patted him on the back and welcomed him to the project and then made sure his shoelaces were tied. We had the coolest forts ever.

Open Source projects attract all types of people, from the end-user who downloads and uses the software but doesn’t say anything at all to the world-changing rock star of a programmer who can take a project from so-so to irresistible. Then there are those of us who fall in the middle. We download the software and use it. We like it so much we figure out how to do really neat things with it. We tell other people about the project and they go download it and do stuff with it and talk to you about what they’ve done. These are not core developers but what I like to call “integrators”, people who really appreciate what the project has to offer. People who are not involved in the creation of the software but who take the core functionality and adapt it fit our requirements, whether it’s for a client business process or for our own project.

Then we want to contribute. We spend our free time creating an add-on product or writing documentation or creating screencasts to help the project and the community “grows”. After all we want as many people as possible to know about our project. We hold events to promote the project and feel like we are part of this community even if we don’t actually write the code that makes it work. We contribute in our own ways.

The world is changing on an hourly basis now, not daily. The way we did something last week is no longer applicable this week.

How do we ensure that the project stays “current” and keep the community strong by encouraging contribution? Or is that even possible?

Those of us who “integrate” feel trapped between the desire to help the project and further the community and the speed at which the project is developing, leaving us gasping for air as we try to keep up with changes.

Which is more important for an Open Source project, the strength of it’s community or the quality of the project?