Slashdot Mirror
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?"
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.
-- I'm the root of all that's evil, but you can call me cookie..
The author of the paper brings up a good point that ESR overlooked in his original paper Cathedral and Bazaar paper, which is that Bazaar style development does not necessarily mean Open Source and Cathedral style development does not necessarily mean closed source.
It is possible, and actually occurs quite often, that a project may release its source code licensed under an Open Source license but has a development process that is elitist and closed (one has to look no further than the *BSD camp). Similarly it is possible for commercial projects to be developed in a Bazaar style manner especially with the rise of software development techniques like Extreme Programming where no one specifically owns a particular part of the project and people are encouraged to participate in all parts of the code and as well as test and review all parts of the code.
I thought this would be some interesting food for thought.
You will find that if you submit a diff to the list and author of a project which is active, they will be quick to either accept it, or explain why they didn't. After a few good patches on the list, you can ask for CVS access and work on projects as you wish!
I remember pre-KDE-2.2 working hand-in-hand with the release manager (cheers to David Faure!) to update libraries while I updated code. Bouncing patches back and forth to get it 'just right' for my app needs and the overall needs of the project is when you feel open source is working best for you!
...PLEASE do not think that only open-source collaborative projects are good! The quality of a software is the software itself and the associated license (choosing a good open-source license is essential). I think that big open-source projects *have to* be open to external contributors because one man can't do everything. But having a good coder for one small open-source project is sometimes better than having several students in software engineering too much self-confident. Also the fact that it's open-source software guarantees the possibility to fork when people are unhappy with the maintainer.
Here's a couple guidelines off the top of my head:
.tar.gz. If you're going to be doing it anyway let others benefit.
1) Follow the goals of the project
Usually a project leader will have in mind where he wants the project headed. Follow it. Ask him about it if you can't find any information about this on the web page or mailing list. (Sometimes a project is organic however).
2) Follow the existing design unless it's broken
Don't change the design unless you can articulate good reasons for it. This forces people who already know the existing design to take time to learn a new one.
3) Coding style
Follow the style of the rest of the code. Some people will reformat it for you if it's good enough, but don't bet on it.
4) Keep it manageable
It's difficult to read and verify large patches. Send separate functional pieces if possible. It takes me much longer to merge big patches than smaller ones.
5) use cvs diff
Unless keeping it manageable prevents it, use 'cvs diff -u'. This generally makes things easier for you and whomever is applying your changes. Especially if you're never made a diff before.
6) Tell the project leader what you're doing
Even if you're not going to be done anytime soon, let someone know what you're doing. I had two people come up with independent debian packages for a project because one of them didn't mention it to anyone.
7) Put it on a web page somewhere
If your patch doesn't get merged put it on a web page. Send the url to the mailing lists and keep it up to date. Maybe provide a prepatched
That's all I can think of at the moment. I try to reply to all patch emails even if I reject them but some people don't have the time. Don't feel bad if nobody replies, just manage the patches yourself if you find them that useful.
Rick Haines (rick&kuroyi!net)
http://dxr3.sf.net
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!
One open source business model that has been ignored is that of a coordinator between users with needs and programmers willing to write open source code.
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 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.
A Government Is a Body of People, Usually Notably Ungoverned