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 ;)
>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
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
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
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.
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.
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
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
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.