Slashdot Mirror
SourceForge Fails To Forge Source?
An anonymous reader writes: "I've observed the development of the SourceForge software and documentation during the past four months and I'm amazed to see that it's developped in a closed fashion, opposite to all of the open source ecology standards.
About the only thing related to open source is the publication of a tarball containing the php scripts used to run sourceforge. It has been published in a as-is fashion, no packaging effort was made. The only documentation included was apparently provided by volunteers and is outdated since it refers to the previous version. This documentation only covers a small part of the software.
There is no CVS tree for the project, not even read-only. Given the fact that three months elapsed between the last releases, there is no way contributors can do a proper job. At the same time VA Linux evangelists attend conferences repeating the golden rule of open source colaborative development: release often.
The only way for contributors to participate to the SourceForge development effort is to submit patches using the patch manager. The SourceForge guys will then decide if it should be integrated or not. Well, this could work if they were careful. But the situation is pathetic : patches sit in the queue during weeks and some of them even don't have a followup. It does not matter much anyway since there has been only nine patches since the beginning.
The SourceForge site documentation shows another remarkable mistake. It is maintained by volunteers. It's far more accurate and complete than the default site documentation but is not easily accessed. When clicking on the Site Documentation link it first shows the outdated documentation and a link to the volunteers work is only included at the bottom of the page. This is a minor issue. Much more annoying is what apparently occurred last week. All the volunteer work was trashed and replaced by a new system without notice. The volunteers protested but the SourceForge staff didn't care to reply ( the thread). The guy who did the mistake didn't even care to commit his changes to the CVS tree of the documentation project. The CVS tree does not match the content of the documentation anymore.
Behaving this way, the SourceForge staff does a big mistake. First it frustrates potential contributors, second it does not allow them to scale well. It's pretty obvious that they are completly overloaded with work and that they really need help.
What kind of conclusion can we draw ? The worst would be that the SourceForge staff is a bunch of talented programmers who do not believe in open source, even though they provide tools to help its development. The best would be that they need the open source community to kick their ass to go back in the path :-)
I sincerly hope that SlashDot will publish this bit. But VA Linux now owns Slashdot and may be immune to this kind of news ... "
CT:Technically VA Linux doesn't own Slashdot. Andover.Net does: the deal hasn't closed yet. And nobody is immune to 'nuthin, however I have slightly different opinions: releasing and maintaining a good open source package is hard and time consuming, as I learned firsthand with Slashcode. The vast majority of users don't contribute back (unless you count complaining). Don't get me wrong, I obviously love open-source development, but when the bitchers get to a critical mass, those who can actually add something positive get drowned out, get bored, and do other things.
It wasn't until Andover.Net came along and hired Pudge and Patg that it became feasible to bring Slashcode to a solid 1.0 release. Now, for the ultimate irony: Slashdot itself is a release behind the latest code ... at least for another 48 hours or so. For the year between the 0.3-0.4 tarballs, and the 0.9-1.0 Slashcode tarballs, I committed virtually every sin listed up there. My point is that its hard to maintain open source packages. Especially when the negative comments outweigh the patches fixing the problems, and on top of that, you have another job (like running a Web site for example ;) It's often a case of the best of intentions being bogged down in the most mundane of details.
Of course, since I obviously am simply a mouthpiece for various corporate entities my opinions are irrelevant and discardable, have a nice day ;)
Presumably there is something wrong with this line of reasoning, or the FSF folks would already have pursued it. So, can anyone explain why this wouldn't work?
-rpl
>My point is that its hard to maintain open source packages.
Which is why YOU shouldn't. Here's how Open Source works:
1) Programmer A has an itch.
2) Programmer A scratches until the itch stops.
3) Programmer B tries to use the same program to scratch his itch, but finds himself only half-scratched. He patches until the itch is fully scratched.
You seem to be overlooking the fundamental problem with releases - programmer B has to *UNDERSTAND* the code that programmer A wrote.
This involves one of two things.
Option #1: Programmer B has to spend weeks digging through leftover cruft that programmer A didn't bother to delete and reverse-engineering code that programmer A didn't bother to document and finding specs that programmer A didn't bother to write or point to.
Option #2: Programmer A has to spend a few person-weeks of effort and clean _up_ the code, _write_ documentation, and attend to all of the other details of packaging the release that allow other programmers to modify it without pain.
This takes a LOT of effort, and if it has to be done in one-hour chunks while you work at your day-job or take courses full-time or what-have-you, it will take a long time to do.
I've done this myself. I wrote a series of extensions to the driver for the Linux Media Labs 33 video capture card and posted packaged results to the web. http://www-ug.eecg.toronto.edu/~thoma sc/lml33.
Please make sure that you have full knowledge of the effort involved in a task before belittling someone else's efforts with it.
Here's a thought...
Maintaining OSS projects is a lot of hard work, and there is no real clear way to go about it. This article is not the first gripe I've heard pointed toward an otherwise "good" company, and we risk scaring off more corporate OSS involvement if we trash the people we already have. So I propose this:
Why don't we put together (as we I mean people who have successfully maintained large OSS projects) some information on how to do this. Some DOs and DON'Ts, some guidelines, and people to ask for help when things go wrong. If we, the community, provides help for how to maintain a project, not just for the project itself, we might see a lot more corporations playing nice.
http://kered.org
But Programmer A's son just got caught scratching his itch with Programmer B's underage daughter in the back of Programmer A's Chevy, and Programmer C is still at home scratching himself. (Ew.)
Just thought we should consider the human element.
Seriously though I think your flow chart for OSS growth is a bit optimistic...it sure would be nice if it did work that way but whenever you get more than one person involved in something there will be conflict.
The Divine Creatrix in a Mortal Shell that stays Crunchy in Milk
The House Between - Original Sci-Fi Series
Do not look a gift horse in the mouth. This old saying is also applicable to open source code. When someone gives you something for free you either try to figure out how it works with the little help they provide or you pay big bucks to someone who will do it for you.
Personnaly I prefer the first choice because it prevents me from becoming a trained monkey who can do something whithout knowing what I am doing. Having someone else do ALL the hard work for you will result in creating uneducated users who know little or nothing about the software they use and the dangers associated with doing so. If that is what you want try commercial software. Albert Einstein once said: "Make things as simple as possible, but no simpler"
Open source software gives users and developers a lot of freedom, but freedom doesn't come easy. You usually have to fight for it or struggle to achieve it.
There are 10 kinds of people. Those who understand binary and those who don't
is that people are complaining, and not fixing...
try this logic
if(ProblemInCode(ProjectName))
FixCode();
else
UseCode();
Note that the function ComplainProfusely() is not in there...
if theres a problem, shut up and fix the damn thing...
... hi bingo
As the guy who oversees handling of patch submissions to sourceforge, I can tell you we DO make a great effort to accept and use quality patches. The original poster was wrong on several counts, but I'll address just the patch situation. The fact that "patches sit for months" means they are either unusable or we don't want them in the main tree, but we do want them available for other people to use. One example is a postgres support patch. We use MySQL so are we really going to apply a postgres patch to our main code base? I receive most patches via email, not the patch manager, and have actually applied and used at least a couple dozen patches, most of which were included in the 1.1 release of SourceForge. No, not every patch was accepted, nor should they be. As far as docs and the handling of the code release, why not pitch in and help if you're such a wonderful OSS advocate and wizard of documentation?
When a project is 'open source' or 'free software', the author of that project is giving you something because he wants to. It doesn't sound right to bitch about the quality of it.
I don't think it's very cool or nice to not make a CVS server available or any of the other things you seem to hate, but they're not obligated to do that. In fact, if they wanted to convert all of their source code to EBCDIC and distribute it that way, sure, it would suck, but they're still giving you something that you wouldn't have otherwise had.
What's the license? If you're so fed up with their efforts, you could just fork it. I realize that there are a lot of strong pressures not to do so, but at the same time, the right to fork was made for situations where there are large problems like you seem to say there are here.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
Well yes it would be nice for everyone to contribute, but sometimes people dont have the knowledge base to release the patch. So what they can do is point out the problems, just they tend to come across as whining or complaining.
So remember that when you email a bug or problem BE POLITE. Who knows, you could be on the other end of it some day.
Hrm loving these
My point is that its hard to maintain open source packages.
Which is why YOU shouldn't. Here's how Open Source works:
1) Programmer A has an itch.
2) Programmer A scratches until the itch stops.
3) Programmer B tries to use the same program to scratch his itch, but finds himself only half-scratched. He patches until the itch is fully scratched.
4) Programmer C tries to use the program and finds himself 90% scratched. He patches until the itch is scratched.
5) Etc
As more people use the software, it magically grows more features to cover all their needs. So in your example (CmdrTaco), you don't need packaging--so don't do it. If someone else needs packaging they'll do it. If no one needs it, it doesn't need to be done.
In any case, do only what you need done. Then release. When people submit changes, roll them in and re-release. It's really very easy.
It's a very very bad mistake to try to run an Open Source project just like a closed source one with the occasional "public code review".
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
It seems you have an incredibly naive view, although that view is supported - it's the philosophy of how open source works. But in reality it's a whole different picture... What tends to happen instead is things stop at point 1, unless your code is already at point 4, so you end up spending hours, weeks, months, writing your code, improving it, fixing it, promoting it, and still no patches come in. Eventually you get to point 4 yourself, if you put in the effort.
But that's OK - because you've got a great product that people use. I have a couple myself that I'm very proud of. But patches are extremely rare until you hit a really large critical mass. Take all my open source projects combined (XML::XPath, DBIx::AnyDBD, AxKit, CGI::XMLForm, DBIx::XML_RDB, Time::Object, XML::PYX and Win32::ASP - all Perl based, all (most) used quite a lot). I recieve about 1 or 2 patches a year (in total - not per project). Thats not a whole lot, and not enough to keep a project going without me.
I'm not complaining though - these projects not only scratch my itch, but they were/are fun. I still get the "open sauce kudos" - although it's not as prevalent as ESR makes out in CatB.
The point of this is: Patches do _not_ happen until there is critical mass. And critical mass is a lot bigger than some people believe. (although the argument is probably moot for slashdot and sourceforge - if they're already getting patches they've probably achieved critical mass!)
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Free software is software with no restrictions that prevent you from using the software to its fullest, nor any restrictions preventing you from helping others use it to its fullest.
:-)
Well, jiminy jillikers, Radioactive Man! Sourceforge is relased GPL! You can't get any more "Free software" than the license endorsed by the guy who coined the phrase "Free speech, not free beer"!
So what if they're using a closed development model? "Bazaar" development is not a defining characteristic of free software, after all.
If you think that an open development process would make sourceforge's code even better, for your site, start hacking yourself, put up a webpage describing what you've done, and start a mailing list! (I bet you might even be able to host it on sourceforge!
If, however, you think that the Sourceforge coders are doing a good enough job, lay off!
Also, I'd suggest a read of the Mythical Man-Month. There's no saying that adding more coders to the Sourceforge project would make things faster.
SourceForge is a great boost to many open source projects, especially in providing CVS servers, mailing lists, web hosting, patch management, bug databases etc etc... Their service is fast and reliable, and you even get technical support from people who knows how to help.
SourceForge is probably doing more for the open source movement than any other single entity. They could change money for it and nobody would question it because their service is so great. But they don't. They could be proprietary, but instead they use only free software. And on top of all this, they even release their sourcecode for the project, as if they had to!
And then what: people complaining that "SourceForge doesn't help the open source movement because they release their source as a badly organized tarball and they didn't include my patch"! I mean, WTF! Fscking whining maggots!
SourceForge now hosts the entire KDE CVS. They gave it a dedicated box, and they don't even ask for a single mention of this in return. Think about that the next time you use KDE.
I can see why the poster would choose to be anonymous -- most trolls do!
--
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
I mostly agree with CmdrTaco that running an open source project is complicated, as the folks learned from releasing Slashcode (btw, I also have quite specific complaints about the management of Slashcode project, but that's another story).
But seems to me that there is a fundamental difference between a generic, huge-user-base software (mostly clients or desktop software, e.g. my favourites gnucash or fetchmail) and software that was originally developed for a very specific, site-related task and therefore suffering from a lot of idiosincrasies of the only installation.
For SourceForge, as for Slash, first was the site, then the software used to run it. Then, at a very later stage, you try to repackage the whole thing in order to let someone else use it, which is a very complicated thing and needs an extra set of efforts.
"It is more complicated than you think" (The Eighth Networking Truth from RFC 1925)
Linus takes are very hard when it's ready line with the development. Sure Alan does a kick ass job of getting pre releases out, but you don't hear as much bitching about that.
After releasing one small GPL program (that was only really usefull to perhaps a small group of people) and getting nothing but flames, I know the feeling.
With VA taking a pounding in the NASDAQ maybe they had to lay off all the project managers...whos knows why. But sometimes it seems that the Linux community (and to a lesser degree, the Free Software Community) takes the approach or bitch first, ask questions later.
-- Are you an EFF member yet?
It seems to me that although open source has forced a major improvement in software development, it's done the exact opposite for manners. Since when was it polite to tell people how and when they should do something? They (like me) will release their source as and when they see fit. You have *no* right to tell them otherwise you miserable little bastards. Accept what you're given gratefully, else you may find you won't get it again.
Now weary traveller, rest your head. For just like me, you're utterly dead.
But, if people cared to check on http://sfdocs.sourceforge.net/, they will note the ease with which volunteers may now submit documentation to the project. Not only this, but also the number of staff written articles on SFDocs.
Of course, the offer is always open for _anyone_ to submit documentation at any time. =)
regards,
Quentin Cregan (aphzen)
Support / Systems - SourceForge.Net
I understand the complaints here. I also understand Taco's defense. Perhaps what is needed is three sets of code: stable, unstable, and sausage. The first two would require administration and be prone to the delays and inconsistencies attacked above. The "sausage" directory would contain code, unsubstantiated patches, unincorporated features, lips, dirt, bits of hair, etcetera. That way hardcore open-sourcers could get at the bleeding edge stuff themselves, and could even fork the project if the official maintainers weren't keeping things far enough up to date. But meanwhile, those controlling the project would be able to keep a well-organized, documented version that was officially unaffiliated with that vat of partially defatted fatty beef tissue over there.
Of course, there would still be complaints that patches weren't getting out of the sausage bin quickly enough. But at least then if the complainers became numerous enough, they could mount an effective response.
- Michael Cohn
-----
Go ahead, blame me... I voted for Nader!
I think that's the biggest mistake of the SourceForge team right there. First, they screwed up. Now that's ok, no one's perfect, and we ALL screw up from time to time. I certainly have. :-)
But, the problem is when people who are volunteering their time complain, and theu didn't even have the decency to reply to their posts/e-mails and address the situation. I tend to agree with what CmdrTaco said, in that it's a lot more work than you think. But, I don't see why the SourceForge staff couldn't have taken a few minutes to reply to the e-mails or posts and explain their side of the story.
Let this be a learning experience to the rest of us in the value of addressing peoples' comments in a timely manner. :-)
The GPL covers code distribution. A proprietary third party could, however, take the code, make improvements to the code, and put up a competing site using the improvements. Nothing in the GPL would compel them to release the improvements.
Do you know how to extend a GPL style license to the web? I don't. I know that several key people from the community are working on the issue, as well as several high paid lawyers.
Check Slashdot's interview with Stallman, and look at Bruce Perens' questions for him. You'll see that Stallman acknowledges that (a) the GPL doesn't address this issue and (b) the issue needs to be addressed.
Everyone at Sourceforge is doing the best they can to work things out, but folks, we're in ucharted territory, so bear with us.
Mark Stone
Media Publisher
VA Linux Systems
strider@linux.com
It's not different from what you said, but you make it sound incredibly easy and as though it's automatic. Promoting open source software is just as, if not more so, important as for closed software.
The point is, I'd love to have lots of people use my software. It's _good_ software. But people don't use it until it's worth using. And people don't patch it if they're not using it. It's kind of a catch 22 situation. So saying "don't do things if you don't want them" is all well and good if you want people to go elsewhere for their software - maybe to a closed source package. But if you want people to use what you produce, and obtain that critical mass, there's a lot of effort goes in before that occurs.
And the old 300-liner application doesn't quite count, IMHO. Apps like that are easy to patch, and often only require small fixes, and are never going to grow into much larger apps. The packages I'm talking about in my comment run into the thousands of lines, and to improve require that intimate knowledge that only either large numbers of users or the sole developer can bring to the table.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Option 1: Realease early often and show the world all the work you are doing. Including the dumb stupid moronic bugs. Get flamed for putting out such low quality work.
Option 2: Release periodically when you have a nice stable point. Make sure as many bugs are out as possible. Get flamed for not being open source.
Oh this sounds like fun. Yes I'll admit the hypocritical part of this (with them preaching the realease often part) sounds odd. But this is really their choice. And its all still compliant with GPL. Released in a timely fashion. Yes it'd be nice to see a CVS repository and a tar ball release, but that's tough.
-cpd
I agree in general with the concept that open sourceing things is hard to do and a big drag when people are complaining.
However, when talking about Andover and VA and others, I think it is fair for the community to (politely) demand better behaviour. The officers and employees of these companies only have jobs and overvalued equity stakes because of open source/free software/etc. If it were not for this movement many people would not be multimillionaires at this moment. As such, it seems only fair that they should be held strictly accountable to the principles on whose back they made their fortune.
The constant routine of "do as I say not as I do" because a) "I'm sleepy" or b) "I provide a "free" website so leave me alone" is beginning to leave a sour taste in my mouth after hearing it from the same offenders 100 times over.
I can understand how the folks at SourceForge feel and certainly can identify with the growing pains. Like CT and the poster say, it is hard being open and making those initial steps to recalibrate your brain into that mode.
OTOH, what also was not said in this piece (or maybe I missed it) and I've made this same comment on the SF forums is that not all the source for SF has been released. Their cron code which does alot of the background processing to sync what's in their database to the "state of the system", user id creation, mailing list creation, etc etc etc has not been released. There have been more than a couple of calls for it to be released but the SF staff for some reason doesn't want to do that. It would kinda be like Linus releasing a kernel minus the memory management code.
I don't think there's any question that SF is going to have to make the step and fully open up. If they don't, I think it's quite probable that they will see alot more critical commentary pointed their direction.
Now obviously the SF staff are a bunch of folks who should be commended for the great service they are providing for the community.
Yet now they are in the role of really a leader in the Open Source World, unfortunately it also means that they need to be a shining example of Open Source at it's best. It's time they take that step. Regards, Tom
I maintain some minor free software packages, and the flames/whining[1] vs. praise in my email is about 0.1 or so. I.e. much more positive email than negative. I talked to a friend who put in a lot of work to maintain a web site / database about cultural events, and asked if he didn't feel the positive feedback compensated for the hard work, expecting a similar ratio. But he answered that the ratio was the opposite.
/. posters act personally insulted, each time an /. makes an editorial choice they disagree with.
Which makes me wonder: Are users of free web sites a lot more inclined to whine and flame the people who provide them, than the users of free software? It certainly fit the way some
[1] I distinguish between "whining" and constructive critisism by the whiners seeming to think they have a right to *demand* improvements, or feel cheated if the free software doesn't solve their particular problems.
Some of the problems described are far from unique to Source Forge, but one of the beauties of the open source and free software models is that if you don't like how the project is being run, and you care to do more than bitch, you can fork the project. Two of the most notable forks of free software forked from the temple of the high priest, and for reasons which included some of the complaints listed here. egcs forked from gcc in part because of the slow (or nonexistient) release cycle of gcc, and XEmacs forked from Emacs because Lucid couldn't cooperate with RMS.
As for documentation, in general, documentation sucks because developers hate writing documentation. There are exceptions, but they are no more common in the world of open source than in the world of closed source.
If you don't like how the Source Forge software is being developed, and the differences are irreconcilable, fork it. If you don't like how the Source Forge documentation is being maintained, and the differences are irreconcilable, fork it. If you're right, your project will flourish.
First off, please read Mark Stone's post above regarding the web/asp issues and the gpl, they are -very- important. This represents one of the biggest problems for us (by us I mean all of us) right now. That said, we do releases based on the gpl every couple of months, so I'm fine with that.
While I understand the frustration the AC felt with the patch and documentation systems (more on this later) the AC should realize that when a group does work on an open souce project many people choose to go the route of tarballs every few months. You may not like this method, I don't. I asked myself last week why the cvs tree wasn't public, and while I did not agree with the SF team, the fact is, since they have tarballs coming out often (and I tell you, every two or three months is a completely reasonable interval) I'm not going to tell them how to run thier project. Any more than I would tell mandrake or raster how to run enlightenment.
It sounds awful, and counter intuitive, but many of the OSS worlds best projects are run with an iron fist without external cvs servers. Not that I wish to equate SF with the importance of the Kernel, but when was the last time anyone saw a cvs server from Linus?
Now, the patches and the rest, I'll take a look at what's up and see that they pay greater attention to them, but again, a few procedural mistakes in the early stages of an OSS project is common and forgivable.
So what I'm trying to say in a nutshell is, if SF is only released every three months, and if they choose to completely ignore outside help, that's fine, that's a choice they are making. I don't think it's the most efficient, but it's thier choice to make and I'm not going to interfere with how they practice what so many others don't even have the courage to preach.
Anyhow, if anyone would like to contact me personally about this, please email me at chris@valinux.com (or chris@dibona.com).
One last thing, I can't stress enough the importance of Mark's post. IF you didn't read it , you should. The GPL as written basically allows people to write an ASP like SF and put it out under the GPL. At that point, another person can take the code and set up thier own public SF, which is fine, but any changes they make don't have to be redisributed, which is not. This is a -big- problem, and if the GPL is not fixed, there will need to be a new licence made to address it. We'd rather just use a GPL that covers this contingincy. I'm of the opinion that a clause in the next version of the GPL that says that "public distribution as defined includes use on a public web site" thereby introducing the redistribution requirements for such uses, but I'm not sure that this sort of language will work to promote GPL'd software in the right way.
Anyhow, any thoughts on this would be appreciated.
Chris DiBona
VA Linux Systems
--
Grant Chair, Linux Int.
Pres, SVLUG
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.