Which Open Source Projects Are -Really- Collaborative?

An Anonymous Coward asks: "I'm a highly competent and occasionally respected software engineer, who has worked on several Open Source/Free Software projects; some of my code is in the Linux kernel. Within the OSS community, we maintain that the main point of publicly announcing OSS projects is to invite programmers to join the project and collaborate to make better software. But in about 90% of cases, I've found that publicly announced projects in development are not actually open to new members - the project leaders will ignore unsolicited code, won't respond to emailed queries or suggestions, and in many cases the projects in question remain in an early stage of development forever." What projects do you know of that don't make an issue out of incorporating user submitted patches and design changes, and what projects put forth huge restrictions on such submissions, even to the point of not accepting them at all? "This happens even when the project has explicitly asked for collaboration, and it happens when the project leaders are big names in the OSS community as well as when they're relative unknowns. So my question is, who actually collaborates? Which projects make unsolicited development effort worthwhile by making it part of something bigger?"

Comments

Most welcome good help

[Burdell]

Virtually every project I've been involved with have welcomed good code. Sometimes, changes are rejected because they don't fit with the maintainers' "big picture" view of where they want a project to view, but usually they'll explain themselves if that is the case (and you can try to adapt your change or their viewpoint :-) ).

I've submitted code to some projects (like util-linux, sendmail, and GNU libtermcap) and had my ideas accepted but someone else made the change (in ways that better fit the "big picture"). Nothing on my patches page for Cistron RADIUS has been integrated into that code, but that is because Cistron RADIUS is considered "stable" and doesn't get much in the way of feature changes (new features go into FreeRADIUS). I've had patches accepted for OpenSSH, wu-ftpd, and Cyrus SASL that went right into the core code base. When I suggested a change for Cricket (which is maintained on SourceForge), I was given direct access to the CVS tree and basically told to "make it so!"

Don't give up because your changes are not accepted. Talk to the maintainers, and if it is clear that they aren't interested, put your patches up on a web page and let others know about them. If they are useful and people use them, the original maintainers may decide to pick them up. If not, that's okay too - thats one of the great things about Open Source software!

Collaboration

[Arandir]

Collaboration is great. Everyone uses it, even closed source development shops. But it can be overdone.

Pulic collaboration is a tricky beast. You CANNOT let just anyone commit into your code base. Someone you trust must review that code first. And if no one has time to review it, the code won't get in. This only makes sense. An Open Source software project is not a place where everyone wandering by is free to leave their mark on the fire hydrant.

The question to ask is "who gets commit privileges?" The answer is those you trust, and only some of them. Too many contributors and the project loses focus. Limit commit privileges to those who have proven their coding and domain expertise. But this doesn't mean that only a few people can participate.

I rather like the FreeBSD model. There is a small group with full commit privileges, but a much larger group called "contributors". These contributors may have commit privileges in limited areas of the code tree. Anyone else wishing to contribute may do so, at any time, but not directly to the tree. Instead the submit their code and patches to the appropriate contributor. Eventually a submitter will gain trust and be admitted to the ranks of privileged contributors, and maybe eventually to the core committers.