Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

SourceForge Fails To Forge Source? 161

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

This discussion has been archived. No new comments can be posted.

SourceForge Fails To Forge Source?

Comments Filter:
  • It goes the other way too, if you want to influence a free software project, you should respect the people doing the work. Including the fact that they may accationally be too busy to answer.
  • 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.

    One possible solution (?) would be to make the first release a low-level basic functioning stable release and split the tree into a developmental release.

    In essense, this can give users the working version and the more functional - yet even less guarentees release. It wouldn't fully solve the dilema as we get the more anticipated "When you gonna release 2.0" syndrome - but in theory it should reduce 2 flame topics into (hopefully a lessor) 1 flame topic.
  • >And that was perfectly ok in your case, CmdrTaco. After all, you had to run the damn site during all that time.


    > Now I may be wrong, but the main job of the sourceforge guy is to maintain and develop the software, right?

    So you think the sourceforge guys didn't have to maintain sourceforge.net? Get real...

    And everybody: free vs. nonfree software is completely orthogonal with "cathedral" vs. "bazaar", no matter what ESR says.

    A lot of successfull free software projects worked and work in a "cathedral" fashion, with stable or mostly semistable releases.

    I think that at least for relatively new projects, having a small initial group of designers and developers leads to a much better design (think early versions of linux)

    There are a lot of relevant quotations about design by committee, but I'll spare you...

  • I agree with the anonymous coward. I took the time to some of the replies and the responses seem to be ah shut up and don't wine. Well first of all this project is supposed to be funded by a publically held company. It has responsibilites. Why would I consider buying a piece of hardware from a company that's open source effort is percieved to be half-hearted and crap? It is no wonder that the e./linux/.open yada tech stocks are in the toilet. You people gripe about microsoft and then cry foul when that critical finger is pointed back at you. VA blah blah blah is supposed to be in the BIG TIME with their stock being traded and all that yet, the only thing they can do is acquire the sites that have traditionally been the voice of the people they are marketing to? Sounds a lot like some one elses tactics to me. I have found slash dot to be cliqie and biased and if whoever or whomever isn't on the "list" then ./ignore ./flame ./forget. Now that the thing has funding it is even more free to ./burn ./reject anything that it finds disagreeable. This whole COMMERCIAL Linu$ thing has become a cult of personalities. I will continue to read /. , however it seems to have over the past few months to become more and more a tool for the bra$$ and less a place of information. The funny thing is that the guy who started went out and got a real job. Seems to me thats what a lot of you need to do before your heads explode!
  • So you think the sourceforge guys didn't have to maintain sourceforge.net? Get real...

    No what I actually meant was that the sourceforge guys don't have to create/post actual content. There job *is* the maintenance/development of the sourceforge backend. There is a difference here... Maybe I expressed it badly (english is not my native language)

    As for the rest of your post: Since I have never worked on a big collaborative OSS project, I guess I'll just have to blindly accept your holy word :)

  • So, why don't you fix this major problem instead of complaining about it?
  • Mark, I dig VA and Source Forge, but I gotta tell ya, I don't understand your concern. You write:

    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.

    My question is: so what? Let them. Encourage them. I admit I am no businessman. I am just a lowly little Andover.Net programmer who not only has no business aspirations whatsoever, but actually dislikes business. I don't believe in marketing (it is just a figment of our collective imagination) and I think business plans are silly. So perhaps my words ring hollow.

    But I don't say what I say out of a lack of understanding of business or a zealousness for free software. I just don't think it matters much. What is really the worst that could happen here? Nothing of significance.

  • by Anonymous Coward
    and it's free so we shouldn't complain.

    Open source done this way is pointless. Many of the posts here back me up noting how they've received so few patches.

    Here's an analogy:
    I'm going to run a marathon and I will

    • make a great effort over several months to work out and eat right
    • then...
    • get plastered the night before the race
    • wear 10-year-old sneakers with worn out soles
    • skip breakfast
    • show up late to the race
    This is like doing Open Source with your Bill of Rights. Why bother with this great heroic effort for the community if you're not going to follow through? OSS is supposed to be fun, but who the hell wants to fool with a pile of sloppy, undocumented code? Is this really the best you can do? Time constraints and other excuses notwithstanding, I ask again, why bother? I am truly starting to lose faith in the OSS model.
  • that this may truly be a slashdot first like he said... its releveant, funny, Ontopic, not flamebait or a troll, yet incorporates Both Natalie Portman and Grits...

    will the wonders never cease?

    Now if someone could work in "JonKatz suckZzz" in a relevant manner, we will be complete :-)
  • I honestly thought I had.....

    I blame it on the box being so close to the submit button - I've hot the button a few times when I meant to hit the box first.

    I'm also worried about all this submitting we have to do.

    Not sure I want to submit :)


  • I've contributed to the documentation and a patch to the code. Although I tend to agree with the A.C. on the fact that there currently are little problems in the contribution scheme, I wanted to add that the sourceforge staff has been *very* responsive, at all time. This does not show in the mailing lists/formus because it was adressed directly to the contributors. Regarding the current documentation inconsistency, for instance, they deeply apologize to us for the mistake. The situation will be back to normal in a few days. Considering the huge amount of work they are doing, we contributors can be very happy that they constantly try to improve their methodology. They are definitely going in the right direction.
  • Yeah. OK. Point taken.

    I was trying to point out a value for money thing and got a bit carried away. I believe that very few people would ever need stuff that Photoshop can do that the Gimp can't. Besides, any missing functionality could be coded in gimp_perl coundn't it?

  • Hmm. It sounds like the SourceForge folks could use a system that helps them maintain a CVS server, distribute code, test compiles, manage mailing lists and support forums. Gosh, that would be a great Open Source project! Someone should start one--they could call it SourceForge. Then the SourceForge folks could use SourceForge to help then manage all those tasks they apparently have trouble managing. They could put the SourceForge code up on SourceForge. They could use SourceForge to manage mailing lists and support discussions...

    What's wrong w this picture?
  • by Robert Link ( 42853 ) on Tuesday May 09, 2000 @07:18AM (#1083455) Homepage
    I've been thinking about this since the RMS interview. As I understand it, copyrights allow the owner to restrict "public performance" of the copyrighted material. Wouldn't application service fall under the umbrella of "public performance"? And if so, wouldn't this provide a mechanism for upholding the spirit of the GPL in the face of asps?

    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?


  • >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 [toronto.edu].

    Please make sure that you have full knowledge of the effort involved in a task before belittling someone else's efforts with it.
  • A lot of people are calling this guy a whiner. In his defense, let's point out that VA is supposed to be good at this sort of thing -- they're a group of Linux professionals who are trading on the fact that they "get" open source. If a closed-source company (say, a graphics or sound card manufacturer) behaved this way with their drivers, wouldn't you get fairly pissed off?

    That said, there's another assumption here that doesn't make so much sense -- that VA has total control over the development process. If the software is truly Free, this isn't the case; someone just has to grab the code, put it on CVS and start development independently. Furthermore, the threat of having their sails deflated like this might make VA more responsive to spearheading development.

    That's why we have and need the right to fork -- to revive stalled development, and to give people a prestige (dis)incentive to keep development going in the first place.


  • 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.
  • by The Queen ( 56621 ) on Tuesday May 09, 2000 @05:01AM (#1083459) Homepage
    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
  • by test007 ( 162343 ) on Tuesday May 09, 2000 @05:03AM (#1083460) Homepage
    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.
  • Hi Chris, I appreciate the suggestion for me to hack an insecure version of SF but that would be the easy part. Providing the server hardware and bandwidth is the hard part. I've got three kids and a wife to support so my personal resources are a little thin (at least for now). Willing to provide the server and bandwidth? We'll call in SourceSmelter to reflect the cruder development process. Then add a SourceAnneal where projects can be tested.

    When SF started I assumed it was simiar to LinuxBox, my previous host. I just assumed that besides hosting they would provide additional services. But, as I mentioned I found SF all but unusable in collaborative efforts. Not to mention the amount of time and hassle using secure tools was adding to the workload. As far as getting hacked is concerned, this is more an exception than the rule. Damaging hacks are few and far between. Long ago i learned not to put anything up on the web that I didn't have a copy of elsewhere. At any rate, I've stuck with LinuxBox, though they have combined with LinuxAve(in no small part due to the MassLinux fiasco I'm sure) they give me a place to hang my hat with a minimum of hastle.

    By the way, whatever happened to installfest.com? When I type the URL all I get is Thunder.net Communications logo. I've looked at the feasibility of providing installfest kits (ditro cds and basic setup instructions.) and I figured they could be produced for $2.50-$3.00 apiece. I'd be willing to spend the time (along with my wife) putting the kits together if we were sure to get the level of participation to make the effort worthwhile. Any ideas?

  • I'm not adverse to a secure CVS archive. Its the development environment that I find cumbersome. BTW there are faster ways of getting a response from the maintainers, but circumventing the system probably isn't a really cool thing to do.
  • >
    >For every Apache or Linux there's hundreds of lower quality, less-developed programs out there.

    It's not necessarily a lower quality, it may just be a lower following.

    A programmer may find himself needing a program that does action A (pour breakfast foods down a certain actresses pants) to news story B (RedHat Buys Microsoft for $12) and posts a troll on dotslash.net [dotslash.net] He spends many months developing this software (open-sourcely) until it gets to the point where it does everything the programmer(s) needs.

    Unfortunately for him during the months he spent on this software everyone quit reading dotslash.net, and now has news stories beamed directly into their fortune mod programs (long live fortune).

    With the opprotunity to troll lost, the project fails (along with the developer's marriage). However it did not fail beause of poor quality programming or a lack of effort into the programming cycle. It simply failed because life sucks.

    And that may be the hardest 2 pennies you ever earned.
    Devil Ducky

    Devil Ducky
  • Settings like this that make sites break are a support problem. Furthermore, it's going to become less effective as webhosts are moving to having a DNS entry in their domain point to someone else's ad server. I think ads.nytimes.com was serving up ads for a while but it was resolving to a doubleclick.net IP address. In short, it's not an effective solution and it breaks lots of sites. It *should* be hidden.

    Anomalous: inconsistent with or deviating from what is usual, normal, or expected
  • I don't really have a problem with not including the cronjobs, I just wish you guys had a list of what was IN the tarball :P Oh well, not a big deal.
  • by EnderWiggnz ( 39214 ) on Tuesday May 09, 2000 @04:26AM (#1083466)
    is that people are complaining, and not fixing...

    try this logic


    Note that the function ComplainProfusely() is not in there...

    if theres a problem, shut up and fix the damn thing...
  • We have accepted patches from contributors. We don't accept every patch however. But then again neither does Linus.
  • SF.net provides excelent hosting services for anyone who needs them.

    They are responsive, and very willing to accomadate most projects.

    I've had a project running for ~3 months now which could not have been started without sf.net

    Thanks SF.net guys...
  • by bigdisk ( 183176 ) on Tuesday May 09, 2000 @07:30AM (#1083469) Homepage
    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?
  • you got java in my c++!!!

    you got c++ in my java!!!
  • While I'm in favor of open source for the peer review, the tone of this rant really makes me want to reconsider that... please note, this isn't a troll - this is just my honest gut reactions to the guy.

    If I start a project, and I want to do it myself, why the hell can't I? It's MY project. Sure, I can let you use it, but who says I have to let you contribute?

    From the way this guy talks, it's as if he demands every single program be open to whoever wants to toss in code to do so (and yes, I saw the mention of the read-only CVS tree). Why should I? Opinions and input are one thing, but that should be the developers choice if they're used, or just routed to the big bit bucket.

    It's a great big Internet - there should be room for all types of software development, ranging from fully open collaborative, to ultraprivate encrypted end to end on standalone networks.

    To me, open source means that eventually, it'll be open. Not that you get to watch and snigger over every small little glitch the guy makes, sniping at him along the way until he loses interest. If his choice is periodic releases, then you should be polite enough to accept that.

  • by Uruk ( 4907 ) on Tuesday May 09, 2000 @04:28AM (#1083472)
    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.

  • How is he going to fork the hardware and bandwidth?

    I thought that this was about open source/free software, not open hardware or free bandwidth. There are costs involved in forking a project - in this case the costs may include setting up a competing service. OTOH, depending upon how the fork is done, the forked source might even be hosted on Source Forge itself, and a forked documentation project could certainly live there.
  • by atopian ( 106699 ) on Tuesday May 09, 2000 @04:29AM (#1083474) Homepage
    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.
  • I only moved my project to Sourceforge recently (less than 2 months ago.) This is the first open source project I've worked on. So far I've been using Option 1, but only because it's so early in development. It also uses PHP scripts, contains no documentation, and is completely free (GPL.)

    So I release stuff that's imperfect but contains important parts of the framework as development (odd number) releases. When I finally have something that I feel is stable I'll make a stable (even number) release. Then back to dev releases again. So far I've received a couple e-mails from people that are setting up or planning on setting up the software, but I haven't had to deal with patches yet since I've done all the coding so far myself. I don't understand why they don't update their CVS repository more often. I update mine almost daily. Is it possibly because they're too busy to incorporate patches on a regular basis? I could see that happening. I do hope they find some time for the people that want to submit patches. I know it might seem like the AC was being an ingrate, but OTOH it's in SF's best interests to give these guys what they want--provided it doesn't take away from the things that they need to work on right now.

    Keep in mind, I'm not criticizing Sourceforge for doing it differently. I host my project on Sourceforge, but I'm not involved in the development of their site. Sourceforge gives me a great place to host the project, complete with shell account, web space, ftp server, bug tracking, project and task management, forums, mailing lists, cvs, and a load of other stuff that's enabled me to accomplish a lot more than I would have been able to otherwise. It's free. Sourceforge has my full appreciation.

  • The anonymous coward is right that open source projects should release early and often. Unfortunately, as CmdrTaco said, that isn't always so easy.

    Now I don't know what's going on over at SourceForge with regard to the code and documentation getting out of sync with themselves, but if that stuff is true, then it's pretty bad moves on the part of SourceForge, and it's certainly no way to run an "open source" project!

    And this post adds no additional insight whatsoever. It's eseentially a "me too." Whatever.

  • Well, as that declaring the JonKatz variable initiates the flamewar() function, it could be a good test for seriousness. If the programmer takes things too seriously, then the use of JonKatz would start the flamewar. If the programmer couldn't give two wet flips, then the flamewar never happens and the original program gets finished without the need to call Trolls. All you'd have to do is a boolian test on the JonKatz SucKzzz variable and you're there :-)

  • I see a lot of excuses being raised. It's difficult to do this, and so forth. This is completely understandable, I'm the lone developer on my own open source project.

    But part of the reason I'm the lone developer is solely because I haven't taken the time to make it easy for others to join. I don't have the documentation available on how to work with the CVS structure, how to recompile, etc. etc. etc.
    Therefore it's my own fault that I'm alone.

    This is the issue that is brought up by the Anonymous Coward in his article, that people seem to be missing.

    He's not asking for anything special, all he is asking is that SourceForge provide a model example for Open Source development.

    I think that is an appropriate position for VA Linux to be in. If they can't get OSS to work well, then how can they advocate to the masses that it's a good idea?
  • by FascDot Killed My Pr ( 24021 ) on Tuesday May 09, 2000 @04:31AM (#1083479)
    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?
  • > split the tree into a developmental release.

    It also has a price, in administration, in confusion, and in synchronizing changes to the two branches. It is probably worth the extra work for a project like Linux, but for projects with a small user base I don't believe the benefits outweight the costs.

  • by Matts ( 1628 ) on Tuesday May 09, 2000 @05:05AM (#1083481) Homepage
    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!)
  • by JamesKPolk ( 13313 ) on Tuesday May 09, 2000 @05:07AM (#1083482) Homepage
    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.
  • But someone still has to organise and bring it all together right? Or else where will Programmer C find Programer B's Software?
    Does programer B have to distribute it himself?
    More likely Programer C will find Programer A's web site and work from there, If Programmer A hasn't had the time to add Programer B's source to his own Programer C is only going to see Programer A's code and have to recreate Programer B's 40%Scratch patch in addition to his own 10%Scratch code.

    Right? Or have I missed something important?
  • 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.

    I help run a free web site (rather large for what it is, does about 22 gigs worth of transfer in text and html files a month) and I would have to say yes.

    The complaints far outweigh the praise. And people can get nasty over the littlest things. I remember one recent one, which holds the record for being the longest and most un-understandable complaint - it took me almost two days to figure out what the user was cussing about! She/he didn't like the way we named our mirror sites because it was stupid. But it took her about ten paragraphs of foul language to get to that point.

    Most recent is complaints from Internet Exploder users because there are a couple of Windows programs out there that are starting to hijack the extension cgi. Since Exploder uses the extension rather than the content-type to decide how to display a file, they can't use the sections of the web site that run though the cgi scripts. There's not a damn thing we can do about that - we have to send them rooting around in their extensions list to kill whichever program has taken over the cgi extension. But it's our fault - the MS browser couldn't possiblty be broken, right??? *rolls eyes*

    People come to a point where they gain the attitude that they deserve the free site. I don't know why - but it happens.

  • It's not quite this easy. It is a very time consuming procedure. Before each patch can be put into the source tree it has to be:

    1. Tested alot
    2. Read over for anything irregular (ie if $username=="sstrick" then karma=999)
    3. Merged with any other changes to the same piece of source (CVS helps but there is often an element of human involvement).
    4. Tested some more.

    This can often take almost as much time as writing a small code change yourself.
  • Now it's not good enough to simply release your source code. You have to fully document it, package it properly, and host a CVS server.


    That kind of attitude is not only bad for the "open source" [bowel] movement; it's bad for society as a whole.

  • After a conversation with some of the sourceforge guys, I think I need to ammend by statement.

    The guys at sourceforge are doing a *GREAT* job. The project as it stands is great. They're limitation to things such as public CVS access and a good build/install and/or packaging system is simply becouse they are a small group of people providing a wonderful service.

    I would list sourceforge as one of the best open source 'projects' out there. I simply wouldn't list their source as one of the best. This isn;t do to their efforts, or anything they can do anything about.. What they need is *people*. Volunteers wanted at http://sourceforge.net/patch/?group_id=1
  • by Anonymous Coward
    From the comments on bugzilla, they apparently removed the menu item as well, although by changing imageblocker.enabled to true instead of false in one of the .js files you can turn it back on. Makes perfect sense to me. The geeks and power users can still turn it on as they please, while the sheeple will be none the wiser.

    Netscapt 4.x had a number of things you could do by editing the preferences that were largely undocumented or had no menu controls, such as blocking the more useless buttons (shop? c'mon guys) and adding some of your own, to changing the throbber (the flashing letter "N" in the right corner) to one of your own design (I had an exploding smiley face. Lovely it was.)

    What bothers me about this one is that a lot of people feel it's something that *SHOULD* be right up front, easily accessable to anyone who wants to do something like this (most people). Now, how open is the mozilla source? I mean it's out there, but if they decide to yank the feature entirely can someone run and fork with their own web browser?

  • Sure PHPBuilder is great but personally I've found Sourceforge all but useless(at least for development). SSL limits what browser I can use so I had to backdoor upgrade my IE to 5.0 so that I could even log in at woork (my company uses 4.0 because 5.0 causes problems). SSH is a pain in the butt for doing updates. When you spend more time trying to update then development close to nothing gets done. Not to mention how discouraging it is to the bulk of part-time developers. Security is a fine thing but this is overkill. I've moved my project over to another server that provides free hosting for now. sure I'm sacrificing a little stability and security but at least I can get somthing done.
  • I write a little digital audio mixing program (see link below), and I chose Option 2. I have yet to be flamed for anything, and have actually recieved a patch from one person (thanks owen), and suggested patches from another...

    For me it's a matter of pride in my work. In order for other people to use my project, which I've sweated and bled for (cut myself installing a soundcard...), I feel that it should be:
    1) stable as I can make it
    2) clean, so others can understand it
    3) have a certain feature set and core API. Currently I am the only one who knows what features are needed. Could others help out? sure. but the code base is so new, that to have even 3 people poking around in it could mess it up for the other developers. But until the code reaches a point where I feel it is ready for others to add to, I'm going to keep all development on my home system. Also, the other developers may not understand the final goal, and may start adding features that are unneeded and hinder the achivement of the ultimate goal.
    4) Have the proper clean and organized directory structure and file setup. Otherwise, the entire tree could easilly become convoluted and hinder development.
    5) all the docs are ready. this includes architecture specs so that future developers will not need to reverse engineer anything.

    The other thing is that this may be Open Source, but it is "my baby". It's my name on the copyright. Using the GPL means that the code is free, but it is still owned by me and I can do whatever I want with it. I am under no moral obligation or compunction to release code. I release the code because I want to. I am feel that I am performing a service to the community, and quite frankly getting an email from some kid in germany thanking me for my work makes it all worth while. And I want my baby as perfect as it can be before someone else tries to use it.

    "You want to kiss the sky? Better learn how to kneel." - U2
  • by RPoet ( 20693 ) on Tuesday May 09, 2000 @05:11AM (#1083495) Journal
    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!

  • I can't help but notice the article(s) above have been marked as flamebait......

    But they look rather like discussion points to me, at worst they are simple statements of a personal viewpoint but not flamebait.

    "All free software sucks" would be flamebait, as would "I hate macs because I hate them" or "John Katz writes like a crazed koala"

    (the stuff above is presented purely as a series of examples - please don't take seriously!)

    People should learn to moderate sensibly and not knee-jerkingly in an "ooh, I've got 5 points to spend, let's screw a thread up" kind of way. I guess this piece I've written will be modded to hell now as I've probably annoyed someone but it's just meant as my take on things :)

    And as for my take on the sound forge thing - if it annoys you, just ignore it - there are better things to do in life than whinge about open source projects -if it really annoys you, go out and code something yourself or better yet try maintaining your own distribution - it's bloody complicated and takes a lot of time to do.


  • Whether or not Sound Forge is Open Source, it's a damn fine program. You can't expect teams that have been devloping successful proprietary software to jump on the band wagon all at once. Rather, they should be congratulated for their first step, however small.
  • 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.

    Yes this is easy, in theory. The problem is, if you are in charge of a program, like the people at Source Forge have done, then others expect you to keep the code up. When somebody else submits changes, it is still up to you to 'roll it and release it.'

    Let's look at your example...
    Programmer A wrote a program that does 1, 2, and 3.
    Programmer B added 4 and 5.
    Programmer C rewrote 3 and 4 and added 6.
    While Programmer C was making changes, Programmer A was rewriting 3 and 5 to make a new combined one, lets call it 7.
    When Programmer C submits his modifications, it is up to Programmer A to check and make sure everything works right, if not, people don't track down Programmer C to complain, they complain directly to Programmer A.

    When people submit patches, often they are poorly documented about what they modify and what they do. It is up to the person in charge of the program to try and pull all of it together.

    A good example of how to run a program update system is Torvalds et al with the kernel. One person with final say-so over it, but many in the second-ring who are in charge of components or packages. Those people oversee any contributions and make sure they are tested before it goes up the line. That way no one person is completely overwhelmed with upkeeping the system.

    When you have a handful of people working on something, and especially if it is not full-time, and lots of people sending in updates, then that handful gets overwhelmed and is unable to keep up with the changes, or even the udpates.

    For Source Forge, this means that they may need to re-evaluate how they are handling their updates and maybe assign parts of the system to volunteers or be willing to let volunteers or other maintainers have a little more control over the development.

  • try adding this:

    #ifndef __PROGRAMMING_SKILL_H__
    #define GOODSTYLE
    #else //__PROGRAMMING_SKILL_H__
    #undef WHINING
    #endif //__PROGRAMMING_SKILL_H__

    Last I checked FixCode(); was defined in ProgrammingSkill.h but the #undef is VERY important in cases like these. Should compile nicely now :-)

    oh, and tagback, you're it!
  • I think a lot of people don't understand how opensource works. They don't have to release code (unless they are spreading gpl'ed binaries). They also don't have to give any kind of support, this is stateted very clear in the gpl.

    I can release any kind of source under the gpl, even if it is totally useless. I would be nice if I reacted nice to people sending patches, but I don't have to.
    And if you don't agree with my visions you can just fork the program and do a better job yourself


  • Using SSL and SSH means that the site is being run in a secure manner. If you don't think that's true, you are welcome to download the SF code and set your own, insecure version of SF up, becuase SF will not change this aspect of it's administration.

    You want a hassle? How about having machines crashing due to people cracking them. That's a hassle. I know that SSH isn't always the best of utilities, but it's the best we have right now.

    You are better off learning to use ssh and scp than continuing to use insecure, cleartext, tools. If you don't agree with me now, that's fine, you will after you get hacked a few times.

    Chris DiBona
    VA Linux Systems
    Grant Chair, Linux Int.
    Pres, SVLUG

  • by jimhill ( 7277 ) on Tuesday May 09, 2000 @08:26AM (#1083505) Homepage
    Did you or Ender _read_ the post or just Malda's self-pitying addendum? The guy is not grumbling about bugs -- he's grumbling about the fact that patches are not accepted or even acknowledged, the fact that the markedly inferior documentation is touted over the superior product done by volunteers, and that the maintainers essentially flushed everything without warning at one point.

    This isn't a "shut up and code" issue -- the volunteers have BEEN coding; their efforts are going for nought because the maintainers seem to have no interest in working via the free software model.

    Personally, I'd suggest that the original submitter do one of two things:

    1) Work on some other project, or preferably

    2) If others feel the way you do about SourceForge, take the code you had when VA ripped the rug out from under you, fork from there, and use the free software model to smoke their product.
  • SourceForge is still an open-source project, it's just operated in a different way. The closed-development, selective patching nature of the project reminds me a LOT of the BSD and Apache style development model.

    So perhaps VA would do well to change the license on SourceForge from GPL to BSD-style. (I'm assuming that SourceForge's code IS under the GPL).

  • I think what the author of this article fails to notice is that it still is their project. Being as the nice people at sourceforge have written the software they should have control.

    I see a couple of other flaws with the arguments. First of all, it's not always the case that patches are accepted. Look at all the projects [sgi.com] SGI has done for the kernel and note how some of them were outright rejected. Yet we magically don't accuse the Kernel of being open source.

    about the release cycle thing, I don't see a problem if they take a long time. It takes a large amount of time to do stuff like write documentation, create tar balls and the like. If it's just programmers, most of them would rather program. And access to the CVS for the PHP source, it's been my experience that CVS doesn't serve PHP that well, your mileage may vary.

    so while it would be nice to have the SF source code all nice and up to date. If they choose only periodic releases so be it. It's their project. If you think this is a problem, go Xemacs on their ass and fork the code.

  • by alessio ( 39749 ) on Tuesday May 09, 2000 @05:25AM (#1083515) Homepage Journal

    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 [gnucash.org] 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.

  • People aren't going to go around releasing sourceforge's left and right on every geocities webpage they own. The only thing I can see sourceforge source being useful for is the educational aspect of seeing "how it was done" in order to model a process in your own work. To me, setting up perl2html, php2html (if it exists), and executing:

    ln -s /usr/lib/cgi-bin /var/www/source

    Counts as making a cgi-based website open source. It's all that would be necessary for someone to see how the process was done, and if for some reason somebody wanted to copy the site, they could with very little trouble. Why should the maintainers of a site with potentially very important contributions to the open source world waste their time providing tarballs with a good installation to people who wouldn't know how to install apache themselves anyway?
  • by Thomas Charron ( 1485 ) <twaffle@@@gmail...com> on Tuesday May 09, 2000 @06:02AM (#1083521) Homepage
    Ordinarily I'd agree.. But in this particular case, given the nature of the system, and the amount of evangilizing done by sourceforge, I'd say people have the right to complain. Yes, it is an open source project, no doubt there. But is it in the true nature of open source to keep development closed, and release every once and a while? My answer.. No. Practice what you preach, plain and simple.

  • True, but developing a "web site" in an open source fashion is a little bit tricker. If you start building a web site from the ground up with flexiable in mind, it can work out well. But if you have a current web site that is "hand fitted" to the companies goals (news for nerds, open source develop) and try to release this, it can and is most offen a huge mess.

    Look at it this way, slashcode is a lot like sourceforge, they are an open source project, but they are also a LIVE web site. Being that this code has to be used NOW AND FOR THIS, it is hard to push in new feartures.

    It is difficult to put in new feartures in a live web site, because

    1) the site can't go down because of a programming error.

    2) The site has to do what it was meant for.

    3) the site has to be tested first

    4) sometimes the interface it "attached" to the code, and it is extremely difficult to pull apart

    5) ussually, speed is more of a concern (with a large site like /. or sourceforge) then portablity/flexablilty

    I think it would be a better idea to have 2 version in this case. Have the slashcode or source forge that ran the site (put under the GPL of course) and also have a developers version that focuses on a more portable design (under the GPL also), which developers where encouraged to work on the developers version, and "pull" all of the goodies out of the version that ran on the live sites.

    This way the open source developers could work on their version for their own purposes, and the paid employees at VA Linux or slashdot could work on their version for the live site. Have both version avaiable under the GPL, and if an open source developer wants to "pick" out of all good stuff from the live site, then so be it. and if the paid employees want to "pick" out the good stuff from the developers version, so be it.

    This way, the site will still run and the developers could add feartures/test without having to worry if Rob needs fewer SQL transactions or not... and Rob could worry about cutting down on SQL transactions while the developers "split" the interface into a more portable way...

    One thing I thought would be cool is to make slashdot into a bunch of modules (not my idea, seen it posted on slashcode.org first), which is cool from a "fun thing to do if I get bored looking at portman pics" sort of thing. But Rob on the other hand, needs the site to server 1 million or so geeks a day, and it would be in more of his intrest to make the site super fast and not bother with "fixing something that isn't broken" type of thing. So from the "Senior Developers" point of view, it would be better to tweak out the site, rather than waste time making a nice neat little package, I think VA Linux might be the same way in some respects.

    Forking is ussually a bad thing, but this would have it's benifits, the people that wanted to package every thing up and make a nice, neat, easy to configure, multi-platform version with portablilty in mind could do this. The other version would be of the people employeed full time on it, developing it to fit the task at hand (ie. there web site)

    there would have to be a good communication between the two groups, and they both should try and stick with some of the same concepts so that each other group can share code, and if group a has a really neat hack, group b can implenet it into their version of the code.

    Having 20 thousand people working on one live web site, could get REALLY MESSY REALLY QUICK. So there has to be some type of separtion between the people devloping the "live" site, and the people devloping the "portable multi-funcational" site. Both will come up with good ideas that the other group can use, both will come up with bad ideas that the other group SHOULDN'T use.

    I would like to put a "percentage of hot grits currently in pants" meter on slashdot, but it won't work with the live site, it would be better to fork off and build my own "grits meter slash box" out of the slashcode...

    My vote (if I get a vote) is to fork into two projects, both release under the GPL and code/release/develop as they see fit, while both groups are free to take code from the other project.

    Do you know how many freaking vi clones are out there? why can't there be more than one "source forge" project?


  • it's really too bad that this iterative, "let 10 peolpe sequentially do a halfassed job" method of writing software has become such a pervasive paradigm. if Programmer A wrote a clean, simple, extensible framework which people could add to in order to get their particular itch scratched, Programmers B and C wouldn't have to juryrig a bunch of patches onto some crappy works-fine-for-me kludge.

    but most people are too blind to see anything other than that which everyone else is doing, so I suppose this sentiment will always fall on deaf ears.
  • by Anonymous Coward
    If Sourceforge is adding significant new functionality to their codebase and releasing often, the "clone" ASPs will contribute back source to make their own life easier, unless they truly do a fork and don't look back. The time spend re-integrating Sourceforge X+delta changes into their own version Soureforge X overwhelms the cost of adding their own features back to your codebase.

    In addition, we can learn something from the slashdot experience here -- the power of the brand in a community website is very significant. It's not rocket science to put up a quality /. competitor -- but no one has found a reasonable strategy for stealing a significant amount of /. traffic, because of traditional media issues -- namely, the power of the /. brand, all those links in all those bookmarks and webpages.

  • by pberry ( 2549 ) <pberry@nOspAM.mac.com> on Tuesday May 09, 2000 @05:30AM (#1083532) Homepage

    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.

  • ...you end up spending hours, weeks, months, writing your code, improving it, fixing it, promoting it, and still no patches come in.

    As long as all these improvements and fixes are to scratch YOUR itches, how is this different from what I said? As for "promoting it", what does that mean in the context of a non-business?

    As for critical mass: I don't think it's a size issue, at least not entirely. I wrote a less-than-300 line program and put it on freshmeat on Sunday. On Monday I had a patch in my inbox.
    Have Exchange users? Want to run Linux? Can't afford OpenMail?
  • by Anonymous Coward on Tuesday May 09, 2000 @05:33AM (#1083537)
    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 [advogato.org] 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.
  • Just for reference.
    A CVS server for slashcode does exist. You can get instructions of how to connect from http://server51.freshmeat.net/projects/9/ [freshmeat.net]

    Also try the website at www.slashcode.org [slashcode.org] for further info.


  • CVS is of almost paramount importance when launching a Free Software project. It's sort of an ad-hoc-release system for unstable code. Setting up a CVS tree takes a couple of hours for some one who knows how to do it. Set it up for anonymous read only at first. Within a few weeks or months the people who should have write access will make themselves known by their commitment. In this way, a core team of developers will emerge naturally.

    Every time the project builds and runs reasonably, ship it. Major releases can be done when a bunch of new features build and run. When the project gets larger it can have branch releases like the AC kernel patches. These are not forks since they get merged back in to the main line fairly quickly.

    Setting up a project for frequent releases should be done early. The longer you wait between releases the more difficult it becomes to get it out. Frequent releases of minor changes impart an evolutionary nature to the project, a definite win. Waiting a year between releases makes for a ton of work getting the configuration and build setup alone to work.

    In short, you can't be afraid to hang out your underwear. The advantage is that the holes in your drawers may magically get fixed before you have to wear them next.
  • by Psiren ( 6145 ) on Tuesday May 09, 2000 @05:33AM (#1083542)
    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.
  • Rule One of Open Source: If you have an itch, SCRATCH! You can't talk an itch to death, and they don't get bored and walk away.

    Secondly, as CmdrTaco points out, Open Source projects aren't easy to maintain and co-ordinate. You might as well try and have a hedge maze made of triffids.

    Have your itch - that's no bad thing - but scratch it, too, or it's not doing you any good!

  • by q ( 4977 ) on Tuesday May 09, 2000 @06:21AM (#1083546)
    As the person who 'didn't care to reply' - let me note one thing. I have been in personal email contact with both Loic and Sebastien (the two posters) regarding SFDocs. (Days ago ;) ) Yes. The system changed - and I admit, I should've committed the changes to CVS. Time constraints stopped this from happening.

    But, if people cared to check on http://sfdocs.sourceforge.net/ [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. =)


    Quentin Cregan (aphzen)
    Support / Systems - SourceForge.Net

  • by laborit ( 90558 ) on Tuesday May 09, 2000 @04:34AM (#1083548) Homepage
    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
  • There's one really important suggestion that shouldn't be too hard to implement...

    Would it be possible to have a CVS tree made available for slashcode? even if it's read-only, you might get some suggestions from the relatively intelligent coders we get here.

    I think if this was done properly, some of the packaging efforts could be put a lower priority.

    But I also have to say that complaining about a lack of decent packaging for home-brew code is kind of looking in the gift horse in the mouth. We're lucky to get a tar ball from people, i'm sure there are some packaging wizards out there who could fix it up with a decent autoconf script or in rpm or apt package format. Getting the majority of the code debugged, that's much more important.

    Gonzo Granzeau

  • The volunteers protested but the sourceforge staff didn't care to reply

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

  • Nobody ripped you off bowie, that's what you keep on forgetting. VA was hosting projects long before you were on the scene. SF was, again, just an extension of that. And we didn't rip System12 off, we're buying Andover.

    So you see, we did address your claims , and I'll do it again here: They were groundless.

    Chris DiBona

    VA Linux Systems
    Grant Chair, Linux Int.
    Pres, SVLUG

  • by markst ( 169846 ) on Tuesday May 09, 2000 @05:38AM (#1083561) Homepage
    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

  • To be fair, the majority of closed source projects fail too. The RISKs digest is full of systems costing millions of dollars which have had to be shelved because they just don't meet the requirements.

    Developing software is complex, and we don't always have the best people doing the jobs which are required in a project.

    Perhaps we should be amazed that any software works at all.

  • by Matts ( 1628 ) on Tuesday May 09, 2000 @05:50AM (#1083564) Homepage
    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.
  • by Anonymous Coward
    You are not entitled to a CVS repository.
    You are not entitled to a nice makefile.
    You are not entitled to a mailing list.
    You are not entitled to discussion board or a Usenet group.
    You are not entitled to documentation.

    All you get is the unobfuscated source code. It may be poorly-commented. It may be sloppy. It may be useless to anyone other than the original coder (and even he may not understand it anymore). No one is obligated to hold your hand and make it easy. If you want something badly enough, you'll make do or start from scratch.

    Not everyone has time and resources to coddle all the wannabe open-source heroes. Take the code, say, "Thank you," and get on with it.
  • 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?

    Yeah, I saw it. Following the link to the bugzilla entry yields an interesting discussion.

    The code is still in Mozilla but is turned off by a default preference. You can turn it back on and all the old functionality comes back.

    Anomalous: inconsistent with or deviating from what is usual, normal, or expected
  • Read up on the Bugzilla link. They say that feature was not removed, just set to be disabled by default. You can still enable it with the javascript setting they provide.

    This appears to be more of the complain-publicly-that-corp-is-evil-before-investi gating attitude that we see more and more often.
  • are out now. First it was free software advocates, not open source advocates. Now it is open source, but not convienent enough. When will it end?

    Just because the source is available does not mean they need to make you happy. If it is open source take the code, and make your own version, and stop telling others how to release their code.
  • by schporto ( 20516 ) on Tuesday May 09, 2000 @04:43AM (#1083572) Homepage

    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.

  • 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 website for example ;)

    And that was perfectly ok in your case, CmdrTaco. After all, you had to run the damn site during all that time, producing at least some original content, but most of all skimming trough heaps of submissions and selecting which to post. The slash code release has been handled very well.

    Now I may be wrong, but the main job of the sourceforge guy is to maintain and develop the software, right? Since they have decided to do so in an opensource fashion, they have to take responsibility and either keep up with the updates, or be honest about their being overworked.

    Ok, I'm not in any way personnally involved in all of this, but this guys complaints seem valid and should be adressed. They appear to be mainly a problem of lack of communication and information. This can be fixed! (and I bet it will, now that it's up here on flamedot :)
  • by gus2000 ( 177737 ) on Tuesday May 09, 2000 @04:45AM (#1083574)
    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.
  • by turb ( 5673 ) on Tuesday May 09, 2000 @04:45AM (#1083575) Homepage

    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

  • by Per Abrahamsen ( 1397 ) on Tuesday May 09, 2000 @04:47AM (#1083577) Homepage
    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.
  • by StenD ( 34260 ) on Tuesday May 09, 2000 @04:48AM (#1083579)
    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.
  • contributions are useful and then useful ones need to be checked out to make sure they're not going to break some other part of the code. If I were to start and OS project I would only accept code changes as patches because the new code may or may not fit my (or the group's) model or may just be an option. Bug fixes are another matter, but then again you could always just point out the bug and provide a fix. I would readily accept valid bug fixes. Oi, open source madness.
  • Mark,

    If this is indeed the official line, why not post this on Sourceforge? I have two small projects on Sourceforge right now. I have been agitating to get WorldForge [worldforge.org] onto SourceForge as well. But it's not likely to happen because of a) An unacceptably vague clause about "objectionable content" in the TOS, and now b) The perception that SF is not on the level with its contributors.

    Issuing a public rationale for the closed development model would go a long way toward assuaging these concerns.
  • From what tony was telling me, the cronjobs are specific to your system (about 14 machines, or more now), so I don't feel that bad about this, he'll probably chime in.

    As to you taking twice as much time, imagine how much time you would have spent with no source code. Imagine how "annoying" that will be. Sheeze.

    Chris DiBona
    VA Linux Systems

    Grant Chair, Linux Int.
    Pres, SVLUG

  • Because one of the main strengths of OSS is to continually evaluate ways of doing things. The "under so many eyes, all bugs are shallow" argument should not just apply to source code.
    The trick of OSS is to sift through the chaff to find the wheat. This is what is happening now as OSS matures. It is part of the development lifecycle, not that of source code, but of the process and delivery mechanisms that the code resides in.
    Yes, many have argued that "hey, you're getting it for free, don't bitch if you have to spend a long time sifting through a tarball to get a compilable version", and they have a point. But until it is easy for people to get what they need from an OSS project, it won't catch on into mainstream; that OSS project will remain solely in the hands of hobbyists. Apache is an excellent example of an OSS project that delivers totally professional software.
    Purists may argue that OSS is only for the dedicated hobbyist, but I disagree with that. Yes, at home I do like to twiddle with an experimental kernel, I do like to jigger with arcane bits and bobs that may teach me something new. But in the workplace, people want things much quicker and reliable than a slapdash release delivers. The more eyes we have on software, even inexperienced eyes, the better. And alienating people that are not 31337 hax0r d00d2 who can decipher a 25Mb tarball in a few minutes is not the way to get those eyes.
    Do we want OSS only in our bedrooms, or in our boardrooms as well? Because I know which I'd prefer...

    Strong data typing is for those with weak minds.

  • So there you go.

    Grant Chair, Linux Int.
    Pres, SVLUG

  • There are actually 3 options for B to understand A's code. Option #3 is: the code is so simple that anyone can understand it. This is actually very common in the real world for itches that start out small.

    In my experience, this doesn't happen much. Even the toy utilities that I've written (such as the document-formatter I used to produce the LML33 guide) are complex enough to be non-trivial. For a more realistic example, look at the LML33 driver itself. It's relatively cleanly written, but something like my guide helps a *lot*.

    Similarly, documentation and clean packaging are pretty essential to avoid scenario #1 for almost all projects.

    On a totally unrelated sidenote: I'm very interested in the LML33 for a home project I'd like to do, but I'm having trouble figuring some things out (pre-purchase). I was actually at your page last night and downloaded your paper. Would it be OK if I emailed you and asked some questions?

    Certainly, though my knowledge grows increasingly out of date. I'd also suggest researching the Video4Linux driver for Zoran cards. Parts of the LML33 driver still need considerable work.
  • by chrisd ( 1457 ) <chrisd@dibona.com> on Tuesday May 09, 2000 @06:45AM (#1083590) Homepage

    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 [mailto] (or chris@dibona.com [mailto]).

    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

  • I think its disgusting that Slashdot are advocating releasing forged source for an Open Source Software project. If we go down the road of counterfit code it will be the end of the OSS movement.


  • That's just it... there are many ways of doing an "open" project. You can release early and often, or you can wait until you feel the public is "ready" for your code and then release it.
    However I am biased: Personally, I tend to put more stock in the first method. I mean, how do you know when your code is "ready"? When it doesn't crash anyone's system? When it doesn't have any visible bugs? Isnt the strength of open software the fact that more eyes make fixing bugs easier and quicker?

    There doesn't seem to me to be any point to waiting until the code is "ready". You'll find as you wait longer and longer, "ready" keeps getting farther and farther away!
  • Moderate this up! The guy's got a good point. If you're not part of the solution, you're part of the problem. There's a big difference between sending a complete, detailed bug report and simply bitching about a lack of features or abundence of bugs. Virtually any user is capable of saying, "I was doing this, typing in this data, and clicked here; then, I got the following error message....." Slackers need to stop whining and start contributing _something_; even if it's only bug reports, or mirroring the download site, or reviewing documention. Projects are multi-level endevours that require work in many different areas so nearly everyone can contribute something.

The absent ones are always at fault.