SourceForge Fails To Forge Source?

I've attached a rather feisty rant from an anonymous coward criticizing the SourceForge project for releasing a tarball, but failing to be much of an open source project. 'Course since it took me a year between Slashcode releases, I'm a tad more forgiving on the subject, but the guy makes a lot of good points.

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

Comments

a HOWTO for maintaining projects?

[deander2]

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.

the major problem...

[EnderWiggnz]

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

Re:the major problem...

[Anonymous Coward]

I agree with what you are saying.

HOWEVER, I do not think that is mainly relevant to what this A.C. has said.

The key thing he is saying is that he has noticed that in the current setup it is HARD, if not IMPOSSIBLE, to contribute to the project.

Possibly himself, or at least the others who have already contributed code(9 patches) can't enter into the FixCode() functionality of your implementation(because the SourceForge maintainers have control of the codebase and are throwing out their changes. Did you see the notes on linuxtoday.com/advogato today about how mozilla may be losing its banner-ad-blocking capabilities because of an essentially identical situation in a different corporation?) I really don't think he is saying that they are not 100% open source, and thus must die, but rather that he has noticed that for a group who so loudly proclaim the merits of OSS they are having such a hard time implementing it themselves.

It's not that he's pointing fingers and saying, "shame on them, they aren't practicing what they are preaching"

If anything, I think he is saying, "It's a shame, because people are trying to help and its just not happening(for whatever various reasons)"

YES, we should not critisize without offering to help.

NO, we cannot help if the software,model,or implementation is broken.

I think what may be most important here, and hopefully will not be overlooked, is that this A.C., and others, are trying to support the open source projects(and movement as a whole). These are the people who are contributing to the metadevelopment of OSS, if you will. If I may make a statement that is hopefully not too all-encompassing, these people really care about OSS, and want to see the projects(not just _their_ pet project, but all the oss projects) succeed.

They want to help, but can't. They are ready and willing to code, but their code is being misplaced. Would you rather they go away in frustration, or would you rather hear one or two high-publicity comments on the current situation, so that things get changed and they _are_ able to help?

don't flame him for critisizing them. Flame him when he continues to critisize them(without contributing) after they fix it. Right now its all he can do to criticize them, because he _cant_ fix it.(another thing I think he wanted to emphasize in his message. He doesn't want them punished or bad-mouthed, he just wants them to fix the setup/software)

just another a.c.

How to make packaging easy:

[FascDot Killed My Pr]

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?

If only it were that easy!

[Matts]

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!)

Manners anyone?

[Psiren]

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.

sourceforce and asp licensing

[markst]

The single biggest stumbling block for a full Sourceforge code release is licensing. The team would like to use the GPL, but the GPL falls short in an ASP environment, which is effectively what Sourceforge is. Here's why:

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

Re:Good points, but...

[gus2000]

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.

Web sites vs. source code projects

[Per Abrahamsen]

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.

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 /. posters act personally insulted, each time an /. makes an editorial choice they disagree with.

[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.

Hey everyone...

[chrisd]

Hey,

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