How do open source projects maintain quality?

Question

How do open source projects maintain quality? What keeps the projects from people with relatively little programming experience checking in poor quality codes?

Answer 1

What keeps the projects from people with relatively little programming experience checking in poor quality codes?

Usually, not everyone have the rights to change the source code. Most often there is only a small group of trusted developers that have rights to change the source code. If someone else wants to make changes, they can submit patches, but these are checked and added by the developers with commit access.

Some projects allow other developers to join the trusted group, if they submit several patches of sufficient quality.

Answer 2

How do closed source projects maintain quality? What keeps the projects from people with relatively little programming experience checking in poor quality codes?

The same way:

• code review
• testing
• static typing
• static analysis
• metrics
• consistent coding styles
• consistent guidelines
• shame (because everybody in the world can see who wrote that crappy code)

But really the answer is: most don't. In both cases, open and closed source. After all, programming is subject to the Pareto Principle and Sturgeon's Revelation (“Ninety percent of everything is crud”) just like everything else.

In Linux, for example, in almost 100% of all cases where a company releases a previously closed source driver as open source, that driver needs a considerable amount of work before it can be merged into the kernel tree, simply because its quality is so bad. In some cases, it is so bad that the code is basically unsalvageable and has to be rewritten from scratch.

So, in Linux, the way that quality gets maintained is that low quality contributions get rejected, but there is a mentoring process helping people to write better quality code.

Answer 3

That really depends on the size of the developer base, and what back yard you happen to be playing in.

How either of those are determined mostly depends on the skills of the founding developer(s).

First, realize that writing code and pushing it into the wild for the whole world to critique and review takes a special kind of person. That person might not be very confident in their abilities, but they are willing to publish their code anyway. Someone else might be extremely confident. Both people have the same goals:

• Release something that seems useful
• Get help from other programmers

There may be underlying financial reasons, but the above tends to be true.

There may be other motivations in the mix. I know people who spend an enormous amount of time re-writing proprietary applications under an OSI approved license (usually the 3 clause BSD or GPL). I know other people who can't stand GPL2+ libraries and work to re-write them in order to release them under a less restrictive license.

In any event, you have lots of people writing and publishing code for various reasons.

In my experience, (really) bad code gets committed due to the following reasons:

• The original author found contributors that exceed their skill level. They don't know a bad patch from a good one.
• The original author wants to stick it to (insert whatever man here) and is happy to have some help and a fellow idealist to e-mail
• The original author trusted a part of the code to someone who made some bad decisions on what actually gets accepted, or didn't really look at what was being proposed.

Lets break these down a bit:

On the first point, the original author probably hoped to learn something in the process of releasing their work. That's not in any way bad, but if you have a small development community it can become toxic. Think about it, you have a thick enough skin to release your stuff, you get a patch that blows your mind, is your skin now thick enough to admit that you have no idea what the patch actually does? That happens quite a bit. If you have more eyeballs watching things, it helps. So let's say the first root of toxic changes is ego.

Additionally, you might just get tired of fighting an otherwise great contributor on a single point and just say 'screw it', even if you understand the patches.

On the second point, stuff that is written to fill an idealistic void (at least early on) is of lesser quality than something written to fill a technical void, at least in my experience. For the most part, the GNU project is an exception to this rule, they have been producing software that runs predictably and consistently on a variety of architectures for years.

You won't see a lot of revengeware in the wild, it doesn't last very long. I have been part of projects that were started explicitly to stick it to the man, and I've quickly left them. This brings us to the second source of toxic changes, no real focus.

Finally, you get to the point that a project has really taken off. The original author is not only skilled enough, but trusts their skills enough to ward off toxic patches. The project grows, the code base grows and more and more trusted lieutenants are brought on to help manage contributions. The original author has final say, if they want it, but trusts their inner circle to effectively look after the parts that they maintain.

People do odd things. I can't count the number of nervous breakdowns that I've witnessed on public mailing lists on both hands. People get burned out, develop drinking problems, sometimes drug problems or all out vanish. Their spouses leave them, their homes burn down, feces occurs. However, by this time, you should have enough critical eyes on stuff to catch that.

This brings us to the third (at least in my experience) reason why toxic code gets put out into the wild - a lack of community oversight. This happens mostly in projects where users outnumber actual contributors by 100:1 or more. You have plenty of eye balls, but none of them know what they're looking at.

Not listed, but finally, the original developer may have burned out years ago. When / if that happens, a project loses passion.

Beyond that, other things happen. Companies get bought (we're seeing the aftermath of that now with OpenOffice / OpenSolaris).

Answer 4

Well run open source projects use the same tool sets and patterns of behaviour that good closed source projects do. The difference is that in the open source model you can have many more eyes on the design and the code.

So for the two open source projects I'm heavily involved with, we:

• Have JIRA as a feature request and bug tracking system ** We roadmap the items listed in JIRA
• We hold collaborative design discussions on mailing lists and IRC
• We have code reviews
• For new joiners, we ask that they submit patches until we are comfortable with their level of code quality and familiarity with the code base
• We ensure that documentation is written as part of completing some code
• We use source control and have feature branches and maintenance branches
• We run a CI server

See http://www.producingoss.com for a guide on how to run a successful open source project

Answer 5

Some don't.

Those that work have a single person (or if very large a group with well defined responsibilities) who vet everything and only let what meets their standards into the official codebase. (Private branches = private problems).

Answer 6

If you have an application with more than one (experience) developer, bad code won't go into the main branch, since you won't get write access if you don't prove you meet their standards.

Answer 7

Most projects have version control systems, where the code development goes in branches. New features are accepted to unstable branches, or even in a branch-per-feature or branch-per-fix manner. When a new branch is tested and it's clear that the code is of good quality, it can be merged into the main branch, or into beta-testing branch, from where, after fixes if necessary, it goes into or becomes itself the production branch.

Read about Mercurial http://hginit.com/ and Git http://progit.org/book/ version control systems.