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

MIT Kerberos one of the worst...

[nneul]

I've yet to see any project that is as bad as MIT kerberos as far as refusing or just plain ignoring contributions. There has been a blatant extremely inconvenient bug in the telnetd/login implementation in MIT krb5 for at least a year, that I've submittedbug fixes for numerous times. Every time it's ignored completely. Similar for other patches.

VERY good discussion topic.

[Thomas Charron]

I've found that, while a great many projects are considered 'Open Source', making the source available does NOT make an open source project. To be a truely open project, you also have to have an effort to do things such as merge and include changes that have been provided BACK into the project.

Many the project has a list of 'contributed' changes, with many things that NEVER actually make it back into the source tree. Why? I'm unsure, beyond the fact that many individuals who do these things, do so for themselves, and are nice enough to make the source available. They are NOT, however, interested in fostering a community around the further development of their code. The blokes who wish to step up and take on these reins are few and far between, and it is really a different 'role' then many of the developers out there WANT to have.

In order for a project to do this, it requires 'evangualists' that wish to take on these roles. Some people serve both roles, indipendent developer AND evangualist. These people serve as the best 'Project' leaders. They posess skills that many people dont have, only ONE of them being good developers or engineers.

I dont think this is a BAD thing, really, it just determines which projects will be wildly successfull, and which ones will simply be pet projects, used little, possibly important, but very often, eventually abandonded.

Perhaps a way to say this would be an 'Open Source' project, versus an 'Open Development' project.

pcmcia is a good project

[andika]

Once I submit a very small config info to make a not-so-popular PCMCIA NIC works, to the project coordinator. He accept my info, although he don't know me.

Horde project

[jjares]

I found horde to be one of the best at this (I really like their discussion lists)... even the developers are really busy, they take the time to reply to every little comment/problem/suggestion, and often they incorporate patches/suggestions in the main development code... I really like to thank the Horde development team for that.

I have limited experience, all good

[rknop]

I haven't done a whole lot of contributing to big open source projects, I have to admit.

I did send the GLE author some RPMs a while back, and heard back from him. And, I sent in some patches for the Atlas project (map software for FlightGear), which made it in quickly.

-Rob

a few good ones

[Garrett Rooney]

I've had good experiences contributing to FreeBSD, Subversion, PHP, and Mono.

With FreeBSD and PHP it took a little while to get my changes in, because the people working on it are volunteers, and believe it or not, they do have lives of their own. In the FreeBSD case especially though, my code was thoroughly audited, and I learned quite a few new tricks in the process.

For both Subversion and Mono, from what I've seen the developers are very very good about incorporating changes quickly. And again, specifically in Subversion, they're very good about auditing your work to make sure it's the best it can be.

So yes, while some projects can take some time to get your stuff in, and some can be quite exclusive, there are a lot of good ones out there, you just have to look for them.

read the CREDITS file

[Zooko]

You can always investigate the CVS logs and the CREDITS file (warning: shameless plug for my own open source/free software project).

Regards,

Zooko

Hacker, Evil Geniuses For A Better Tomorrow

PostNuke

[beanerspace]

PostNuke is a good example of a true collaboration that not only allows, but encourages individuals to participate at all levels. Meaning, it's even okay of you're not a programmer.

For those who don't know. PostNuke is a weblog / Content Management System (CMS). It offers full CSS support, HTML 4.01 transitional compliance throughout, an advanced blocks system, and is fully multi-lingual enabled. PostNuke is a fork of Francisco Burzi's PHP-Nuke ... in fact, the PostNuke project was started because of the closed open/source nature of PHPNuke.

here's why

[krokodil]

I have several tiny open source projects for which
I receive patches from time to time. I do not accept
all of them.

Some of patches are not satisfy my quality requirements to the code. Being professional developer, sometimes when I see code written by some 1st year CS student I would rather rewrite it.

Some of patches are platform specific, and integrating it into real project
requres gread deal portability tweaking (#ifdefs, configure.in changes, etc.). I am not always have time to finish patch for contributor and they are not interested in making in works besides their platform.
Some patches are solving small local problem without taking bigger picture into the consideration. I would
later implement more generic solution.

My words to contributors: when you submit the patch, this is not end of your involevement. Good contributor
supposed to work with project maintainer to refine the patch. Also project migth need your help fixing bugs
if they are found later in your code.

Sourceforge

[brunes69]

Go to sourceforge and look int he "help Wanted" needed. There are always tons of projects there that need developers, Doc writers, Web Developers, QA perople, everything!

Re:The Cathedral and the Bazaar

[Nygard]

Actually, when Raymond first wrote tCatB, the "Cathedral" he referred to was GCC! It wasn't originally about closed vs. open source. It was examining why Linux was developing and evolving much "faster" than GCC. His conclusion was that the centrally designed and planned approach of the GCC team (a fairly closed group of developers, even though their software is free) led to slower development than the relative free-for-all of the Linux kernel.

It was only after the initial publication of his paper that people started to think Cathedral == closed source.