Which Open Source Projects Are -Really- Collaborative? 210
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 think (Score:2)
Re:I think (Score:2)
Even with AC there, he still treats Alans patches the same way, and does it pretty much all himself..
Re:I think (Score:2)
MIT Kerberos one of the worst... (Score:2, Informative)
It's a time problem (Score:1, Insightful)
Re:It's a time problem (Score:3, Insightful)
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...
Re:It's a time problem (Score:1)
This has been my, very limited, experience.
I wrote a few hundred lines of code to solve a very specific problem I was having, and dumped it on sourceforge. I've moved on, but I do hope the code can be of use to someone else.
To me, OSS is more about developers helping developers, and having a (possibly specious) guarantee that your generosity will be returned in kind, than it is about political goals...
VERY good discussion topic. (Score:5, Informative)
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.
Re:VERY good discussion topic. (Score:2)
If the source is made available under a good license, it does - people who are not satisfied with what the maintainer does can just fork it. Some of those forks have been quite successful and needed (remember egcs?).
Re:VERY good discussion topic. (Score:2)
Re:VERY good discussion topic. (Score:2)
It is true that by accepting a patch into your project, you have stated that you are willing to support it, or atleast serve as the primary contact point for questions and problems about it.
If it is a piece of code that a maintainer doesn't see being essential to the project as a whole, and doesn't want to deal with support issues, a "contributed" area of their project is an excellent way to deal with this. I'm not saying its ideal, but if someone just supplies a patch out of nowhere, you don't know if they are going to dissapear tomorrow or not.
Contributed areas of projects are also useful for related sub-projects, such as utilities that make use of the primary project, or administrative utilities for the primary project, which may need to have separate maintainers defined.
Yes, in an ideal world, all related parts of a project would be integrated into it completely,but don't dismis the benefits of having a contributed part of a project immediately.
Re:VERY good discussion topic. (Score:2)
Open Source and the Big Fence (Score:2)
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.
contributed source has to follow guidelines (Score:2, Insightful)
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.
Re:contributed source has to follow guidelines (Score:3, Insightful)
Great! I completely agree with your points. Thus, I am sure that you make sure that
Re:contributed source has to follow guidelines (Score:2)
But, like many projects, it's something that I work on for fun in my free time. I appreciate patches from users, and am never nasty about them. But it may be days, weeks, or even months before I or one of the 5-6 other developers, has the time to deal with them.
Re:contributed source has to follow guidelines (Score:2)
I can sympathise with this approach, because I've been put in this situation before - but its really important that you let the submittor know why the patch wasn't applied, and not just let it fall into a little black hole.
One thing that really gets me going about some OS projects, (especially early projects on Freshmeat), is that they are, needlessly, locked to one platform.
I've sent simple patches to numerous projects to allow them to work on Windows NT/2000 - and the vast majority of the time I get no reply - or a snide reply back that the project is designed for Unix.
Granted it probably was, but thats not really a good reason to turn something down that makes the project more portable - I use Linux at home, and Windows at work. That shouldn't mean I have to use two mutually exclusive sets of tools..
Thank God for Perl [perl.com], and Cygwin [redhat.com]
Not all projects can be highly collaborative (Score:3, Interesting)
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
pcmcia is a good project (Score:2, Informative)
Good projects have to do it.. (Score:1)
If you are sure that your code is good and that project will benefit from it - and they don't "let you in" - just take their work, put your changes in it and distribute it to the world. If what you do is useful or necessary - they people will make the right choice.
The Cathedral and the Bazaar (Score:5, Interesting)
The author of the paper brings up a good point that ESR overlooked in his original paper Cathedral and Bazaar paper [tuxedo.org], 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 [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.
I thought this would be some interesting food for thought.
Ownership doesn't necessarily mean cathedral. (Score:3)
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.
Re:The Cathedral and the Bazaar (Score:2, Informative)
It was only after the initial publication of his paper that people started to think Cathedral == closed source.
Re: (Score:1)
Re:The Cathedral and the Bazaar (Score:1)
Collaborative social constructs that enable the accumulation of software capital will become very important for the OSS community to identify and exploit once market subsidies based on false business promise disappear.
Horde project (Score:1, Informative)
Um, do you want a list? (Score:1)
You are an AC.
You give no examples of projects that have snubbed such a highly acclaimed programmer.
So, I have to wonder, what is your agenda in asking this question?
Anyway... Your question is not too clear. Are you asking for Slashdot to create a list of projects that accept submissions?
I agree that most projects in the open source world are stagnant after the first few weeks, but I see it as simply lack of interest tends to kill off the less interesting projects. And the amount of free disk space (such as SourceForge) allows them to stay in existence for a long time.
In most cases, I wouldn't say it was lack of interest in accepting input, its simply a dead project that hasn't keeled over yet.
KDE is very good in these regards (Score:5, Interesting)
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!
Re:KDE is very good in these regards (Score:3, Flamebait)
It's also truely a multi-language, multi-ethnic, multi-cultural project: Germans, Dutch, French, English, American, Spanish, etc.
For all the sniping at KDE from wierdo Americans, KDE is, for me, the true shining example of an open source project -- far more than Mozilla or any of the other poster boys.
Re:KDE is very good in these regards (Score:2, Interesting)
KDE is one of the few projects I've seen which actually seem to *welcome* new coders, and work to incorporate their code
Agreed. The one time I submitted a (small)patch to KDE, the response was very positive. My patch had a couple sections to it and one section was applied and one was not with an explanation (someone else was already planning on making more extensive changes to that segment of code, as I recall). They seemed pleased to get a bug report with a patch. And when I checked back in a version or so, the problem I had brought up was completely fixed.
I've never done anything more with the KDE code, but that's because of (A) my lack of time and (B) my overall satisfaction with KDE's current quality. The problems I've noticed were difficult for me to fix quickly and tended to go away in a release anyway.
Worldforge. . . (Score:1)
With Linux struggling in the gaming department, I think this has the potential for being an invaluable project. I'm not contributing to the project right now, but I think anyone who wants to dig in will find that the old timers will value your contributions.
Nice question but... (Score:5, Interesting)
Time = Money (Score:1)
Anyway, true open source collaboration actually costs a lot of money. You need to find some way of compensating programers who donate their time, as well as those people who administrate the product and include fixes.
Maybe some projects can get away with charity, but in our society, we'll never see an open source community that truly rivals the commercial.
Today, if you are a small business, there are a few open source solutions available to you, but as soon as you need a piece of software that is even slightly specialized, you'll never find an open source solution.
I think OSS is a viable programming methodology, but you have to pay through the nose for it to truly work.
I have limited experience, all good (Score:2, Informative)
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
Starry-eyed Zealot/Visionary Syndrome (Score:1)
You have someone who has a vision, and is dispensing the coolaid, and as long as your ideas are not too far off "center" you're in the circle -- meaning you have their support and adoration.
If not? well, look at how we came to have OpenBSD? (which, by the way is not a knock on Theo at all -- i happen to like diversity and the work *and* the particular vision that Theo has)
I think to some extent it comes down to expectation management -- and having a clearly defined "roadmap" on the project can mitigate some of the hard feelings.
There are "user-level" implementation suggestions and of course "developer-level" implemenation suggestions as well -- you see this in the MUD's all the time -- players either eventually get tired of playing a given mud, or get IMM status and are drawn into the circle -- or the usual case, they just split off and start their own thing.
Again, the parrallels in corporate entities, or religious analagoies -- its the same.
Chalk it up to inter-personal dynamics, ala human nature.
Why not to fork? (Score:1)
Linux HA project (Score:1)
Join MY project--It NEEDS developers--All Welcome (Score:1)
Typically the larger projects are the ones that aleady have so many people involved, in the interests of sanity, code must be rejected and some questions in mailing lists ignored. However, smaller projects are EXTREMELY rewarding and really collaborative on a truly cool level.
If you want an example of some small projects that work well, check out the COMEDI project [lbl.gov] as well as the RT-Linux [rtlinux.org] project.
Also, if you want to join something with the potential to be cool and sexy, go to rtlab.org [rtlab.org] and join my project! We are developing a generic scientific experiment interface. The software is built on top of RT-Linux (real-time OS's are sexy!) and the COMEDI data acquisition drivers. This is a great opportunity to work on sexy code, as you get to do both Kernel level programming when working on the RT thread, and user-level programming for the user interface (we use Qt/GUI). Join now! Email me at calin@rtlab.org if you are interested in finding out more about the software and/or think you can help! -Calin
Galeon (Score:1)
The ego of the maintainer (Score:3, Insightful)
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
Nice folks on the ArgoUML dev list (Score:1)
http://www.argouml.org [argouml.org]
My experience with Wine (Score:3, Insightful)
I've watched the wine-devel list closely for the past 3 or so years, and I've observed the following:
Re:My experience with Wine (Score:1)
Oh, Andreas can be just as rude to long time developers, too. But I do think he is an excellent example of the kind of person needed to make an OS project work. He is almost dictatorial about where the code is headed, but is completely open to patches from anyone as long as they do not stray from that path and are good code.
"Open Source" definitely is not a magic incantation that confers success and greatness on any software. Linux would never have made it to where it is today without Linus. And I think similarly Wine would not be where it is without Andreas.
a few good ones (Score:3, Informative)
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.
Let me tell you, it isn't GNU Emacs21. (Score:1, Interesting)
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 [google.com]):
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.
Want closed Open Source projects? (Score:1, Insightful)
Look at XFree86.
This is something that's been nagging me for a while now: Open Source is bad term, not only because it avoids the issue (Free Software) in favour of looking good in the eyes of the marketing people, but it also gives the wrong idea, namely, that it is open. It's open only in that you can see the source (which is arguably the only thing that "Open Source" is intented to mean), but getting in is not as easy as it sound at first glance.
In the particular case of XFree86 the matter is complicated by the fact that graphics hardware companies have this fixation about not openly releasing specifications about hardware that's old. By the time a graphics card hits the street it's old technology. Or do you somehow think that reverse engineering that card (say, 6 months from the point when you start to the point when you get your clone to the street) will give you some sort of edge? Please. By the time you got your product on the street, your competitor has his next generation product there, too.
a few guidelines (Score:5, Interesting)
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
How would you get any work done? (Score:3, Insightful)
An Awesome RPG and Project! (Score:1)
Not all 'unsolicited code' is the same.. (Score:1)
At the other extreme, sometimes 'unsolicited code' contains (more or less plausible attempts at) new features, switches, or other user-visible or API-altering changes. In that case, it's really a set of new design decisions that are being offered, and the fact that it's already embodied in some code is at best secondary.
Design decisions take time and effort to evaluate--and often, even if there really is a problem that needs to be addressed, the first ten or twenty superficially obvious fixes for it are actually wrong.
In that sort of case, it's pretty much silly to think that anything will happen if one simply drops that sort of code into a project mailbox with a note saying 'Here are some cool improvements I've made to your project. They work real good for me'.
What kinds of unsolicited code have people had accepted and rejected?
Linus rejects many non-x86 patches to linux (Score:2)
I've yet to find an open source project that ignored unsolicited code that happened to be a flat out bug fix.
Pulsar writes [kuro5hin.org] 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.
Re:Linus rejects many non-x86 patches to linux (Score:2, Insightful)
t.
So why didn't someone on the list point this out? (Score:2)
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."
I would have to think pretty long about it (Score:3, Insightful)
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.
read the CREDITS file (Score:3, Informative)
You can always investigate the CVS logs and the CREDITS [sourceforge.net] file (warning: shameless plug for my own open source/free software project).
Regards,
Zooko
Hacker, Evil Geniuses For A Better Tomorrow
Solution for the worst case scenario... (Score:1)
PostNuke (Score:3, Informative)
For those who don't know. PostNuke [postnuke.com] 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 [phpnuke.org]
Contributor Issues (Score:3, Interesting)
- 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.
Some notes (Score:1)
How many projects actually have a detailed guideline for submitting new code?
Which one is faster and better way of development: A few dedicated persons do the whole job or a few dedicated persons do the job *and* review thousands of lines of submitted code. Usually it is faster to implement an idea than trying to understand someone's code.
Also, I don't think it is ok that some persons just occasionally drop some code to projects. If some submitted code needs fixes or large changes it is better to have the original coder available. If not, the code must be studied and changed or the whole thing must be reimplemented. It is much safer to do all the work inside the core team. What I don't understand is that a skilled coder who wants to become a member of such core team is ignored.
Good question... (Score:2)
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.)
here's why (Score:3, Informative)
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 (Score:4, Informative)
Re:Sourceforge (Score:1)
It's also about copyrights (Score:1)
PHPNuke [phpnuke.org] project (a slashdot-like weblog) makes commiting changes as difficult as possible. Nukelite mainly does not accept patches, which is quite sad, when you do the work to improve something and he reimplements your changes his way in the next version or even forgets it.
The FreeBSD project also makes contribution quite difficult, but not as PHPNuke.
I've made several project forks because of this only to find out, that I don't have the time to maintain my versions and making the fork was good for me, but mainly didn't help the others.
I also think, this is because of copyright. Many people write a GPL covered library, make it very used and then wait, if someone needs it under different license for a fee. This would be very difficult, if the code was from several different authors. So the author won't accept your patch, because it would contamine the code and he wouldn't be the only copyright holder (and so he can't sell the software or library under different license, which would f.e. allow linking with proprietary code).
Re:The PostNuke Project... (Score:1)
It's almost like PostNuke and PHPNuke can be used as examples of a good, and bad (respectively) open source project.
Harry
www.PostNuke.com
Not the point of free software. (Score:1)
The "open source" model has again warped the true meaning of free software, which is freedom to modify the software to suit yourself in spite of whatever the upstream maintainer thinks.
If the new code is applied upstream, more power to you! Either way everyone wins; maintainers don't have to implement features they don't think necessary but you may add them if you wish and share them with others if you desire.
Re:Not the point of free software. (Score:3, Insightful)
My personal experience (Score:2)
There's a project called ming [opaque.net]. 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 [sourceforge.net].
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.
Re:My personal experience (Score:2)
For the sake of clarification, I did submit a patch both to one of ming's developers and to its mailing list, but I've gotten no reply either.
I'd be happy for help (Score:1)
Doing a project on your own and in my case very alone is very hard, no one who makes you keep coding.
Look at Projectangels [tomk32.de] for more informations.
Business idea (Score:4, Interesting)
Re:Business idea (Score:2)
my experience (Score:1)
Still, status updates would be good and would encourage contributions from OSS newbies.
Paul
Re:my experience (Score:2)
I wrote a guide to becoming a Python developer [www.amk.ca] that will be of interest.
scour exchange (Score:1)
Apache XML (Score:1)
My job needed a good XML parser and Xerces, mostly, fit the bill. But we did need to implement a few things like GetElementByID() and everything pertaining to it.
Xerces was great at getting patches verified and put in as quickly as possible. The mailing lists were also a very good source of info.
It may be different now though, I haven't worked on the project for more than a year. We needed a parser and DOM that wasn't the end-all-be-all and eventually wrote our own.
Most welcome good help (Score:4, Insightful)
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!
Apache Projects (Score:1)
the Apache Jakarta's Getting Involved [apache.org] document to see how to get involved there. It's the same for all Apache projects.
well, JRE is for sure (Score:1)
Re:well, JDK is for sure (Score:1)
Got my acronyms wrong...
Re:well, JDK is for sure (Score:1)
Re:well, JRE is for sure (Score:1)
DScaler is collaborative (Score:2)
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.
I check and raise (Score:1)
G-d knows, i would have forewent all the time i spent on PHP if i'd known that the Zend/PHP4 community's focus was on quantity of functions rather than on quality of documentation and well-tested code (eg, session support, or lack thereof). To offer a concrete example of what i'm talking about.
After all, what is really the point in hiding a truth that's discovered 99% of the time before any money changes hands? You're better off putting all your cards on the table and attracting people who will stick with you. You can also undercut time and bandwidth-wasting holy war-type argumentation by just admitting your priorities, focus, and, yes, weaknesses.
For OSS to win, we have to use all of its inherent advantages, of which honest, open human->human communication is most definitely one.
To repeat, I urge every OSS project to include information as to their policies, philosophy, goals, and state of the software on their About page.
Everybuddy does NOT seem to allow outsiders. (Score:1)
This is my first attempt to submit a patch to a GPL project, but I've been a programmer for more than 20 years. It doesn't give me a good first impression of how the open source community works. I guess I'll keep applying my patch manually every time a new release comes out ... :-(
PostNuke vs. PHP-Nuke (Score:1)
PostNuke and PHP-Nuke are two slashdot-like weblogs developed in PHP.
I find PostNuke (postnuke.com) to be a good example of a functional and successful open source project, whereas PHP-Nuke (phpnuke.org) represents the opposite.
PostNuke cam into being as a fork of PHP-Nuke, simply because a number of devs were dissatisfied with the attitude of the main and sole developer of PHP-Nuke.
PHP-Nuke, while billing itself as an open source development, is really just managed and run by one person, who historically does not communicate with his user-based, and while many people constantly suggest and contribute fixes, rarely incorporates code, if at all.
This is the environment that has created PostNuke, which quickly grew into a very dynamic project, attract a large group of inventive, innovative developers - all of which work very cooperatively and effectively on extending and enhancing PostNuke beyond it's original roots.
During the slightly over two months of its existence, PostNuke has leapt by leaps and bounds ahead of PHP-Nuke, to the point where the PHP-Nuke developer has started to incorporate features that PostNuke innovated into his code - albeit badly.
While PHP-Nuke has now, officially, opened their code-base, and claims to have a developer team helping out (again a response to PostNuke's developmnet model on SourceForge and using CVS), activity level and development are nearly at a standstil for the same reason - lack of communication, and lack of management (to the point where his 'developers' are leaving the team for lack of things to do).
What does that really mean? In my opinion, a successful open source project depends certainly on good top-down management, which involves maintaining good communication with the team, providng guidance, an effective vision, and getting a team that works well together.
PostNuke.com is the result of all these factors working together well, and why we're growing really well.
Harry
www.PostNuke.com
instant messaging (Score:2)
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.
Modern expectations of software scope are too high (Score:2)
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.
My experience - the reverse problem (Score:2)
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?
Collaborative design vs. collaborative enhancement (Score:2, Insightful)
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
Perl! (Score:2, Interesting)
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.
Makedepend! (Score:2, Interesting)
PLIB As collaborative Open Source Project (Score:2, Interesting)
You can find PLIB, a 3d game development library, at http://plib.sourceforge.net
The Real Problem (tm) ... (Score:3, Insightful)
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 ...
Collaboration (Score:4, Insightful)
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.
chuckle... (Score:2)
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?
Can you listen to each of your fans? No. (Score:2)
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.
What? I don't think that's possible... (Score:1)
The reason why we can't do it is you can't ask a computer to analyze source code for you, figure out what is going on in the code, and intelligently merge vauge real-world requirements into the source. That requires extremely advanced artificial intelligence -- impossible these days.
Hell, most humans can't even do that!
software tool that helps people fork (Score:3, Funny)
--
pétard
KDE is very good (Score:2)
Their bug system also has a very active wish-list. Many items actually get into KDE this way.