Slashdot Mirror
SourceForge Fails To Forge Source?
An anonymous reader writes: "I've observed the development of the SourceForge software and documentation during the past four months and I'm amazed to see that it's developped in a closed fashion, opposite to all of the open source ecology standards.
About the only thing related to open source is the publication of a tarball containing the php scripts used to run sourceforge. It has been published in a as-is fashion, no packaging effort was made. The only documentation included was apparently provided by volunteers and is outdated since it refers to the previous version. This documentation only covers a small part of the software.
There is no CVS tree for the project, not even read-only. Given the fact that three months elapsed between the last releases, there is no way contributors can do a proper job. At the same time VA Linux evangelists attend conferences repeating the golden rule of open source colaborative development: release often.
The only way for contributors to participate to the SourceForge development effort is to submit patches using the patch manager. The SourceForge guys will then decide if it should be integrated or not. Well, this could work if they were careful. But the situation is pathetic : patches sit in the queue during weeks and some of them even don't have a followup. It does not matter much anyway since there has been only nine patches since the beginning.
The SourceForge site documentation shows another remarkable mistake. It is maintained by volunteers. It's far more accurate and complete than the default site documentation but is not easily accessed. When clicking on the Site Documentation link it first shows the outdated documentation and a link to the volunteers work is only included at the bottom of the page. This is a minor issue. Much more annoying is what apparently occurred last week. All the volunteer work was trashed and replaced by a new system without notice. The volunteers protested but the SourceForge staff didn't care to reply ( the thread). The guy who did the mistake didn't even care to commit his changes to the CVS tree of the documentation project. The CVS tree does not match the content of the documentation anymore.
Behaving this way, the SourceForge staff does a big mistake. First it frustrates potential contributors, second it does not allow them to scale well. It's pretty obvious that they are completly overloaded with work and that they really need help.
What kind of conclusion can we draw ? The worst would be that the SourceForge staff is a bunch of talented programmers who do not believe in open source, even though they provide tools to help its development. The best would be that they need the open source community to kick their ass to go back in the path :-)
I sincerly hope that SlashDot will publish this bit. But VA Linux now owns Slashdot and may be immune to this kind of news ... "
CT:Technically VA Linux doesn't own Slashdot. Andover.Net does: the deal hasn't closed yet. And nobody is immune to 'nuthin, however I have slightly different opinions: releasing and maintaining a good open source package is hard and time consuming, as I learned firsthand with Slashcode. The vast majority of users don't contribute back (unless you count complaining). Don't get me wrong, I obviously love open-source development, but when the bitchers get to a critical mass, those who can actually add something positive get drowned out, get bored, and do other things.
It wasn't until Andover.Net came along and hired Pudge and Patg that it became feasible to bring Slashcode to a solid 1.0 release. Now, for the ultimate irony: Slashdot itself is a release behind the latest code ... at least for another 48 hours or so. For the year between the 0.3-0.4 tarballs, and the 0.9-1.0 Slashcode tarballs, I committed virtually every sin listed up there. My point is that its hard to maintain open source packages. Especially when the negative comments outweigh the patches fixing the problems, and on top of that, you have another job (like running a Web site for example ;) It's often a case of the best of intentions being bogged down in the most mundane of details.
Of course, since I obviously am simply a mouthpiece for various corporate entities my opinions are irrelevant and discardable, have a nice day ;)
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.
Fuck Ajit Pai
> 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
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
So, why don't you fix this major problem instead of complaining about it?
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.
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
... hi bingo
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
heh
Troc
Troc's dubious podcast and blog: http://www.trocnet.net
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.
IR for ever
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?
Thanks.
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?
--Michael
Presumably there is something wrong with this line of reasoning, or the FSF folks would already have pursued it. So, can anyone explain why this wouldn't work?
-rpl
>My point is that its hard to maintain open source packages.
Which is why YOU shouldn't. Here's how Open Source works:
1) Programmer A has an itch.
2) Programmer A scratches until the itch stops.
3) Programmer B tries to use the same program to scratch his itch, but finds himself only half-scratched. He patches until the itch is fully scratched.
You seem to be overlooking the fundamental problem with releases - programmer B has to *UNDERSTAND* the code that programmer A wrote.
This involves one of two things.
Option #1: Programmer B has to spend weeks digging through leftover cruft that programmer A didn't bother to delete and reverse-engineering code that programmer A didn't bother to document and finding specs that programmer A didn't bother to write or point to.
Option #2: Programmer A has to spend a few person-weeks of effort and clean _up_ the code, _write_ documentation, and attend to all of the other details of packaging the release that allow other programmers to modify it without pain.
This takes a LOT of effort, and if it has to be done in one-hour chunks while you work at your day-job or take courses full-time or what-have-you, it will take a long time to do.
I've done this myself. I wrote a series of extensions to the driver for the Linux Media Labs 33 video capture card and posted packaged results to the web. http://www-ug.eecg.toronto.edu/~thoma sc/lml33.
Please make sure that you have full knowledge of the effort involved in a task before belittling someone else's efforts with it.
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.
phil
Here's a thought...
Maintaining OSS projects is a lot of hard work, and there is no real clear way to go about it. This article is not the first gripe I've heard pointed toward an otherwise "good" company, and we risk scaring off more corporate OSS involvement if we trash the people we already have. So I propose this:
Why don't we put together (as we I mean people who have successfully maintained large OSS projects) some information on how to do this. Some DOs and DON'Ts, some guidelines, and people to ask for help when things go wrong. If we, the community, provides help for how to maintain a project, not just for the project itself, we might see a lot more corporations playing nice.
http://kered.org
But Programmer A's son just got caught scratching his itch with Programmer B's underage daughter in the back of Programmer A's Chevy, and Programmer C is still at home scratching himself. (Ew.)
Just thought we should consider the human element.
Seriously though I think your flow chart for OSS growth is a bit optimistic...it sure would be nice if it did work that way but whenever you get more than one person involved in something there will be conflict.
The Divine Creatrix in a Mortal Shell that stays Crunchy in Milk
The House Between - Original Sci-Fi Series
Do not look a gift horse in the mouth. This old saying is also applicable to open source code. When someone gives you something for free you either try to figure out how it works with the little help they provide or you pay big bucks to someone who will do it for you.
Personnaly I prefer the first choice because it prevents me from becoming a trained monkey who can do something whithout knowing what I am doing. Having someone else do ALL the hard work for you will result in creating uneducated users who know little or nothing about the software they use and the dangers associated with doing so. If that is what you want try commercial software. Albert Einstein once said: "Make things as simple as possible, but no simpler"
Open source software gives users and developers a lot of freedom, but freedom doesn't come easy. You usually have to fight for it or struggle to achieve it.
There are 10 kinds of people. Those who understand binary and those who don't
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 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
Devil Ducky
MY peers would get out of jury duty.
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
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
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.
is that people are complaining, and not fixing...
try this logic
if(ProblemInCode(ProjectName))
FixCode();
else
UseCode();
Note that the function ComplainProfusely() is not in there...
if theres a problem, shut up and fix the damn thing...
... hi bingo
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...
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!!!
Bad things often happen to good people,
It is up to them to see that they remain good.
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.
When a project is 'open source' or 'free software', the author of that project is giving you something because he wants to. It doesn't sound right to bitch about the quality of it.
I don't think it's very cool or nice to not make a CVS server available or any of the other things you seem to hate, but they're not obligated to do that. In fact, if they wanted to convert all of their source code to EBCDIC and distribute it that way, sure, it would suck, but they're still giving you something that you wouldn't have otherwise had.
What's the license? If you're so fed up with their efforts, you could just fork it. I realize that there are a lot of strong pressures not to do so, but at the same time, the right to fork was made for situations where there are large problems like you seem to say there are here.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
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.
Well yes it would be nice for everyone to contribute, but sometimes people dont have the knowledge base to release the patch. So what they can do is point out the problems, just they tend to come across as whining or complaining.
So remember that when you email a bug or problem BE POLITE. Who knows, you could be on the other end of it some day.
Hrm loving these
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.
numb
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.
---
How am I supposed to fit a pithy, relevant quote into 120 characters?
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?
My point is that its hard to maintain open source packages.
Which is why YOU shouldn't. Here's how Open Source works:
1) Programmer A has an itch.
2) Programmer A scratches until the itch stops.
3) Programmer B tries to use the same program to scratch his itch, but finds himself only half-scratched. He patches until the itch is fully scratched.
4) Programmer C tries to use the program and finds himself 90% scratched. He patches until the itch is scratched.
5) Etc
As more people use the software, it magically grows more features to cover all their needs. So in your example (CmdrTaco), you don't need packaging--so don't do it. If someone else needs packaging they'll do it. If no one needs it, it doesn't need to be done.
In any case, do only what you need done. Then release. When people submit changes, roll them in and re-release. It's really very easy.
It's a very very bad mistake to try to run an Open Source project just like a closed source one with the occasional "public code review".
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
> 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.
It seems you have an incredibly naive view, although that view is supported - it's the philosophy of how open source works. But in reality it's a whole different picture... What tends to happen instead is things stop at point 1, unless your code is already at point 4, so you end up spending hours, weeks, months, writing your code, improving it, fixing it, promoting it, and still no patches come in. Eventually you get to point 4 yourself, if you put in the effort.
But that's OK - because you've got a great product that people use. I have a couple myself that I'm very proud of. But patches are extremely rare until you hit a really large critical mass. Take all my open source projects combined (XML::XPath, DBIx::AnyDBD, AxKit, CGI::XMLForm, DBIx::XML_RDB, Time::Object, XML::PYX and Win32::ASP - all Perl based, all (most) used quite a lot). I recieve about 1 or 2 patches a year (in total - not per project). Thats not a whole lot, and not enough to keep a project going without me.
I'm not complaining though - these projects not only scratch my itch, but they were/are fun. I still get the "open sauce kudos" - although it's not as prevalent as ESR makes out in CatB.
The point of this is: Patches do _not_ happen until there is critical mass. And critical mass is a lot bigger than some people believe. (although the argument is probably moot for slashdot and sourceforge - if they're already getting patches they've probably achieved critical mass!)
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Free software is software with no restrictions that prevent you from using the software to its fullest, nor any restrictions preventing you from helping others use it to its fullest.
:-)
Well, jiminy jillikers, Radioactive Man! Sourceforge is relased GPL! You can't get any more "Free software" than the license endorsed by the guy who coined the phrase "Free speech, not free beer"!
So what if they're using a closed development model? "Bazaar" development is not a defining characteristic of free software, after all.
If you think that an open development process would make sourceforge's code even better, for your site, start hacking yourself, put up a webpage describing what you've done, and start a mailing list! (I bet you might even be able to host it on sourceforge!
If, however, you think that the Sourceforge coders are doing a good enough job, lay off!
Also, I'd suggest a read of the Mythical Man-Month. There's no saying that adding more coders to the Sourceforge project would make things faster.
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.
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.
WE WANT IT ALL OUR WAY RIGHT NOW FOR FREE.
That kind of attitude is not only bad for the "open source" [bowel] movement; it's bad for society as a whole.
--
#19845
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.
It is always interesting to read these 'rants,' since it seems that in the future, people will be a LOT more thick-skinned.
There is NOTHING about the GPL that says anything about who you accept patches from, or how often. All the GPL says is that if I give you or sell you binaries, I have to offer to give you source, and if you give away or sell thoes binaries or modified ones, you have to also offer source. I don't have to set up an anonymous CVS tree, I don't even have to publish an e-mail address for patches or questions.
All I have to do under the GPL is make sure that you can use, copy, and modify the software, and that you preserve those rights for others.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
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
Sig:
Barbeque is a noun. Not a verb.
I do geek work at a bank. Through proper use of troll functions, I've managed to train them not to take me seriously :-)
//naked hot with grits and petrified
;-)
That's a hell of alot of detail, but could get confusing rather than clearing things up. I'd do it comment-wise myself, i.e.
const GEEKDREAMGIRL = "Portman"
The "properties" of the constant are applied with seperate functions (with the exception of hot, which is inherent).
When I moderate, I try to pull gems out of deep threads, but I don't know how many other people do. Mostly this thread is for you and me
Last, but not least;
TAG TAG TAG TAG TAG TAG TAG TAG TAG TAG TAG TAG
Bad things often happen to good people,
It is up to them to see that they remain good.
My 2cents says that Sourceforge is a great concept but between SSL and SSH the security measures make it so cumbersome to use that many part-time developers become discouraged. SSH at least should be optional. I con understand from a server maintainer aspect this level of security makes life easier, but for people who just want someplace to go and help with projects this level of security makes it too much of a pain. CVS aside, I think many groups would rather have someplace where they can upload and share files without all the hastle. It seems that in its current configuration Sourceforge is little more than a well designed secure CVS.
What is really needed is a playground where developers can interract with a minimum of hastle. On a side note, every time that I have requested assistance it was provived very quickly. I didn't always get the answer I wanted but I definitly got an answer fast. Their efforts are worthy of praise and I hope they iron out the bugs before long. Until then though, I've found another host that gives me much more flexibility buy without the level of resources that SourceForge could be providing.
SourceForge is a great boost to many open source projects, especially in providing CVS servers, mailing lists, web hosting, patch management, bug databases etc etc... Their service is fast and reliable, and you even get technical support from people who knows how to help.
SourceForge is probably doing more for the open source movement than any other single entity. They could change money for it and nobody would question it because their service is so great. But they don't. They could be proprietary, but instead they use only free software. And on top of all this, they even release their sourcecode for the project, as if they had to!
And then what: people complaining that "SourceForge doesn't help the open source movement because they release their source as a badly organized tarball and they didn't include my patch"! I mean, WTF! Fscking whining maggots!
SourceForge now hosts the entire KDE CVS. They gave it a dedicated box, and they don't even ask for a single mention of this in return. Think about that the next time you use KDE.
I can see why the poster would choose to be anonymous -- most trolls do!
--
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
Is it just me, or does the VA Linux logo remind you of the CORE logo from "Good vs. Evil"?
There is no silver bullet. Plus, werewolves make better neighbors than zombies or vampires anyway.
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.
bugger.net | MunkAndPhyber.com
try adding this:
//__PROGRAMMING_SKILL_H__ //__PROGRAMMING_SKILL_H__
:-)
#ifndef __PROGRAMMING_SKILL_H__
#include
#include
#define GOODSTYLE
#else
#undef WHINING
#endif
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!
Bad things often happen to good people,
It is up to them to see that they remain good.
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
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
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
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
All of the projects you mentioned are fairly mature, with stable core teams. My post was more concerned with taking a project from seed to sapling. As a counter example, the Gnome project has had AnonCVS since a very early stage. The growth rate of Gnome is very impressive.
One possible solution for the volunteers to take is to:
At least this puts them in the position to more easily merge their changes with the ongoing SourceForge development.
The SourceForge folks might even decide to make use of the CVS repository since they did not have to put forth the effort to set it up. They are after all time-bound right now. Perhaps they just haven't had time. (Giving the benefit of the doubt, of course)
Regards,
DeanT
so at this point what i am wondering is...
can we implement an AI that mimics the trolls and flamewars and offtopic stuff on slashdot... we seem to have all of the objects ready...
what more do we need? someone managed to make a pancake function for us... hmmm...
oh yeh...
... hi bingo
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).
Intercarve Networks, LLC
Programming is a lot easier than maintenance.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The first one (and the one I'm jumping on): He or she doesn't like how the sourceforge is distributed and how well it's cleaned up (no docs, no CVS, etc.) At the same time, he complains that they don't release often. Well, what shall they do? Release or clean up?
It's an unfortunate tendency that today it's kind of demanded to make everything proper from the start. (I still remember how the first Linux kernels looked -- no polishing at all.) If it doesn't have a configure script, it's not good. Not good IMNSHO, but you can't change people.
IMO, the author hits home with his second point, on a seperate issue: the way the SourceForge folks react on volunteers.
But one should not mix the technical and the personal complaints. That just leads to the typical /. flames, not to sensible discussions.
Joachim
People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
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 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.
My Slashdot account is old enough to drink...
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.
Anyway, #3 doesn't apply to Slashcode. CmdrTaco tried Option #2 already: only it didn't take weeks, it tooks months. In fact, it was nearly "years". AND there were people clamoring for the code and volunteering to do Option #1. Why wasn't that route at least tried?
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? (I know you aren't the official spokesbeast, but the official spokesbeast seems to have a little trouble with English)
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
I mostly agree with CmdrTaco that running an open source project is complicated, as the folks learned from releasing Slashcode (btw, I also have quite specific complaints about the management of Slashcode project, but that's another story).
But seems to me that there is a fundamental difference between a generic, huge-user-base software (mostly clients or desktop software, e.g. my favourites gnucash or fetchmail) and software that was originally developed for a very specific, site-related task and therefore suffering from a lot of idiosincrasies of the only installation.
For SourceForge, as for Slash, first was the site, then the software used to run it. Then, at a very later stage, you try to repackage the whole thing in order to let someone else use it, which is a very complicated thing and needs an extra set of efforts.
"It is more complicated than you think" (The Eighth Networking Truth from RFC 1925)
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:
/usr/lib/cgi-bin /var/www/source
ln -s
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?
Sometimes, it is better to not release any code than to do it. I mean, it's better to release something useful before letting the masses look at it.
I myself is coding a little thingie, but I won't release it public (GPL) until I feel that the code is somewhat usefull.
If they won't release the code so often now, is maybe because they want to make a good framework themselves, before seeking help to do the "real work".
What do I do, when it seems I relate to Judas more than You?
Still not dead.
Yeppers, open source rocks. However, if you don't want the trolls and natalie portman stuff, you need to make sure you undefine them with the GOODSTYLE define. There's a routine in the GOODSTYLE macro that reads:
;-)
Project(attitude)
{
if attitude == TooSerious(
TrollFuriously();
Discuss(Portman);
Unclothe(Portman);
Petrify(Portman);
Eat(Cheese);
)
else
Project(complete)
}
As you see, taking anything too seriously chews up an awful lot of compile and run time.
and TAG, DAMNIT!!!!
Bad things often happen to good people,
It is up to them to see that they remain good.
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
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?
J(ust)MHO
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
It would be nice to hear a response from SourceForge? Have they been contacted (for example by the editor)?
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
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.
Oh, look.. Another VA goon posting as AC.
Actually, no, they never did address my "claims". Nor did the address anyone else involved in the project.
You might want to try taking your own advice..Especially when it comes to that little detail you mentioned about "getting some facts before you start spouting off at the mouth."
By the way, to the guy who originally wrote the above response: Thanks, but I dont really need a spokesman. If you dont like what VA is doing to the Linux community, great, I happen to agree with you. I'd even go so far as to agree with you on the concept that they ripped me, AND the other people working on System 12 off pretty badly. Its fairly obvious by now. Just please refrain from using my name to make your point.
Thanks,
Bowie J. Poag
Bowie J. Poag
It's just like the bogus libertarian argument that "you can get another job if you don't like this low-paid, unsafe, hellish job" to someone who hates their job. Yeah, right. Dream on. Um... if they hate their job, and they still continue with it... do I even have to complete the question? It's like, mundo obviouso.
Female Prison Rape in NY
You are doing that yourself in that very paragraph. So shut up, you impolite person!
Seriously, we do have a right to complain. Let me use this (little bit stretched) analogy. If I give you some free source code, then call you a moron every time you try and contribute back, would you still say you had no right to complain? How about if I physically punch you in the face? Would you still say you had no right to complain? Where do you draw the line?
Some people are clearly getting frustrated and they have every right to complain.
Female Prison Rape in NY
Amongst the trolls, it seems customary to accuse moderators of smoking $3 crack. So for each enum we use we have to have another set of enums for quality, unless you want to link it all in one nasty string. easier just doing it as another dimension in an array.
;-) Though we are getting away from the real point, which is . . . .
Digression? we're discussing forging source! Look at the headline
TAG!!!!
Bad things often happen to good people,
It is up to them to see that they remain good.
The bottom line for me is that software maintenance sounds much easier under the Free Software / CatB model, but it's not. You still have people trying to read your code, which is equivalent to reading your mind.
--
"You're gonna need a bigger boat." - Chief Brody
Linus takes are very hard when it's ready line with the development. Sure Alan does a kick ass job of getting pre releases out, but you don't hear as much bitching about that.
After releasing one small GPL program (that was only really usefull to perhaps a small group of people) and getting nothing but flames, I know the feeling.
With VA taking a pounding in the NASDAQ maybe they had to lay off all the project managers...whos knows why. But sometimes it seems that the Linux community (and to a lesser degree, the Free Software Community) takes the approach or bitch first, ask questions later.
-- Are you an EFF member yet?
...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?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Forged source may be somewhat evil
Delays in releasing source may be annoying
This goes beyond evil: AOL orders Mozilla to remove code that blocks adds
When Monopolies believe that it is their right to control open source development that will be the end of the OSS Movement.
134340: I am not a number. I am a free planet!
How is he going to fork the hardware and bandwidth?
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
A CVS server for slashcode does exist. You can get instructions of how to connect from http://server51.freshmeat.net/projects/9/
Also try the website at www.slashcode.org for further info.
Lee
//ok, the original was a tad simplified...
//note fall thru /dev/null; //yeh yeh... its not syntactically correct
while(UsingOpenSourceSoftware())
{
if (BugFound())
{
switch TypeOfUser
{
case "Programmer"
FixBug();
case "NonProgrammer"
ReportBug();
break;
case "Troll" || "Flamer"
Complaint >>
}
else
{
ProvideFeedback();
}
}
... hi bingo
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.
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.
This turns out to be not as evil
The feature was not removed it just had it's preference turned off.
134340: I am not a number. I am a free planet!
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!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
There's also the CVS portion of Slash project containing the instructions without clicking further. The ultimate for the lazy bum :o)
--
--
Me spell chucker work grate. Need grandma chicken.
But, if people cared to check on http://sfdocs.sourceforge.net/, they will note the ease with which volunteers may now submit documentation to the project. Not only this, but also the number of staff written articles on SFDocs.
Of course, the offer is always open for _anyone_ to submit documentation at any time. =)
regards,
Quentin Cregan (aphzen)
Support / Systems - SourceForge.Net
just wondering, but you have Portman as a variable? Maybe Its a constant or a #define, but usually when I use constructs such as these, I use all caps...
Unless of course you think that the object of everyone's discussion will change from Portman, and then I would probably make it a const of GEEKDREAMGIRL so we can change it when need be...
... hi bingo
I understand the complaints here. I also understand Taco's defense. Perhaps what is needed is three sets of code: stable, unstable, and sausage. The first two would require administration and be prone to the delays and inconsistencies attacked above. The "sausage" directory would contain code, unsubstantiated patches, unincorporated features, lips, dirt, bits of hair, etcetera. That way hardcore open-sourcers could get at the bleeding edge stuff themselves, and could even fork the project if the official maintainers weren't keeping things far enough up to date. But meanwhile, those controlling the project would be able to keep a well-organized, documented version that was officially unaffiliated with that vat of partially defatted fatty beef tissue over there.
Of course, there would still be complaints that patches weren't getting out of the sausage bin quickly enough. But at least then if the complainers became numerous enough, they could mount an effective response.
- Michael Cohn
-----
Go ahead, blame me... I voted for Nader!
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
Gonzo Granzeau
"Nothing the god of biomechanics wouldn't let you into heaven for.." -Roy Batty
However it is nice to see sources released in standard tarballs occasionaly. It's kind of a stroll down memory lane - 5 years ago running an old slack distro and doing everything by hand. I'm glad things were more complicated and aggravating back then before RedHat RPM and Debian, because I learned things. How to install and un-install stuff, what belongs where, etc.
Fuck Ajit Pai
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. :-)
Please, warn us before you write things like this. It's really awkward when I roar with laughter, and everyone can hear it. It makes it pretty clear I'm reading something unrelated to work.
One Company. One Program. One User. One Virus. One Less Mouse Button. The Best is Yet to Come.
Well, what can I say? I'd say I've told you so, but I didn't, but anyway it's certainly not unexpected that the open source model so praised by /. and other similar communities has failed to deliver on its quite amazingly grandiose claims.
When people praise open source, they point to the legions of developers, the "many eyes" to find bugs, and the ability to quickly and efficiently incorporate user feedback and requests. But the truth seems to be a "little" different from this Garden of Eden coding paradise.
Most open source projects are really only the work of one or two people, who occasionally can be bothered to actually write a few lines of code and then release it as the next version (hence version numbers like 0.99beta-pre3). There is none of the dedication which occurs in a closed source software house, and certainly none of the encouragment or rewards, unless you count the mythical "kudos" which are often heard of, but never seen.
And as for the bugs issue, well, how many people ever read the source code to something they download? Not very many from what I can see. And when you've got projects as convulted and bloated as the Linux kernel, how many people can actually find the bug in the first place? Linus and a few of his cronies is about all I'd say. So this argument seems to be little more than hand-waving.
User feedback ties in with both the previous two points - it all depends on whether the coder(s) actually bother with doing anything often, and whether bugs and requests can actually be fixed.
Two high profile open source projects - Mozilla and the HURD - have both been pretty much vapourware for the last God-knows how long, and if you ignore the extremely buggy versions of Mozilla which we've seen, they appear to be so for the forseeable future.
Closed source may not be the best thing in the world, but at least it delivers what its customers want and on time.
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
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
I maintain our LUG web site. The ratio of constructive criticism to kudos is actually about 1:1. It's actually scary that I receive so few comments either way, given the relatively large number of LUG meeting attendees (average 60-70 / month). Another intersting point is that although I give instructions (on the site) on how to build the site and contribute to development, rarely am I approached or do I receive patches or contributions.
--
"You're gonna need a bigger boat." - Chief Brody
BITCH ALL YOU WANT TO about source forge, but from where I stand they're doing allright by me.
Source forge also runs (or at least has alot of involvement with) phpbuilder.com. (via Tim Perdue) phpbuilder is, for me, a budding php programmer, a godsend!
There are LOTS of source code snippets, lots of user feedback, a clear, well-organized API with lots of articles on howto this and that, and I have many times gone back and forth to sourceforge to get what I wanted.
It's possible that the stuff you all are complaining about is stuff that they aren't trying to do?
Look before you leap. Be careful not to bite the hand that feeds you, or you just might end up hungry.
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
The points made in the comments "Most open source projects are really only the work of one or two people" and "how many people ever read the source code to something they download?" are well made. I can't say for certain, because I haven't carried out a poll or seen any statistics. What I know from the literature (such as CatB), experience and observation is that most open source projects start out as an itch that a programmer decides to scratch. The majority of people who find out about the project don't do anything except download the binary, a few download the code, a fraction of them comments and a fraction of that fraction hand back some modifications. Only a small portion of the much-vaunted "many eyes that make bugs shallow" are actually being harnessed. That's not a bad thing -- the closed source model exposes the software to even fewer eyes. It's just that there are many obstacles to fixing or modifying someone else's code: how the original programmer wrote it, availability of documentation, availability of the programmer to answer questions, whether it's written in a language you know, the complexity of the program's problem domain, how good a programmer you are, and the big one -- how much time you have.
The primary advantage provided by open source to a program's developer is the potential peer review and fine-grained testing that freely handing out your source gives you. There's a large body of evidence that code review is one of the best ways for incresing software quality. However, as Fred Brooks says, there's no silver bullet for the problems of software development, and peer review is only one step in making good software. Without good planning and process, all you have is a bickering committee. And we know why they don't make statues, painting or memorials of committees, right?
There's a very good article by Steve McConnell (author of Code Complete, Rapid Development, Software Project Survival Guide and After the Gold Rush) covering some of the issues around open source software. He points out that if open source wants to really reach its potential, the following needs to be done:
1. Create a central clearinghouse for the open-source methodology so it can be fully captured and evolved.
2. Kick its addiction to Code and Fix.
3. Focus on eliminating upstream defects earlier.
4. Collect and publish data to support its claims about the effectiveness of the open-source development approach.
===
Getting back to the original reason for this post -- could I ask one of you moderators to consider cancelling out the "troll" rating for the previous post with an "underrated"? A contrarian opinion does not constitute a troll.
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
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.
and this is what happens when open source is done correctly... one person does something, and then is tweaked back and forth until the program is usable... incredibly powerful stuff...
now if you add in some natalie portman and grits, and flames and general whining, you could have the complete process...
also notice how these things subtract from the project, and not add...
... hi bingo
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.
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.
i gating attitude that we see more and more often.
This appears to be more of the complain-publicly-that-corp-is-evil-before-invest
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.
Option 1: Realease early often and show the world all the work you are doing. Including the dumb stupid moronic bugs. Get flamed for putting out such low quality work.
Option 2: Release periodically when you have a nice stable point. Make sure as many bugs are out as possible. Get flamed for not being open source.
Oh this sounds like fun. Yes I'll admit the hypocritical part of this (with them preaching the realease often part) sounds odd. But this is really their choice. And its all still compliant with GPL. Released in a timely fashion. Yes it'd be nice to see a CVS repository and a tar ball release, but that's tough.
-cpd
I 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
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
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
My point is that its hard to maintain open source packages.
Wow, programming is hard too... who would have thunk it?
DrLunch.com The site that tells you what's for lunch!
I maintain some minor free software packages, and the flames/whining[1] vs. praise in my email is about 0.1 or so. I.e. much more positive email than negative. I talked to a friend who put in a lot of work to maintain a web site / database about cultural events, and asked if he didn't feel the positive feedback compensated for the hard work, expecting a similar ratio. But he answered that the ratio was the opposite.
/. posters act personally insulted, each time an /. makes an editorial choice they disagree with.
Which makes me wonder: Are users of free web sites a lot more inclined to whine and flame the people who provide them, than the users of free software? It certainly fit the way some
[1] I distinguish between "whining" and constructive critisism by the whiners seeming to think they have a right to *demand* improvements, or feel cheated if the free software doesn't solve their particular problems.
I will be blunt and outright and say that I think that open source should always be the solution. I won't complain if someone is merely giving their product away. I might ask a few questions about it, especially if it's about a bug or something like that. However, if the person opened up the source code, I would definitely send them my gratitude. I would more readily choose open source software over closed freeware.
OTOH, I would choose closed freeware over commercial anyday.
// file: mice.h
#include "frickin_lasers.h"
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.
Actually why does slashdot necesarrily have to set up CVS? In fact I'll just buy CVS.cx and set up CVS for slashdot which slashcode can link to. Then I could set up CVS for Windows just in case.
Seriously though, the Internet destroys time and space and gives us links and bandwidth. Why are people still complaining as if you actually had to row an unmarked barge to Christmas Island just to set up a site?
Comfort breeds whining, who'dathought?
The message on the other side of this sig is false.
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.
I'm a loner Dottie, a Rebel.
As a person who is currently working on a version of sourceforge adapted for a free website service (code will be released as soon as the site is operable), I know how annoying sourceforge's policy can be. For example, when I started the project, I figured that the sourceforge tarball would have all the parts of the sourceforge site. However, I was wrong. It doesn't include the very important cronjobs that handle things like user addition, account creation, cvs setup, etc, the very things I needed the most :P Argh. Anyway, I had to add a field to the database and am writing my own cronjobs. Meanwhile, I'm spending about twice as much time as I thought I would when I started this project, and getting paid the same (basically a street perforrmer's protocol system). So, sourceforge, please do a COMPLETE release next time.
Well, that's my opinion, anyway. There are two sets of opinions here, and the lines seem to be drawn between those who have developed applications for direct consumer use (who tend to be the open source skeptics) and those who have developed server apps ((the zealots).
Chris
--
Grant Chair, Linux Int.
Pres, SVLUG
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
First off, please read Mark Stone's post above regarding the web/asp issues and the gpl, they are -very- important. This represents one of the biggest problems for us (by us I mean all of us) right now. That said, we do releases based on the gpl every couple of months, so I'm fine with that.
While I understand the frustration the AC felt with the patch and documentation systems (more on this later) the AC should realize that when a group does work on an open souce project many people choose to go the route of tarballs every few months. You may not like this method, I don't. I asked myself last week why the cvs tree wasn't public, and while I did not agree with the SF team, the fact is, since they have tarballs coming out often (and I tell you, every two or three months is a completely reasonable interval) I'm not going to tell them how to run thier project. Any more than I would tell mandrake or raster how to run enlightenment.
It sounds awful, and counter intuitive, but many of the OSS worlds best projects are run with an iron fist without external cvs servers. Not that I wish to equate SF with the importance of the Kernel, but when was the last time anyone saw a cvs server from Linus?
Now, the patches and the rest, I'll take a look at what's up and see that they pay greater attention to them, but again, a few procedural mistakes in the early stages of an OSS project is common and forgivable.
So what I'm trying to say in a nutshell is, if SF is only released every three months, and if they choose to completely ignore outside help, that's fine, that's a choice they are making. I don't think it's the most efficient, but it's thier choice to make and I'm not going to interfere with how they practice what so many others don't even have the courage to preach.
Anyhow, if anyone would like to contact me personally about this, please email me at chris@valinux.com (or chris@dibona.com).
One last thing, I can't stress enough the importance of Mark's post. IF you didn't read it , you should. The GPL as written basically allows people to write an ASP like SF and put it out under the GPL. At that point, another person can take the code and set up thier own public SF, which is fine, but any changes they make don't have to be redisributed, which is not. This is a -big- problem, and if the GPL is not fixed, there will need to be a new licence made to address it. We'd rather just use a GPL that covers this contingincy. I'm of the opinion that a clause in the next version of the GPL that says that "public distribution as defined includes use on a public web site" thereby introducing the redistribution requirements for such uses, but I'm not sure that this sort of language will work to promote GPL'd software in the right way.
Anyhow, any thoughts on this would be appreciated.
Chris DiBona
VA Linux Systems
--
Grant Chair, Linux Int.
Pres, SVLUG
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
Of course I am being a "whiner" here I suppose.
Let's think of it, How many of you will be downloading source forge and setting up a source forge server? Thought so. So why should they run it as if it is a project that the mass will download and work with the source? It is very sad that whenever people give something to the community, that there are always people who will find something to whine about it. Let's assume that source forge is closed source, so what?! If source forge was closed source, I still do be 100% grateful. It is a service, that is what I appreciate, I don't see it as a program. The same thing with slashdot, slashdot is a service to me, not a program. If it was a software that I ran on my system, then perhaps I will be concerned.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
it's the longest that I'VE been on-topic and relevant ;-)
Bad things often happen to good people,
It is up to them to see that they remain good.
I'm not sure that putting a clause in the GPL that affects public web sites is such a good idea. Here's my reasoning:
;) It's about choice and freedom to control the behavior of ONES OWN computer. (sorta ironic that it's about the freedom to CONTROL your computer, huh?)
:)
GPL is about the freedom to control the behavior of your computer. If you use a GPLed program on your computer you should have the right to modify the program to function differently. It's your choice.
To protect this choice, the GPL states that when software is distributed to another party, it must be accompanied by the source code so that the choice is equally parted onto the next person.
That's my interpretation of the GPL. I do not interpret the GPL as the tool for the overthrow of proprietary software.
Now, if we believe in freedom to control ones own behavior, then isn't it counter-productive to want to control the behavior of someone else? (I read Chris DiBona's comment below about Lawyers getting involved... aren't they the masters at control?)
In fact, the rule that states that you must distribute the source code with your GPL work is really the only point of contention that a lot of people have with the GPL. What we're saying there is: "Freedom is our number one value, but in order to protect freedom we must restrict freedom in this ONE case." Some people feel that it's not worth it and choose other licenses for their work.
My personal impression is that this ONE exception is placed in the GPL very carefully, because you can avoid this restriction if you do not redistribute your changes to a GPLed program.
Basically, the restriction to have to release your source is not on your decision to change the code, or to EVEN use the code. It is when you redistribute the code for use on OTHER computers by OTHER users. (maybe I'm missing some key info here, but that's my interpretation.)
Therefore you can make changes and alter the USE of a GPLed program and not have to release the source code.
The question that plagues us now is: "What if the GPLed program interacts with OTHER users?" This is the case with all software that is used over a network. Other computers are asking YOUR computer to execute a program and return a result. Is the other user, since they are 'using' a GPLed program, entitled to now see the source code.
I say NOT!
Because, the program is being executed on YOUR computer and not the user's computer.
Now, you may disagree with me on drawing the line here, but I think we should because if we draw it anywhere else, the house of cards that is the GPL will come tumbling down like nothing you've seen before.
On the other hand, I truly empathize with the user of GPLed software to have the freedom to change the behavior of the program, even if the program is running on another system. Of course, we can't give the user the right to modify the way the software behaves on the other system. The best we could do is to have the user download the GPLed source code and set it up on their own systems.
And so a reasonable GPL modification might be: "If you use GPL software that has the ability to be used by anyone but you, you must release the source code." After all, you did decide to use GPL software that was built by others, and now that you've decided to let other users use the program you must release the source code and give other people the freedom also. This seems to be perfectly in line with GPL philosphy, the way I understand it.
However, I think the burden that is now placed on the developers is too great. If they create a GPLed program, or modify it, which in any way communicates with other users or computers, which most programs now-a-days do, then they would be required to release the source.
It is now impossible to make any personal modifications to your own setup of GPLed software without releasing the code. Think Sendmail, POP clients, etc.
OK, I must admit, that I've now confused myself, because I now understand the pro-ASP licensing arguments at lot better. And I don't know if I can muster the right arguments against it. But, my gut is still telling me we should be insanely careful before we add additional freedom-robbing exceptions to the GPL. I feel the burden of proof should be on the side of those who want to mofify the GPL.
The question of course is, whose freedom are we talking about: the user or the developer?
Maybe someone else can complete my thoughts on this.
Hans Cathcart
hans@cathcart.org
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.
:-)
An Eye for an Eye will make the whole world blind - Gandhi
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!
Which seems to be another thing AC was ranting about: if you open-source a project and are asking for public involvement/assistance, be so nice as to respect those who did contribute, don't just ignore/screw them.
--AP