SourceForge Fails To Forge Source? 161
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 ;)
Re:...and why respect matters (Score:1)
Linux Development model (Score:1)
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.
Re:Take it easy... (Score:1)
> 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...
This whole thing seems to be run by babies (Score:1)
Re:Take it easy... (Score:1)
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
Re:the major problem... (Score:1)
So, why don't you fix this major problem instead of complaining about it?
Re:sourceforce and asp licensing (Score:2)
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.
We are entitled to junk! Hooray! (Score:1)
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.I think (Score:1)
will the wonders never cease?
Now if someone could work in "JonKatz suckZzz" in a relevant manner, we will be complete
Re:Your Rights (Score:1)
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
SourceForge staff helps contributors (Score:1)
Re:Yet again the open source model fails to delive (Score:1)
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.
Idea: Why not use their own system? (Score:1)
What's wrong w this picture?
asp licensing (Score:3)
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
Have you ever actually tried packaging something? (Score:4)
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.
Fork the code (Score:2)
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
a HOWTO for maintaining projects? (Score:5)
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.
But these are people... (Score:3)
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
maintaining open source (Score:3)
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.
Sorry, I am just me. (Score:1)
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?
Re:Critiquing Free Services/Software (Score:1)
Re:open source (Score:1)
>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
Re:the major problem... (Score:2)
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Re:I'm working on a spinoff of sourceforge (Score:1)
the major problem... (Score:5)
try this logic
if(ProblemInCode(ProjectName))
FixCode();
else
UseCode();
Note that the function ComplainProfusely() is not in there...
if theres a problem, shut up and fix the damn thing...
Re:the major problem... (Score:2)
your missing the point of SourceForge (Score:1)
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...
Patches & Open Source (Score:3)
chocolate and peanut butter. (Score:1)
you got c++ in my java!!!
Open Source = Collaborative Projects? WTF? (Score:1)
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.
Your Rights (Score:4)
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.
Re:That won't work in this case (Score:2)
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.
Complaining (Score:3)
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.
Re:Catch-22 (Score:2)
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
Good points, but... (Score:1)
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.
---
Re:I think (Score:1)
TAAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGG!!!!!!!!!!
Leading by example (Score:2)
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?
How to make packaging easy: (Score:5)
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?
Stable and unstable branches (Score:1)
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.
If only it were that easy! (Score:5)
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!)
Don't confuse the concepts (Score:3)
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.
Re:How to make packaging easy: (Score:1)
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?
Re:Web sites vs. source code projects (Score:1)
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.
Re:How to make packaging easy: (Score:1)
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.
Ingrates (Score:2)
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.
--
Re:Your Rights (Score:2)
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
Re:the major problem... (Score:2)
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?
Re:Gosh, Y'all can be JERKS sometimes... (Score:1)
Re:Catch-22 (Score:2)
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
SourceForge is not about SourceForge! (Score:4)
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!
--
Re:Your Rights (Score:2)
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.
Hohum
troc
Open Source or no, it's good. (Score:2)
Re:How to make packaging easy: (Score:2)
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.
argh. doesn't compile. (Score:2)
#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!
Missing the point.... (Score:2)
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
Sorry, you are just wrong. (Score:2)
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
Re:the major problem... (Score:3)
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.
Still opensource, just not like you expect... (Score:2)
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).
Hmm... (Score:2)
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.
Different kind of Open Source software (Score:3)
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.
Why do they even need to release a tarball? (Score:2)
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?
Re:Your Rights (Score:3)
true (Score:2)
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
Re:How to make packaging easy: (Score:2)
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.
Why clone ASPs will contribute back ... (Score:2)
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.
What about the kernel? (Score:3)
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.
Scratching an itch? Or starting a business? (Score:2)
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?
Re:the major problem... (Score:5)
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.
Re:Slashdot response? (Score:2)
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.
Lee
Growing a Free Software project. (Score:2)
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.
Manners anyone? (Score:5)
Now weary traveller, rest your head. For just like me, you're utterly dead.
My Thoughts (Score:2)
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!
Re:It's all about public relations... (Score:4)
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. =)
regards,
Quentin Cregan (aphzen)
Support / Systems - SourceForge.Net
OSS (open source sausage) (Score:3)
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
Slashdot response? (Score:2)
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
It's all about public relations... (Score:3)
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. :-)
Re:SourceForge was a rip off from the beginning (Score:2)
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
sourceforce and asp licensing (Score:5)
The GPL covers code distribution. A proprietary third party could, however, take the code, make improvements to the code, and put up a competing site using the improvements. Nothing in the GPL would compel them to release the improvements.
Do you know how to extend a GPL style license to the web? I don't. I know that several key people from the community are working on the issue, as well as several high paid lawyers.
Check Slashdot's interview with Stallman, and look at Bruce Perens' questions for him. You'll see that Stallman acknowledges that (a) the GPL doesn't address this issue and (b) the issue needs to be addressed.
Everyone at Sourceforge is doing the best they can to work things out, but folks, we're in ucharted territory, so bear with us.
Mark Stone
Media Publisher
VA Linux Systems
strider@linux.com
Re:open source (Score:2)
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.
Re:Scratching an itch? Or starting a business? (Score:3)
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.
Open source Bill of Rights (Score:2)
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.
Re:the major problem... (Score:2)
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
Re:Mozilla + Ad blocking (Score:2)
This appears to be more of the complain-publicly-that-corp-is-evil-before-invest
The extemists... (Score:2)
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.
Catch-22 (Score:4)
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
Take it easy... (Score:2)
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
Re:Good points, but... (Score:5)
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.
Opening Up (Score:4)
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
Web sites vs. source code projects (Score:5)
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.
Problems not unique (Score:4)
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.
Not all... (Score:2)
Re:sourceforce and asp licensing (Score:2)
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.
Re:I'm working on a spinoff of sourceforge (Score:2)
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
Re:The extemists... (Score:2)
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.
I obviously meant Server51. (Score:2)
Chris
--
Grant Chair, Linux Int.
Pres, SVLUG
Re:Let's go back to the example, then (Score:2)
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.
Hey everyone... (Score:5)
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
Why do you want fake source ? (Score:2)
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.
:-)
It's the cathedral and the bazaar all over again (Score:2)
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!
Re:the major problem... (Score:2)