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

  • 6
    How do you define "quality"?
    – user1249
    Nov 10, 2010 at 9:08
  • 4
    What do you mean by "checking in"? I doubt you will find a single open source project with a world-writable repository. Open Source means that you can take the source, make your changes (good or bad) and be happy (or not) with the result, but that's not the same version that most other users get, unless your changes are accepted in the main branch.
    – user281377
    Nov 11, 2010 at 12:29

7 Answers 7


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.


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.

  • 1
    This answer needs a hefty edit, I think you've copy and pasted in twice - I'd edit it but I don't want to lose the gist of your answer... Nov 10, 2010 at 9:38
  • Indeed, open source stimulates better quality than closed source. In closed source the only thing that the world sees is the external behavior of the application, and the primary motivator of programmers is their monthly salary, which doesn't depend on the code quality at all. Thus the code is often quite a mess. Been there, seen that... Nov 10, 2010 at 10:31
  • +1 for "most don't. In both cases, open and closed source." Nov 10, 2010 at 13:52
  • 1
    NOTE: static typing does not guarantee quality. Strong typing does. There are serveral languages that are strongly typed, but not statically typed. I dare say the proportion of quality projects is probably about the same between the different platforms. At the end of the day it's all about the logic, not the types. Nov 10, 2010 at 14:37
  • If I could set two answers as accepted answer, I'd have chosen this one as well. but the answer I chose explained the aspect of open source project that I didn't undestand before. I thought the open source projects' codes could be changed by anyone, like a wiki.
    – Yeonho
    Nov 10, 2010 at 14:44

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).


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


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).

  • Interesting the votes down here. Linux - the open source pin-up poster, is an example where there is a strong person in charge who vets what gets through. This promotes long term consistency and quality. I personally don't like the linux code base, simply because like most open source, there are too few comments. HOWEVER, it has outstanding longevity and thats due to that person at the top who rules over what's in and what's out. Apr 21, 2016 at 0:43

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.


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.

  • I'm willing to bet that this is not true. In my experience, only a small number of projects actually use version control. And of the ones that do, many use version control systems in which merging is something between very painful and virtually impossible. I count myself blessed to mostly work in an environment where the "version control question" basically boils down to "Git, Bazaar, Mercurial or Darcs?" but for most programmers its more like whether to put the manually managed foo_finalversion.test-20101110-abc.bak.bak.c files in a separate folder or not. Nov 10, 2010 at 9:35
  • 2
    @Jörg W Mittag I completely disagree, you only have to look at where 90%+ of open source projects are hosted. Sourceforge, Github, Google Code and more, they all provide source control and that is used is a vast majority of cases. Nov 10, 2010 at 9:40
  • As soon as you learn DVCS like hg or git, you naturally start using them as soon as you start a project. Just create a folder, and do hg init or git init, and your repository is created.
    – user5545
    Nov 10, 2010 at 9:44
  • @Jörg: I think you might be somewhat right for many propritary products. But almost all open source projects use version control. Nov 10, 2010 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.