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 worked on an open source project, but as soon as the code was in a state suitable for our purposes, we stopped development in the project and moved on to new frontiers. I think it's quite normal that a lot of these projects stop in the early stages.
The ones which involve giving intellectual properties away free over the internet.
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.
Look at FreeBSD - they are fairly open, in that anyone with GOOD idea will be eventually admitted. However you can't just come in with a bunch of code that does not conform to their guidelines and does not do something within a current plan and hope they will take it.
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.
What we need is a software tool that helps people fork. You run your new forked version of some source (say "info" with the fixed navigation keys) and then it monitors new updates to GNU's info distribution and changes yours accordingly. I think a fork-monitor app like that is important for free software development. It would get more views across.
Someone mod this one up, please....
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.
I found horde to be one of the best at this (I really like their discussion lists)... even the developers are really busy, they take the time to reply to every little comment/problem/suggestion, and often they incorporate patches/suggestions in the main development code... I really like to thank the Horde development team for that.
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.
.sig available on 'Need To Know' basis only!
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!
One of the few projects I've actually tried to get involved in is called Worldforge. It's a good-sized and really ambitious project for creating the framework for building a variety of MMORPGs. I found them to be very helpful and very patient with me, even though I quite frankly couldn't find a pointer with both hands. I don't know what would happen if you submitted a patch out of the blue, but I did get the impression that the entire group is very willing to take new ideas seriously.
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.
You want the truthiness? You can't handle the truthiness!
...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.
OSS is founded on the idea of programmers giving away their time for free to help you with your project. Sure, you get a almost minisculely better piece of software in return, but it's more productive to go out and make some money with your programming time so that you can waste it all on cars and girls. Damn skanks.
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've had problems with a project where the person who started it worked on it a little then stopped doing anything on it. Now he has no interest whatsoever in it, but still refuses to give up control. Fortunately, the GPL allows me to fork off my own version if I want to.
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
Not letting go of what you have created is probably one reason: Software-prj-mgmt-HOWTO.
This is JMHO, but the several projects that I've been close to you end up having, what I call "the starry-eyed visionary" syndrome -- akin to a leader of a small religous group.
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.
Old age and treachery almost always overcome youth and skill.
Let's take a 'half-dead' project whose members reject your code. Assume that the project allows a reasonable open fork to be made (GPL allows this). Well, take their code, mention them in credits, and set up your own project, add your valuable code, submit it to freshmeat.net. Voila, we have one more improved project. And then -- don't forget to accept patches from other people :-) Understand them, include them in code you know and like, make them work, etc -- it's not easy, but that's what it takes to be a project leader.
Computers make very fast, very accurate mistakes
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
Linux HA project is completely open for new members, I had very good expirience with them. Also, people who writes good code is always wanted, since project is in production stability, but far from finished. So if you have time check www site.
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 as well as the RT-Linux project.
Also, if you want to join something with the potential to be cool and sexy, go to 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
It's nice to see that so far more projects have been hilighted for being open than for not. I'd like to add Galeon to the list. The devel list happily accepts patches, even my poor attempts to produce graphics for it.
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
The Argonauts (the ArgoUML project members) are always looking for contributions and your patch should make it in the next release, if it's of any use. Just nice folks there, and if you have any concept of UML and/or Java, you're always welcome...
http://www.argouml.org
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.
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!
It is about the closest thing any bit of GNU software has come to having w4r3z. With as closed as the process is, good luck finding the source anywhere. I think David Kastrup said it the best on comp.emacs (groups.google link):
They claim they keep emacs21 under wraps because they don't want to be flooded with bug reports from stupid people who can't debug it themselves. Of course, they could still release it and just ignore all bugs that don't come from pretesters, even if just by giving the pretesters a special address to send the reports too. Personaly, I think they just like their little exclusive club and enjoy keeping it that way.
Let me be the first to say that emacs21 is wonderful, so maybe their dev model works, but it causes a lot of strife. It is, of course, their choice to pick a dev model that works for them.
However, I call upon people to mirror the source if you have it. I've built emacs21.0.105 on several platforms without much hitch. I'm a stupid, non-pretester member of the unwashed masses and I didn't have to pester them to get it working. I'm still looking for a place to mirror the source (it is pretty big, ~25MB, worth every bit of it too), but I hope to have it available sometime soon.
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.
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?
WorldForge is a very cool Ultima-online style RPG currently in open-source development. Because of the scope of creating an entire online world, as well as multiplatform clients and a complex server, they thrive on participation and feedback from the users. I designed their first village after only knowing of the project for a few hours, and it still stands today :) Anyways, it's a great project, and with many RPGs/MUDs, a great community. They have their own IRC network, and if you are interested in working on a cool and fun game, check these guys out!
# wrote sig.txt, 23 lines, 31337 chars
Try FVWM if you're inclined.
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?
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
If the idea behind the project is still worthwhile, and yet project management is screwed up that it is ruining that idea, can you not fork the project? If what you say is true, then you can't be the only one experiencing it. Create a new version, a new distro, and incorpoarate all the bug fixes that the other project doesn't. You are allowed to do so, you know. Use it as a last resort, but the truth is that open source even has solutions built into the model for this sort of problem.
Sourceforge has lots of examples of failed open
source projects. Many many times I find a project there I'm interested in only to find, "This project has not released any files." and the maintainer ignores all e-mail offering assistance.
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
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.
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.
I'd really award the mozilla project for beeing the most collaborative Open Souce Project. In addition this project brought some incredible useful and mighty tool to the community: Bugzilla.
IMHO a bugfix sent in using bugzilla almost always gets you a reaction of the developers.
The worst example for collaboration is the Linux Kernel:
- No Bugtracking tool
- no CVS
- Just an ummm heavily loaded mailinglist
best, domiGo 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.
PHPNuke 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).
Collaborative projects are a myth perpetrated by Eric Raymond, amongst other banal and trite observations which gave him his fifteen minutes.
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.
POKE 36879,8
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.
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 for more informations.
-- just a geek - trying to change the world
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 submitted a patch to Python, and it eventually made it in -- 1.6 or 2.0 -- it just took them a while to actually integrate it. This may/may not have had something to do with their moving at the time.
Still, status updates would be good and would encourage contributions from OSS newbies.
Paul
If everyone remember Scour Exchange last year, there was a free/OSS client for linux. I submitted a patch that made searches more efficient, erased incomleted/cancelled files, and implemented the idea of keeping "in progress" downloads separate from finished downloads. Two months went by with me writing to the author of the free scour client and asking when he was going to implement my changes (by typing one command no less!) and he never replied. I guess I never really got steamed because about 2 after I wrote the patch scour went offline. I could see this kind of thing happening with a lot of projects
Working with the Apache XML people was great - at least on the C++ side.
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.
I do everything the voices in my head tell me to...
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 have got to be some of the most collaborative and open projects out there. Go read
the Apache Jakarta's Getting Involved document to see how to get involved there. It's the same for all Apache projects.
I contributed a little javadoc-related chunk to the JRE (environment for Java development under emacs), and the author promptly put it into the next release. I think at least half of that project is minor contributions from people who want to have something their way, make it, and then decide to submit it...
-S
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.
Yes, /all/ open source sw projects really should make a point of complementing the openness of their source with honest statements as to the policies, philosophy, goals, and state of the software in their project, at least a sentence for each.
That way potential users and contributors can avoid potentially huge time sinks hacking at software not right for them. They can instead make intelligent choices and not have to learn so much the hard way.
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.
"Be thankful you are not my student. You would not get a high grade for such a design
Dude, I meant the JDK.
Got my acronyms wrong...
-S
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 ... :-(
wait uhm, that's not it either...
-S
[Disclaimer: I'm a dev on the PostNuke development team, so my views and opinions might be slightly skewed, but no less accurate.]
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
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.
and I don't think it's my fault. I feel better about this posting if it's anonymous.
I'll write about a project I have made GPL on Sourceforge. It's a developer tool, so the potential users are certainly those with the ability to contribute. It has been downloaded hundreds and hundreds of times, so I assume many are using it. It is the only tool of it's kind for Linux, whether free or commercial. It contains good documentation as to the design and structure of the program.
I have not received a single comment, good or bad. I have not received a single line of code fixing a bug or adding a feature. I have not received a single thank you.
I use the tool daily, so I know it is not perfect. I don't know if others find it so good they don't know what to contribute (unlikely), they find it so bad it is useless to them (I know it's useful) or they are just a bunch of leeches and will never contribute anything.
I'm certainly open to accepting patches. The documentation says so, too. I have no idea how to inspire others to contribute, though. The project could benefit greatly from other peoples input.
An interesting corrollary of the effect noted in this story: I've occasionally posted, as an AC, comments on Slashdot threads - very relevant comments, on matters that I was plainly unusually well qualified to speak on - and without exception those comments have been ignored by the moderators, remaining permanently at their initial score of zero. This discourages me from posting on any future threads. Slashdot produces some great discussions, but it's obviously not participatory.
MAME is open source and does accept outside submissions. And I know more people who use MAME than people who use Linux...
Clarification of original post; deserves wide exposure.
...and precisely because of nukelite's inability to cooperate and work in an open/source environmnet was PostNuke created - and precisely because it implements a truly cooperative environment has it grown quite popular.
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
I think that the mosix team is very good at accepting suggestions and patches. They have always been very open and willing to accept new ideas, as well as respond to the status of the suggestion
I've seen a number of posts about projects that seem to have some management issues, so I though I'd throw out a positive reference.
Request Tracker (rt for short) is the project of Jesse Vincent. It is a ticket system, written in perl, front ended by apache and mason (in 2.x) has cli for those that want additional functionality, a bit of an API started, and also accepts ticket submissions by email.
We started using RT here back in the 1.x and are now running 2.x. A LARGE number of current features have come from users and additionally, user submitted code. It is amazing the number of times a message on the rt-users list has mentioned something, and a few hours later a reply from jesse stating that its been added, or a code segment offered by a user gets incorporated in.
So "props to jesse" for managing an open source project the way many of us think it should be done.
- Stephen Feather
----- LoboSoft specializes in Digital Language Lab
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.
xfree86: bug reports ignored forever, probably because my ati video card driver isnt being developed further.
gcc: never seen to be able to reproduce my various bugs, even with source code and everything. reply after a month or so, by which time i've moved onto other things.
redhat: pretty good, they are responsive and actively track and fix stuff.
ximian: again, pretty good, although they bugzilla was broken at the time.
various small projects: code never made it in, broken links on web pages are still there, etc. Usually when I report a bug I get a reply saying that they don't have time to look at it at the moment. To be fair, when someone submitted me a patch for my project it never got added because I didn't have the time. Of the few things I have done, they served their purpose and even though the source is out there I dont have the time or motivation to work on them further.
As you can tell I almost always submit bug reports for stuff because I figure if its free software its the least I can do to help. Even though it hasn't always been positive I would encourage everyone to do the same (after checking out a cvs build, and making sure it hasnt already been reported).
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
I get 15-20 e-mails a day related to my project but they're mostly half-assed bug reports, or just, "Mondo doesn't work. I be using Linux 7.1; please help!! Thank you!!! I wait you respond.." etc. I only get one patch per month or so.
I don't object to that: I knew the job was thankless when I took it. My point is, I have always encouraged users to participate but most of them don't. I suspect this is the case with most Open Source software projects, whether the authors call users to participate or not.
http://www.microwerks.net/~hugo/
Not only that, but they could probably use a few more developers seeing that they've been attacked by AOL lawyers recently, as read on slsahdot.
Berto
SAPDB is the open source incarnation of SAP's Adabas-derived database. It's a wonderful package, with much potential.
This is an example of a company-sponsored effort,all forms of development outside SAP appears to be discouraged. Source code is released in tarballs without advanced warning. There is no CVS access.
There seem to be several issues involved:
1. SAP employees want to define 100% of the feature set. They see it as their internal project which they release for external use "as is"
2. Weak internal documentation, in German
3. Weird issues related to source code shared between the GPL SAPDB, and other, closed source, SAP projects. The developers refuse to explain how these work, or document them.
Matt
Some open source projects that are in pre-alpha don't want any outside help until they hit alpha. The people running the project want enough of a code base down that other people can see where the code is supposed to be going before they make submissions.
This is the case with some projects that I'm working on.
This doesn't address the issue of projects that are actively asking for help, though. I've never encountered a project that is asking for help, and has ignored submissions that I've made.
-- Nolite audere delere orbiculum rigidum meum.
I don't know if this is because of Perl's easier level of entry, or the quality of coders interested in the project, or the project leader Andy Wardley, but it's great to see. It's one of the reasons this project has gone so far so quickly. Not too long ago, TT was just an idea, and now it generates every page on Slashdot.
In my mind, one of the things that makes an opensource project stand out as "open" is that anyone can come in (even if they cannot code a line of C/C++) and help test the product. And when/if they find a bug (and it will be when in the case of many opensource projects) they can access a public bug database, enter the bug report, and have full access to what happens with that bug. In addition, anyone can come in and help to confirm that bugs really do exist or verify that they were really fixed.
Several opensource projects that I know of actually pay developers to test the product and handle bug related tasks. Other projects will accept bug reports, but only to a black-hole email address where what is submitted may end up on a to-do list much later.
However, to have an opensource project that is truly open, anyone must be able to come in and assist with these tasks. I started with opensource software with Mozilla where I downloaded a build, thought it was pretty nifty, and then browsed http://www.mozilla.org/quality/help to find out what I could do to help. I started confirming bugs and was welcomed into the community not by lists of rules and procedures, but by giving the privs to confirm bugs and to edit all aspects of all bugs. I am very sure that if I had not been greeted in this way, I would not be in my second year working on Mozilla where I have gone from confirming a couple of bugs to being a component owner and a qa contact for 3 componets.
I started messing with installing/using Debian about a month ago. From the minute I started installing it I fell in love with it. Apt-get was clearly awesome and I could tailor everything to my needs.
As a project I have found both fronts here. The laptop mailing list I am on has proved invaluable to getting "sid" running (and X) on my new laptop. Always very quick to respond and very helpful.
BUT, the #debian channel on openprojects is horrible. I sometimes pick up some tips from the people on there who talk amongst themselves who are regulars but I have asked various questions over that last month and I have not even recieved one response acknowledging I asked a question. These were not "how do I install debian" stupid questions either. I know what I am doing and only asked when I had done a lot of research and not found the answers. Meanwhile regulars in the channel would ask stupid questions and just because they were known to the other people in the channel they would answer them.
Debian is the coolest system I have ever used but you get a bit of the 31337 attitude from some of the community.
If someone knows a better #debian channel please post it.
Caveat: I'm not a developer.
I have used the Hurd and was watching the main mailing lists for a couple years. From what I saw, they're open to most contributions and willing to consider the merits of different ways of doing things as long as you're willing to work on the code to bring it about. For more information please check out:
Official site
Debian GNU/Hurd
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.
Never attribute to malice that which can adequately be explained by stupidity." I've seen a few small projects pop up with Version 0.1 or 0.0.7 or 0.3, maybe add one more rev, and then stagnate. In most cases it's because the person didn't realize that managing a project like this does require real effort, and they've stopped doing their own development on it and lost interest and are off playing with other things, or studying if they're college students. Somebody else's comment about the difficulty of getting community support also applies. In at least one case, I gave up on following the project that would have been cool, was an "0.3" release, but wouldn't compile, and when I sent mail to the owner asking him about it, he sent back one reply that helped me get it to compile, but it was really clear after that that he must have never tried to run the thing, because it wouldn't really start either. It was just too rough to bother with.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
There was a fork of PHP Nuke for this exact reason, to Post Nuke. After the fork, FB then started opening up development but it was too late.
PHPBB is also the same way. They are a tight knit bunch that doesn't really allow anyone not in the main group to contribute on a flexible basis.
How would a collaborative OS project where the reviewers are conservative and careful about what they incorporate and when look different from a project not that interested in collaboration although Open Source? There are many ways of running an Open Source project and many things that can effect how much gets incorporated into the project and how quickly. Sometimes a project is started with some enthusiasm but noone, including the current leader[s] of the project has as much time and energy to devote to it. Sometimes additions are just not close enough to the general architecture of the work to be incorporated directly. Stuff happens.
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
There are two mailing lists, a developer's list and a very active user's mailing list. Users are encouraged to submit bug reports and requests for enhancement to the list, and we'll try to fix it as soon as possible.
There's a public CVS available so you can keep up with the latest version and somebody with write access will commit any good patches you submit.
This is a great project to get involved with, it's already in a usable state and it's actively worked on with new versions regulary released. I got involved because I wanted a Free alternative to Forte Agent (which works very well under Wine). Even if you can't program please use Pan and submit bug reports, any help is good.
In breif i was making RPM's for various of their packages on my computer for personal use ,while talking to the developpers on a silc channel.I was simply told they dont want packages by outsiders.Nada no never niet.
I simply deleted their software and use conventional IRC.
They would pay me that id never use this.
Their project can die !
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?
The second reason could be, that the compilation in this phase is a way of debugging, i.e. the developers would like people to compile it to test for most of the compilation errors. Please stay ahead with silc, they do a good job.
>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 inv
>
Yah right. Anyone who starts off claiming that they are "highly competent" should be shot on sight.
Linux/390 was developed behind closed doors at IBM, while Linux/370 was an open development effort by Linas Vespas and crew. Linux/390's beta was released, finally, while Linux/370's still in beta. The reason? Lots more people wanting something for their S/390s, than wanting something to play around with on superannuated i370s. Ergo, Open Source isn't necessarily the same as open development - but without Linas Vespas and Linux/370, no one in IBM would've considered playing around with Linux on the S/390.
Worth considering? I think so. Open development is how both Linux and Apache got where they are today, and companies have to be told that Open Source isn't a product or - heaven forbid - a trademark! It's a process that may involve some sacrifice of time and effort on their behalf to leverage the talent out there looking for something nice and juicy to get their teeth into.
And the willingness to meet the potential developers half-way, like making documents available in .txt and .html as well as .pdf or whatever.
As an example, I was developing the FAQ functionality of DCL (and is still unfinished) when the company suddenly had need for a trouble ticket system apart from the bug tracking. Rather than see them throw good money down the drain, I completely halted development of the FAQ system and shoehorned the TTS into DCL. Since then, some users have implemented the missing features on the FAQ.
Being that I am currently the sole developer, getting feature requests and bug reports can be a bit overwhelming and may take additional response time. I have also received a couple of patches that I didn't implement because they didn't fit in with the overall design of DCL. Admittedly, it's not currently perfect, but I make every attempt to at least remember the features that everyone has requested and *not* simply say "I won't implement that". Those unapplied patches will be reimplemented in DCL as they are common feature requests.
In the past, I had tried to proactively seek development/documentation assistance for the project. While I got several responses with interest, in the end it is still only me doing the development work. Parts of the project also suffer because of this since I have to ultimately prioritize the whole bug/feature list into a serialized, volatile road map. I would much prefer to do some development with a few more individuals so more ground is covered a lot more quickly.
So, that's my experience thus far with my own Open Source project. Collaboration is a two-way street that not only requires the cooperation of the project developers, but that of the community as well.
The AbiWord project is truly a Bazaar. In fact, they have refined some very explicit practices which are designed to help lower the barriers, allowing new contributors to join up.
Eric Sink
Software Craftsman
However, the project was quickly cancelled, because there was already another free encyclopedia project: Nupedia. The problem is that Nupedia is being developed by the cathedral method, and imposes much more onerous requirements on potential contributors.
The result is that I'm not happy with working on Nupedia, and so I'm not working on any free encyclopedia. Everyone loses.
www.jedit.org
This is an amazing programmer's editor that is moving forward very rapidly. You can submit patches for the original code, or you can develop plugins totally independent of the main tree development.
One of my favorite and most used open source applications.
TBone
"freedom is another word for nothing left to loose" Janis Joplin
I have been using Linux, Gnome, and various applications on the Linux platform for 3 years now. I use it on the server side, and on the desktop side, and have never been happier. I don't see where you are coming from stating that open source costs through the nose. I can buy a full Linux distro at Office Max for $25, and have everything I need to do damn near anything I want in the computer world. If I want to do the same with M$ windoze, I have to first pay around $200 for windows, if I want to write apps, I have to pay around $400 for MS Visual C++, if I want to write documents and make spread sheets, I spend $300 or so on M$ office, I'm not even going to go into the cost of M$ SQL server, or Win2000 Advanced server. It seems to me that the point you are trying to make is incorrect.
Why must you compensate the programmers? Are they asking for compensation, or are they voulenteering to work on an open source project? is someone twisting there arm forcing them to code? I doubt it. Same thing with project leaders.
Open source software isn't a product, it's a project. One in which you as the end user get to choose your level of involvement in. if you don't want to participate, the don't. If the only reason you code is for money, then you are in the wrong place.
What pisses me off is when companies in magazines tout using an open source solution which includes their mods, but they never seem to say how they've helped the project in general advance and what changes they've given back to the community.
If companies using open source aren't giving back to the community, I think they are breaking the law. I think that magazine publishers should make a point of asking the question of what the company has given back to the community (and where to get it).
Linux/390 was developed behind closed doors at IBM, while Linux/370 was an open development effort by Linas Vespas and crew. Linux/390's beta was released, finally, while Linux/370's still in beta.
Almost correct. The Linux/370 "Bigfoot" project is effectively dead, and has been almost since the day IBM revealed their Linux/390 project.
The reason? Lots more people wanting something for their S/390s, than wanting something to play around with on superannuated i370s.
Sorry, but that's not how it happened. What happened was that IBM had software engineers who had far greater resources to apply to the task at hand. Linas Vepstas and the "Bigfoot" folks were making great headway - they actually had the kernel booting almost cleanly when IBM spoke up. We voted with our feet, and began running the only system that was fully functional as fast as we could get our hot little hands on it. That system happened to be Linux/390.
The IBM mainframe user community has always seen the danger in forked development. We tend to support the variations of projects that have the best hope of success. When your community is as small as ours is, everybody benefits from a unified stand. "Bigfoot" had some good ideas that I really miss, and I work on Linux/390 all day every day. At a minimum, Linux/370 was poised to be one of the few platforms not succeptible to the classic C buffer-overrun failure, by the simple expedient of making the stack grow up from the bottom as God and Knuth intended.
Ergo, Open Source isn't necessarily the same as open development - but without Linas Vespas and Linux/370, no one in IBM would've considered playing around with Linux on the S/390
Again, untrue, although the public record doesn't support my claim. The stories passed along orally at SHARE meetings etc. report that IBM's effort began simply because a well-placed IBMer wanted to do it. If you talk to some of the Linux/370 "Bigfoot" folks, you'll hear that they learned of IBM's work long before it was revealed, and that they deliberately provoked IBM to open up. What is certain is that without Linas Vepstas and the Bigfoot crew, the coders in IBM's Boerblingen lab would likely never have been able to get Linux/390 out of the lab.
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?
This thread is a knock-down-drag-out over who is responsible for reviewing and committing patches in a timely manner. If a project does not have a single firm leader that is willing to do all the review work - it generally bogs down. Linux is fortunate - they have Alan Cox and Linus. TCL had its Ousterhout, Perl had its Larry Wall, emacs had RMS. Who is GCC's champion? A committee of twelve! The best open source projects in my opinion are: KDE, GNOME, Linux and Apache. Things actually get done in these groups. The pace of GCC development is glacial.
I am sure that the new Shared Source license written by Microsoft will eliminate any problems. Don't even bother to submit your patches or additions.
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.
Olivier Fourdan is very good about working others code into the XFce project. The code for many features and additional utilities (xfsamba is a great example) has been incorporated. The key, IMO, is that Olivier, while being very accepting of code and patcher, still keeps the core of the project in focus.
--
If I actually could spell I'd have spelled it right in the first place.
I've found that the Apache team is generally very good at taking patches from new users, especially the Java XML projects.
For example, the Ant (Java build tool) has a prototype directory where there are several re-implementations of the core to try ideas for Ant 2.
leaders dont want to use other peoples code,
they just want to have all their own code and
their own design and not listen to anyone else.
yes it takes alot of time to bring everyone together
and coordinate them, and you cant 'do any real programming work'.
that is your job as a leader, because as a group
people can accomplish much more, as long as they have some kind
of communication going between them. if you
are ignoring people, then you are basically destroying
any chance you will ever build a team.
would you want to work on/for a team where
team members were not included in the process?
that is no way to build a team, you need
to get everyone on board, and yes that is alot of work
but it is 'meta-programming', the result of
coordinating programmers will produce far more
and better code than any amount of single-programming
ever.
alot of supposed leaders dont want to lead
a team and coordinate, they just want slaves
who they can disrespect. they view
people as incompetent and losers, even a really
experienced programmer will get disrespected by
some of these OSS so called 'leaders', and
guess what. the 'leaders' are the ones who are stupid and incompetent,
maybe not as programmers, but as leaders.
they are throwing away perfectly good resources because
they dont understand the fundamental basics of human beings
feelings and the way they interact, and its really stupid
and has done more to hurt OSS than anything
software patents and the NSA could ever do.
ha ha ha.
maybe you could fork ming and include
the forked source with your package.
on the other hand, maybe ming is to goddamn big to do that.
perhaps you could make a 'layer', aka 'wrapper', that presents
the interface you would like to have to ming,
uses the "real" ming as a backend, and have your
xml2swf call your 'layer'??????????
now the real question, will you ignore my ideas,
or will you respond exactly why or why not you dont like them?
I think most 'public' open-source projects behave in a rather unfriendly way to suggestions, bugreports, and even when you offer to help. When such a project grows bigger, the main developers' task should change to a more 'guiding' and 'overviewing' function, as to guide all the new man-power to the projects' goal.
I always wanted to help out some projects - albeit not as a programmer, I really suck
Projects that are known to be pretty bad on this, include major linux and *bsd distributions. Qmail and slackware are amongst the worst, both being runned by very capable people with a strong vision, that doesn't allow the project to be strained even a bit. Ofcourse, if one makes a program of sorts, he can decide what to do with it, and if he thinks it's better not to open things up too much, that's his decision.
Hmmm. Not making my point here. I guess I just wish the intelligent geeks that start big projects would be more friendly towards 'outsiders', their communcative skills usually being rather limited...
I must say that I have been highly impressed with the Interchange project (interchange.redhat.com). It has been very receptive of new users and contributors, IMHO. However, it seems that the target market of users aren't very contributative. But anyway.
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.
lameness filters are lame. Here is something to fill space in this message: How Stuff Works
****Gfx Scrollbar Special case hit!!*****
Yeah, I can do all these things except that I have a plenty of other, more useful, things to do with my free time than repair the damage of someone's insolence!