The basic idea behind open source is very simple: When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves.

(Yes, there is “Open Source” and “open source”, but since OSI coined the phrase, their definition deserves consideration.)

Your list has “read” and “modify”, but not “redistribute”. In my mind, that one is too important to omit: The leaders of a project (i.e. committers) may decline to accept my patches, but if they do, I have the option to distribute those patches myself, or even fork the project to include my patches.

This forms an important safety mechanism that keeps open source projects democratic, despite the exclusive nature of the committers in most projects: If the project leaders fail to satisfy the needs of the user community, that community can, as a last resort, fire the leaders by forking the project. This goes some way to ensure that “if you, the end-user needs it, that the software will be updated and supported”. Historical examples: emacs/xemacs, gcc/egcs, xfree86/xorg, the various BSDs.

Are there any examples of projects which are generally accepted to be open source, yet do not include the right to redistribute?

People either worry that The Midnight Coder will commit illegal or bad code to the project when no one’s looking …

This has always baffled me and is a good indicator that the person making such a statement has little experience with how most F/OSS projects work. I can’t think of a single project that has–or has had at any time–open commit access. There’s a pretty standard vetting process for potential new contributors that goes like this:

Lurk on mailing list
Participate on mailing list
Send patches to mailing list / tracker
Do #2 and #3 for quite some time
Commit access

#5 only happens when your patches are going through pretty much untouched and when applying them is taking up too much of the maintainers’ time. There’s many cases when commit access doesn’t make sense, even when your patches are always good (e.g. when the frequency of patches is low).

… or that actual control of the project rests in the hands of a few elitists who exclude just anyone from committing code.

Every successful project I’ve been involved with includes one or more “elitist” maintainers – you need committers with a high level of intolerance for shitty code that don’t have a problem with rejecting patches. The best policy for maintainers seems to be in assuming you are going to throw a patch out before seeing it – every new piece of functionality is unnessary until proven required.

This general mentality is refered to as “keeping the crack out” by Seth Vidal (Yum, Fedora, Duke/Linux) and I think it’s one of the most important and least talked about aspects of F/OSS project maintainership. Keeping the crack out is not fun for maintainers – it’s not creative, artistic, or intellectually stimulating elsewise. People get pissed at you and throw around words like “elitist” to rationalize the rejection of their patch.

I refuse to work on projects that don’t have at least one guy who has demonstrated the ability to 1.) recognize crack and 2.) keep it out. No developer wants to contribute to a project that’s going to bloat into uselessness because the maintainer is incapable of rejecting functionality that’s not generally applicable (i.e. 80/20) to the community. I’d say this is especially true in commercially organized F/OSS projects where you run the risk of Gartner magic quadrants dictating project direction.

Notable crack-keeper-outers I’ve had the pleasure of observing and who should be lauded for their excellence in crack-keeper-outing: Guido Van Rossum (Python), Linus Torvalds (Linux Kernel), Seth Vidal (Yum/Fedora Extras), David Heinemeier Hansson (Rails), Havoc Pennington (GNOME/Metacity). It’s funny that you never hear about this aspect of maintainership even though it seems to be something that all great maintainers share.

So yea, I don’t buy the “elitist” argument for a second. It doesn’t make sense unless your goal in contributing to a F/OSS project is PR. No established/successful F/OSS project is going to reject contributions from someone based purely on commercial politics – and if they do it’s more likely that it’s because the contribution is crack.