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?"
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.
It is about the closest thing any bit of GNU software has come to having w4r3z. With as closed as the process is, good luck finding the source anywhere. I think David Kastrup said it the best on comp.emacs (groups.google link):
They claim they keep emacs21 under wraps because they don't want to be flooded with bug reports from stupid people who can't debug it themselves. Of course, they could still release it and just ignore all bugs that don't come from pretesters, even if just by giving the pretesters a special address to send the reports too. Personaly, I think they just like their little exclusive club and enjoy keeping it that way.
Let me be the first to say that emacs21 is wonderful, so maybe their dev model works, but it causes a lot of strife. It is, of course, their choice to pick a dev model that works for them.
However, I call upon people to mirror the source if you have it. I've built emacs21.0.105 on several platforms without much hitch. I'm a stupid, non-pretester member of the unwashed masses and I didn't have to pester them to get it working. I'm still looking for a place to mirror the source (it is pretty big, ~25MB, worth every bit of it too), but I hope to have it available sometime soon.
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
- Does what the contributor is offering line up
reasonably well with my vision of the project? Sometimes people are looking to do something very different with my code than I intended
... perhaps radically expanding the scope of a project for instance. I don't mind people doing this, but I tend to be unwilling to accept this all back into the core, thereby becoming somewhat responsible for it, preferring instead to just point off to
their work.
- When supplying patches, does the contributor
explain clearly what the patch is supposed to accomplish?
- Does the contributor seem competant?
Some situations where I didn't end up utilizing patches include:- Patches to get things building in environments that I don't use, and will have
trouble maintaining, like Borland C++. I can't
test the changes, and I can't maintain them.
- Changes to fix a small/uncommon problem that
I fear might break lots of other stuff. This is especially true of "configure" changes that tend
to be very fragile, and that I often have trouble
being confident of the ramifications.
- Library bindings for environments I don't use
(like python, tcl or perl bindings). I will often
dump these into a contrib source tree, but I don't
want to be responsible for them.
- Contributed ideas that will be hard to
utilize. Some people think they have great ideas
but are not in a position to implement them and
think I will be thrilled to have their ideas. Well, they can offer them but don't expect me to
change the direction of my project to try them out.
I would like to note I have had very good experiences submitting patches to the Mesa project. Patches I submitted with detailed explanations have been applied within a few days.I have also had excellent submissions to many of my projects, most notably to libtiff which is of wide use and interest. In the case of libtiff though, I have found some patches to be difficult to apply because it is hard to be sure the submitter has thought through all the possible ramifications.
Finally, people have many things drawing at their time, and it is often difficult to find the time to review a patch and apply it to a project you aren't actively work on at the time. So to the extent possible, make it easy for the maintainer.
Geospatial Programmer for Rent
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 find Perl very open to new developers. I spent some time last year trying to get into the Perl 6 effort. I got some criticism that was mostly constructive, and all in all, I was encouraged to stick around. Time constraints prevented that, unfortunately.
Note that I've been using Perl for three years and watching the community for two. If you try to jump into something like that and throw out a bunch of frequently requested features that don't really belong in the project, you won't go far.
All in all, I think the Anonymous Coward who wrote this is smoking something. I've never met a free software developer who didn't appreciate help. I have met some who didn't appreciate ignoring their design, ignorance, personal attacks, committing to do things without finishing, etc.
Secession is the right of all sentient beings.
I made a few bugfixes to makedepend and submitted them to both the X consortium and XFree86.org about 1 year ago. Nowhere did I ever get any type of response back, nor have I seen any signs that either of these groups incorporated any bugfixes to this important tool. I did get flamed a couple of times on XFree86's maillist just for asking where to submit my fixes. I guess it's not important to these organizations. I do note though how so many other people do their own versions of makedepend anyhow (including the linux kernel source). At least my company has benefited from my bugfixes. I can't say that my first experience in trying to submit bugfixes makes me want to contribute to any other Open Source Projects.
Within less than five days after engaging in discussion with the PLIB people on the mailing list, I had a cvs commit account as well as integration of the discussion of things. In the meantime, someone also working on the same PLIB-dependent project as I(who I got to help me through one of those project announcements) was able to integrate well with the people in the mailing list etc with his GUI work.
You can find PLIB, a 3d game development library, at http://plib.sourceforge.net
The 'mtx' package in all its glory consists of 5,000 lines of code. This also limits the amount of 3rd party collaboration needed -- it just doesn't take a bazaar to write a 5,000 line program. Of those 5,000 lines, perhaps 500 lines were inherited from Leonard Zhubkoff (I re-wrote the remainder of the original 'mtx' pretty much from scratch when I split it into two parts, added a .h file, and changed over to use GNU Autoconf for configuring). The next biggest contributor is William Smith, who contributed the HP/UX port, which is approximately 150 lines of code. Those are pretty much the biggest chunks of the program written by other people. (Note: The 1100 lines of code in the 'contrib' directory are not included in any of this).
Yes, I receive patches. No, most of those patches are never applied. This is not malice. Usually the patches fix a particular problem with a particular loader by hacking around the problem. If a problem has a general solution, though, the patch goes into the garbage and I instead program the general solution. The last time this happened, a guy sent me a 5-line patch to make 'mtx' work with a particular optical jukebox. I looked at the problem, figured out a general solution for the problem for *all* jukeboxes that had that same general problem, and re-wrote the READ_ELEMENT_STATUS code for the third time, splitting it into three different subroutines and issuing separate SCSI requests for each element type rather than one big SCSI request. I ended up changing about 200 lines of code to solve the problem that this guy's 5-line patch "solved". The problem was that this guy's 5-line patch would have resulted in random core dumps on various architectures, though it worked on his particular machine with his particular loader, and his patch, while it solved the problem for that particular loader, did not solve the general problem (which was the problem of multi-drive loaders reporting "ghost drives"). My changes solved the problem -- but required an intimate knowledge of how the READ_ELEMENT_STATUS parser code worked, and how other loaders handled that same basic problem. I will not be modest here -- there was not another person on this planet who could have solved this problem within hours, as I did, and nobody did. I wrote the code, I knew how it worked, I could swiftly split up one big routine into three different routines and add a driver routine because I knew exactly what needed doing, no study required. Collaboration, in this case, was necessary in that I needed the guy who had the problem as a test bed for the changed code to make sure it actually solved the problem, but the patch was tossed because -- like most patches I recieve -- it simply patched around the problem, it didn't fix it.
I would count 'mtx' as a successful Open Source project. When I took over maintenance it supported DAT autoloaders with one drive and up to 8 slots. Today, it supports virtually every SCSI SMC-compliant device out there, including enormous optical jukeboxes with thousands of slots and dozens of drives. The participation of others was crucial for this -- but their participation was most valuable their suggestions, and for helping test whether my code actually worked with their loader, not for their programming contributions, which, with the exception of Mr. Smith, were negligible. I don't know how it could have been any other way, because I was the one who had the knowledge of the code and the knowledge of SCSI and the knowledge of all those other busted loaders out there, and someone who was just coming in from the outside with a particular problem with a particular loader simply does not have the knowledge, in the general case, to contribute a meaningful patch
-E
Send mail here if you want to reach me.