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?"
And do not flame me for it, but I think it is one part maintaining the public image (Jump on board!) to one part of just not having the resources/ Manpower to deal with every piece of submitted code. If all OSS projects had the type of man power that say, the Linux Kernel project had, Open Source would be dominating every market, but, as I do not run any of these, I really do not know.
You say you want a revolution....
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.
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..
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.
Yes, and its not a bad thing. It just happens to be a project that suites its purpose, and thats it. It will never, however, be wildly popular. This isn't a BAD thing, so long as it suites the needs or its target audience.
Many times, the needs happen to be simply trying to do it. In that case, the developers themselves are the audience, and they gain the experience.
And many, OH so many of these small things, that end up sitting in sourceforge limbo, serve, at the very least, as GREAT sample code for the next project to do more then likely basically the same thing...
-- 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.
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
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 [extremeprogramming.org] 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.
Ownership doesn't necessarily mean non-participation of others in test, review, or contribution of code. All ownership does is divide a large project into areas of responsibility. How the owner administers his piece, and whether multiple owners within a project have a common style, are separate issues from whether there's one owner for the whole project or a set of owners for the components.
Typically an owner or his team negotiates interface definitions with the owners of adjacent components. Beyond that the owner makes final decisions about feature set and what code is included in the component. He may keep control of it all himself or break it up and hand pieces to subordinate owners. He may keep his deliberatioins private, make them public without accepting feedback, or invite participation. He may accept contributed code and integrate it, accept suggestions but write the code himself, reject assistance, or even actively try to do something different from what is suggested. He may do his debugging himself, accept bug reports, or stage walk-throughs. And so on. Finally, he may change his policies with time.
All ownership does is create a clear set of responsibility boundaries in a multi-person project.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Alot of the submission-friendliness depends on the ego of the maintainer. If its a person who wants to head up the project just for the fame of it, you'll probably find it hard to submit good high quality code.
Such maintainers are probably more likely to take the ideas from your code and implement it themselves, for better or worse...
I am a maintainer of a project myself, and I know that any submissions that come to be will be scrutinized quite harshly for quality. If they're not up to my own standards then I wont accept them. My project is rather small tho, and very focused.
I've also submitted code to other projects. In one instance the code was completely ignored. In the other instance the ideas of the code was implemented and I was credited for it, but it still wasnt my code that was accepted.
For those who wants to contribute code, the most valuable code you can give is probably that which is nonexistant. Code that offers functionality that is wanted but for which code doesnt exist yet.
Code that simply tweaks currently existing functionality will have less chance of getting accepted I think.
If all else fails, you can always look into forking the project. If you are unhappy with the current maintainer, maybe there are other people who are aswell? Can you do a better job? If so, dont be afraid of forking, thats what free software is for I think. Letting the best man do the job.
/proton
I've watched the wine-devel list closely for the past 3 or so years, and I've observed the following:
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.
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
From that start of Kinkatta (formally Kaim, kinkatta.sourceforge.net) two years ago one of my top priotities have been to get others involved. When I get e-mails I try to answer them right away and if it is a problem I save the e-mail and send another repley once it is fixed in cvs. I constantly ask people for problems that they have so I can fix it, I have been accepting patches and all of the other normal things a good lead developer should do. I figured that doing all of the above would make my app the best it could be. All of these would get people involved and they would know that if they submited their problems that they would not be ignored. When other developers have found interest in working in Kinkatta I have tried to help them out in getting involved. I wrote a hacking file that helps expleain what code is where. I would give them little bugs to try to fix and so forth until they were comfortable with the system. I do not think that I would have been anywhere as successfull if I hadn't done any of these and am surprised that people arn't doing them in the first place.
Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
To some programmers, having working code is not as important as having the experience and knowledge of the codebase. These are the guys who will understand the codebase in months and years to come. To me, accepting a large number of patches early on in the dev process could lead to a sordid understanding of how and why everything works. (Will your static char buf[] fit on the PPC stack in that reimplemented sprintf() call? What? You didn't consider that when accepting the patch last year?)
I've had code turned away by the svgalib developers, because my implementation wasn't full enough. Sure, I coded in dvorak support before they released a version that could do it a couple years back, but my patch was too hacky for their tastes. Theirs allowed a true remapping of the keyboard in raw mode. Mine was an on/off translation switch.
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 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.
... in fact, the PostNuke project was started because of the closed open/source nature of PHPNuke.
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
healyourchurchwebsite.com - WWJB?
- 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
I may be feeding a troll, but, just in case it was an honest question, we already have a very simple tool that helps people fork. I have used this mysterious and little-known tool to maintain my own forks of several projects when I was making changes that couldn't or shouldn't be folded back into the main tree. (To truly be effective, you should use it in concert with another hard-to-find tool.)
--
pétard
.sig: file not found
My thoughts...
People will always object that if it's GPLed or whatever, if you don't like what the Admin's doing, fork it. Kind of like the old: "If you don't like the village, go live on the heath."
As well as ignoring suggestions on patches, an equally good (perhaps better since you don't end up looking bad) way to prevent people spoiling your grand vision is neglecting design and documenting your code. The old: "I'd rather write code than discuss things or think about them." It sounds silly when put like that, but it's an easy trap to fall into (I speak from experience).
Another question, how does one end up as an Admin? I think it is nearly always by either starting the project oneself, or being recognised as a good programmer and promoted by an Admin who is moving on. This means that Admins usually have vision and/or good programming skills, but may well suck when it comes to managing people, which is what's important if collaborative development matters. (And I believe collaborative development is often overrated.)
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.
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!
The KDE team is very good about letting new developers into the fold, and they gladly accept patches.
Their bug system also has a very active wish-list. Many items actually get into KDE this way.
There's a project called ming. It is an open-source library that produces SWF (Flash) files on the fly. It is quite early in the development, but it's already very useful. A few months ago I decided to write a converter from an XML-based format into SWF The XML's tag set was modeled very closely upon Ming's inteface, so it was really closer to a wrapper. I called my program xml2swf.
Anyway, at an early step in the development I became stuck. The problem was that I wanted to know where I'd moved an object (on the screen) previously. This information is stored in the library anyway, thought I, so there must be a way of getting it out.
Well, I was wrong. The structs which contain the position are hidden behind opaque pointers. So I could either compile my program with knowledge about ming's internals (unelegant), store the information on my own (inefficient and long) or to offer a small patch to ming's developers so that it would provide accessor functions.
Naturally, I chose the third approach. However noone responded me. It was a month ago; ming still doesn't have accessor functions, xml2swf is in deep freeze and I'm thinking about other projects where I could encounter more cooperative developers.
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!
Seems to work pretty well for the most part, though once in a while stuff gets checked into the main branch that in my opinion ought to have been sent around to the developers' mailing list for more sanity-checking first.
Anyway, yes, open collaboration does exist out there and is producing good results. DScaler is often favorably reviewed versus $10K+ commercial alternatives.
The OS team's response seems pretty apt. It was soemthing like, Open Source does not mean taking source code and throwing it over the fence. We will not consider opening source code unless we are able to commit the resources to coordinate a serious development effort.
i have been crying to our sysadmin to install a locl im service...i think it's ideal for getting programmers to communicate.
i also know a lot of prgrammers communicate via chatrooms.
so, i think it's a little tough to get a handle on this "problem: because even though there might be a fe problems with people "outside" of the core team getting their influence into a project, i think the people in the core team are communicating/collaborating quite a bit.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Usually the code is too difficult for bedroom programmers to make much headway in it. The problem isn't the coding style as much as the problems modern productivity software has to solve in order to be considered much use.
The bedroom hacked software of today would be considered much more substantial if it was 20 years ago and software that reformatted the screen colors was considered killer.
Now in order to be considered substantial, software has to be 100,000 lines and take 9 megs on disk, which is going to require more than a hobbyist attitude toward scheduling and budget than ordinary individuals have any reason to invest.
I've yet to find an open source project that ignored unsolicited code that happened to be a flat out bug fix.
Pulsar writes that Linus Torvalds often rejects patches that involve non-x86 architecture-specific bug fixes, even if the bug causes a kernel panic on every platform but Linus's precious x86.
Will I retire or break 10K?
We started an Open Source project (the Overflow project - see sig) about 2 years ago. I can say that our problem is mostly the opposite: how to get people to collaborate. We receive many e-mails asking for help on how to compile or things like that, but very few people have really helped or sent patches. Actually, most of the "external" help comes from the fact that the company I work for (The project existed long before I worked there) decided to use it in its product (it's OK, the project is LGPL).
So the question is: how do you get people involved? or even, how do you know how many people use your software. From the sourceforge stats, I know there have been ~15,000 downloads in the past 18 months. Of course, most of the times we only get e-mails when there's trouble so we have no idea how many people are using it? is it 50% of the downloads (well, surely not), or 10% 1%, 0,001%???
Does anybody have experience on this?
Opus: the Swiss army knife of audio codec
This topic has generated many good comments and insights. Here's one point that might not be clear enough to folks who aren't full-time developers: There's an enormous difference between development in a young system verus in a mature system. No question, a large group of casual contributors can be ideal for maintaining and improving a stable code base. However, a system that is designed by committee (in my experience) always sucks. Good software architectures are (again, IMO) always the result of a relatively small, focused group who can devote their full energies to the project. Often, beautifully-designed systems reflect the singleness of purpose of a sole author.
Therefore, requests for assistance by an early-stage project are really requests for full-time, experienced volunteers who can pick up a large piece of the project. Well-meaning but low-level contributions suck down the available cycles of the lead developers, who should be focusing on the big problems. It takes a lot of time to manage a collaborative process. So getting annoyed because the four lead designers aren't spending half their time reviewing suggestions seems unreasonable to me.
Again, this is not true of all projects, but is often the case in an early-stage effort.
The point made in the main post about many projects remaining in this early stage of development forever is totally valid. Often, the system never makes it to the level of stability where a larger community can really work together effectively. This lack of progress reflects a combination of factors: human failings, poor design, poor documentation, lack of interest, lack of financial support, etc. Nobody feels good when a project falls short.
There's no rant here. Some projects have the right combination of key people, community participants, problem area, technical success, and support resources to coalesce into a strong open-source effort. Other times, it just doesn't come together. I don't think it's fair to blame volunteer developers if they're not able to make the whole thing work, unless of course they put out a clear request for specific help and then ignore it. Some comments below call for open source projects to issue clearer articulations of their plans and needs. This is very reasonable. Most of the ambitious projects already do a fair job at this.
But blaming volunteers for not volunteering even more of their spare time never seems right to me. (Not that this was the author's intent, of course.)
JMHO -- Spiny
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
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
I work on a project which has some developers with full read/write CVS access and others who have just submitted patches from time to time. A few of the patches I've received have been nothing more than quick hacks to solve an immediate problem, but which (in my mind) do not solve _the_ problem. I have chosen not to apply these patches. The people who submit these patches may be upset with me, but I think it's important to realize that not all code is good code and we as developers shouldn't be obligated to accept anything just in the spirit of cooperation. If someone is going to modify the source code, I think their changes need to have a few attributes.
1 - The change has to be in harmony with the overall goal of the project. Just because a piece of code has bugs or is incomplete in functionality, does NOT mean that the main developers don't know what they want the code to do. It often just means that the main developers are too busy to implement the feature at that specific time. If someone comes along and submits changes that go against the main developers' wishes for the direction of that particular piece of code, then that submitter ought to first a) know WHAT the developers' original goal was so that he can demonstrate that he b) is informed enough to know why his new method will work better. The developers aren't going to trust someone who just submits a new idea without first getting acquainted with the overall vision.
2 - The submitted code should be well written. If it's just a hack using borrowed code from other source with a few modifications, and lacking comments, the main developers aren't going to be too crazy about using that code. "Oh great, he just went and copied and pasted this other code, made a few hack changes to it, and now he wants to use it." Come on, let's have some pride in our work here.
But I wouldn't call this a problem. Say 0.1% of all opened projects on Sourceforge (just as an example) will really become mature, widely used, big open source community projects. Aren't those 0.1% worth all the effort? Aren't those 0.1% worth putting up with thousands of dead projects because the developers didn't have time or weren't stubborn enough to carry it out? Would you rather have to certify yourself and prove your product's quality before you can post it on the 'net?
I myself started four OSS projects (one of them a community web site actually) with several people, and three of them are unmaintained ATM because I simply don't have the time to continue them. That doesn't mean they rot, though.
So, to summarize, I would LOVE to have 1000 closed, elitist, non-maintained projects floating round the Web - if that's what it takes to produce the one single genius project that changes our world. See Samba, Perl, GCC, Apache, or whatever you like ...
Home Page
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
I wrote a guide to becoming a Python developer that will be of interest.
This is a very good topic, but I couldn't help chuckling. I was thinking about how this story had to make it through the slashdot submission queue in much the same way as code submissions make it through to oss project code bases.
I've always wondered if energy put into optimizing the code development process would be amplified in the code developed using the process.
I mean, if there was an easy way to submit fixes, and also an easy way to view the fixes against the code to see what they would look like, and an easy way to apply them, would this happen faster (or be more likely to happen in the first place?)
The same thing would go for source control and bug tracking. Would effort into these "infrastructure" tools carry over into more/better code in lots of other areas?
I wish I could mod this up. :) all I can say is 'yeah!' despite it being a bit too personal. Not everything is about producing big powerful software projects to take over the world. The simple ability to see the code and learn from it and (typically) incorporate ideas from it into your own stuff, or adapt it to a specialized purpose, has huge value.
The reason is that he doesn't have the resources to handle all architectures. He recognizes that there are other people who are competent and have the machines needed to actually test the patches.
So why didn't somebody on the list tell pulsar what channels to go through? "Linus actively maintains only the x86 version, but here are the addresses of the maintainers of ports to other architectures" is better than "WONTFIX. Period."
Will I retire or break 10K?
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.
I work for a game developer. We have a lot of fans, and the general consensus, among our fans, is that we make games "for the fans." That seems reasonable enough. But "fan" is a loose term. Some--many--are raving, frothing idiots who want us to bend to their every whim. Others say they love our games, but then they have personal agendas that they want us to follow, and they go ballistic when we don't. The simple truth is that we can't listen to them all, and it's arguably better if we have minimal contact with them.
Open source projects are similar, in that potential contributors come from widely varying backgrounds of experience, sanity, and understanding of how large software projects need to be managed. Would most contributions be ignored? I would think so, as they're either (A) too hacky; (B) too messy and complex; or (C) not in the best interests of the project as a whole.
This was obvious even before the term "Open Source" became a buzzword, and I'm surprised that ESR, et al, never addressed it. Perhaps they were thinking of the "good ole days" when there was a more closed circle of UNIX hackers and not the current state of zealotry as we know it.