Slashdot Mirror
Open Source Studies
e8johan writes "Avaya Labs Research has presented a paper studying the open source process in the cases of Apache and Mozilla. They reach a number of interesting conclusions, the ones I find most interesting are: * Open source projects tend to have a core team of 10-15 coders, producing almost all code. The next layer is a set of developers submitting new features and bugfixes. The next layer is a set of advanced users submitting bug reports. * Open source projects tend to have a lower bug-rate than commercial projects. * Open source projects are generally quicker to respond to user requests. The article also discusses the differences between projects that have always been open source (such as Apache) and projects having a proprietary history (such as Mozilla)."
But it's good to hear it reaffirmed from an outside source what many of us know to begin with -- OpenSource development is more successful because the people involved love what they're doing.
if these projects average 15 coders, on average they're also significantly less complex projects, and then of course on average theyll have less bugs.
also, if you have a team of people who are PAID to find bugs, theyll find more.
... and here is my bug sumission. It's spelled COMMERCIAL, not commersial I guess this submission was proprietary.
GNU/Linux=OpenSource=Freedom
"Never doubt that a small group of thoughtful citizens can change the world. Indeed, it is the only thing that ever has."
-- Margaret Mead
So close and yet so far from the world's perfect ID number
Open Source projects tend to have less men with whips walking around your cubical.
"We are slaves."
I bet most open source projects would be better if the 10-15 core coders were paid as full time employees. Of course this would require compaines to back them, which is easier said than done.
ALR-2002-003-paper.pdf
This is funny, not a troll. DUH
"While there are many dangers in the world, the threat from Iraq stands alone because it gathers the most serious dangers of our age in one place," the president said.
--People in stoned houses shouldn't throw glass.
Read more about The Chump-In-Charge
Now, watch how quickly comments filter in, on a 43 PAGE PAPER. ;)
Get thee to the bible of all things Software The Mythical Man Month. Take 15 motivated and talented indivduals (they have to be both) and they will whoop the arse off a team ten times their size which is filled with average people.
Adding more people _makes_ a project more complex but not in terms of the problem being solved, it makes it more complex because there is more communication and communication is not always accurate, the more communication the more bugs. Its no suprise when you look at some elements of large OSS projects that you see that PersonX does everything on Y, its this "master" concept that helps them deliver. And of course in having an excessively large testing team by commercial standards, testers out-numbers codes by huge ratios, any one been on a commercial project where there was even parity.
OSS is the best way to run a paid or unpaid project IMO, the problem is that it looks so expensive on the surface the companies don't do it. But the Total Cost of Ownership is much higher because of the lack of testing and the lack of review, and of course because instead of 15 developers and 100 testers they have 100 developers and 3 testers, 6 managers, 1 programme manager, two account managers, one account director and two administration assistants.
The common factor between OSS and standard commercial is that no-one does enough documentation.
An Eye for an Eye will make the whole world blind - Gandhi
Anyways Adobe has a pdf translation engine here. Just punch in the URL ...
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Open source software has been in my mind more of a philsophical debate than one of software production. It seems like computer science mimics things a lot in regular science. A new *thing* is discovered, and becomes a widely used standard incorporated into other programs (aka inventions) and it becomes part of the market place.
According to the article: Proponents claim that OSS software stacks up well against commercially developed software both in quality and in the level of support that users receive...
In many ways this is true, but coming from me, someone who is trying to switch from windows to linux, help is a lot harder to come by than they claim. I've relied much on my friends who have used linux to help me get my system running, and without their help I would have spent weeks on google, newsgroups, forums, doc, and man pages just to get things as simple as my audio drivers for my laptop working.
Support for OSS is minimal at best, and that's to be expected. When you have to pay for software, someone is payed to answer phone calls, to write thorough docs.. because it is their JOB. I know a lot of people, such as those 10-15 dedicated developers like the article says, can do a lot when it comes do documentation and support, but companies beat them hands down in this department. That is a big problem, there needs to be a better system. The irony there is if you make linux easier to use you lose the power of customizing your kernel, or optimizing programs by compiling them on your machine, etc.
If something isn't done though, OSS software will always take more time to setup than commercial software.
- tristan
One of the authors, Roy Fielding, is on the Apache Board of Directors. I haven't read the paper yet and I'm sure he can be objective, but still.
While everybody works on creating the cool things, the uncool things get little attention. That's where proprietary software is still superior. You can get paid to do the grunt work. In Open Source, nobody really cares when you do that, and you won't look at leet as the guy making another IRC application.
So the big boys like Microsoft and Apple will always have a leg up.
SIG:Slashdot: indymedia for nerds.
And herpes leads to open sores. And thus the cycle continues.
Here
Of windows in all the wrong places = bloat, slow, ballooning req's.
I went to battle MC Escher but drew a blank
Open source projects are generally quicker to respond to user requests.
Oh, please stop making me feel bad.
So open source group dynamics are similar to closed source projects. Not really surprising, since both are staffed by people!
Larger more formalized projects, aerospace for example, improve on the above by making subgroups of subgroups. This layering of project & program management really increases the overhead. It seems to slow things down, but at the end you can put things together and have a hope of making it work. It's really a formalization & extension of the way we organize ourselves naturally.
"Glory is fleeting, but obscurity is forever." --Napoleon Bonaparte
HTML version via since the original is slashdotted and a PDF anyway.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
It's all well and good to focus on the characteristics of a successful OSS project. It's extremely interesting that these projects succeeded without elements that are considered to be fundamental to success in commercial development. However, studying success provides only half the picture. It won't tell you what things to avoid that tend to make OSS projects fail. Without that knowledge, attempts to reproduce and improve upon the methods used by Apache and Mozilla will experience unforseen failures that could have been avoided.
How can we afford to ever sleep
So sound again
--ebtg
It is often characterized as a fundamentally new way to develop software that poses a serious challenge to the commercial software businesses that dominate most software markets today.
I was under the impression that this kind of approach to building is a fudamentally old way of getting the job done. The Homebrew Computer Club essentally built everything "open source" (well, it was hardware mostly, but same approach). The current resurgence of OSS is not something new and revolutionary, it is instead a rediscovery of old techniques that were coopted by big business.
"Your superior intellect is no match for our puny weapons!"
While Apache is indeed a good responsive project with strong management, Mozilla is a prime example of open source mismanagement. Its non-responsive, riddled with bugs, slow to fix those and generally led in a way we prefer to attribute to "evil commercial" software.
Not sure where are those rosy conclusions in paper came from on the basis of these then.
There are better open-source projects (FreeBSD?), well managed and extremely open to outside users. Development there, by the way, is done by a core much larger then 15 people.
I had two peacan danish rolls and a cup of coffee.
The Raven
The Raven
The report mentioned many things that we already know. But there's one important thing about the Open Source software the report may have missed
The freedom to change / customize the software via the source code.
People can argue that even Windoze can be customized - background, for example - but it ain't the same as cusomization via source code.
Do you ever have the feeling, when you use commercial / close-source software, that some part of it are kinda stupid, cumbersome, or simply plain assinine ?
Do you ever think that if you _just_ have the source code, perhaps you could do some change to it, at least to better suit your taste ?
Well
Now, of course, not every one know how to code, and even fewer of us know how to tweak the code to our own liking. But that doesn't change the point that with Open Source, we _can_ change the software anyway we like it.
It's a feeling of having TOTAL CONTROL over the software.
It's a feeling of empowerment.
It's just _the_ thing close-sourced software users don't get to enjoy.
Muchas Gracias, Señor Edward Snowden !
>>There's really no equivalent to Apache or XFree86 in the open source world.
>What about Apache or XFree86?
Grandparent meant[1] that there isn't any other mature web server or other mature set of low-level GUI software.
Except there is: AOLserver, the web server software that AOL Anywhere runs, is under the Mozilla Public License 1.1.
[1] Meant != said. Some people in a hurry have no time to be pedantic because they have a life.
Will I retire or break 10K?
I am sure MS must be coming to the conclusion that an open development model is better. And they are masters of strategy. So what can there response to this be?
The things that Ballamer has said about their Shared-source initiative have been pretty dumb (that it proves that people don't want to see the source code, stuff like that), so it seems that at the top level they still don't get it. But they will. So what can they do? Obviously they can't GPL their stuff but is it possible for them to start using a more open development model and still maintain the leverage they currently have?
Personally I hope not. When it comes to developers developers developers, the OSS development model is currently winning and it's going to be difficult for MS to change that.
I'm sure the study will have very little effect on software development practices.
It reminds me of the study cited in DeMarco and Lister's "Peopleware" on the relation between schedule setting and productivity. They compared programmer productivity under four regimes: schedule set by the manager; schedule set by the programmer; schedule set by a neutral third party; and no schedule. The first three alternatives were tightly bunched, with "schedule set by the manager" producing the worst results (but only by a small amount). The fourth, no schedule, result in more than double the productivity of any of the others.
This book has been out for at least a decade, but as far as I know it has not led to the adoption of schedule-free development anywhere...
"How to Do Nothing," kids activities, back in print!
Oops !
... and here is my bug sumission. It's spelled COMMERCIAL, not commersial I guess this submission was proprietary.
All the words below this paragraph have been rot-52 ! This is a clear violation of DMCA. Somebody please catch me !
This message was encrypted with rot-26 cryptography.
Attempting to circumvent this encoding is illegal under the DMCA
Muchas Gracias, Señor Edward Snowden !
The metric they used was bug density, not the absolute number of bugs. In other words, number of reported defects per N lines of code.
...
Mozilla is a far larger project than the Apache core, so given an equivalent number of bugs per N lines of code you will see a far larger number of bugs.
They did report that to some extent the measurement of bug density wasn't necessarily directly comparable due to the different state of the projects at the time the report was written (Apache == stable, Mozilla == pre-release). If you're interested in more details read the paper yourself
If your open source project does not have a critical mass of developers it will fail. Critical mass can only be acheived if the program being developed is largely finished or already useful in some way. Everyone likes to back a winner. The exception to this rule is when you have a project started by someone with past successes such as Miguel starting the Mono project after the successful GNOME project. But then you could argue that C# was already a mature specification for Mono to exploit, so it was already a "winner" in a sense. The Parrot project, by comparison has the disadvantage of not having pristine design specification and documentation (courtesy of Microsoft) to mimic.
Often, the majority of work in a pre-critical mass project has already been done by a single individual. This is conveniant because they usually become the defacto project leader. It is just as useful to prevent poor contributions into the project as it is to add quality code to the project. This is due to the fact that no one likes code audits.
And the final mark of a good open source project - the leader cannot be a prick. There's too much bullshit to put up with in day to day life, why would you want to get harassed without being payed?
Teenagers these days don't have as much sex as they want each other to think they do.
One Leader
One inner circle of designers
10-15 core group of coders
Dozens of bugfixers, feature submitters
Thousands (and then some) of users
Several Slashdot articles
Hundreds of Insightful, Informative, Interesting posts
A preponderance of troll, offtopic or subjectively funny posts
Priceless
A feeling of having made the same mistake before: Deja Foobar
They're doing it because they enjoy it. Duh.
Ya know, labor of love and such? I think the corporate environment tries to synthesize this through loyalty programs:
"We're a big family here, therefore you will take pride in your work!" *iron fist slams down*
"And of course in having an excessively large testing team by commercial standards, testers out-numbers codes by huge ratios..."
This is probably the most profound statement about OSS I've seen in this discussion.
OSS projects are not better because the coders are more talented or devoted than closed source projects. They are better because they actually have QA resources that cannot be matched by close source projects.
Stop and think about this: put a team of 1000 testers on a project who actually understand the software and do not test by a following a checklist of requirements but actually try to use the software and give them direct access to the developers (ie, remove the management/marketing layers that filter bugs). I suspect in this case a closed source project could have the success of an open source project.
Think about it.
-Chris
I know you are already receiving enough remarks related to your opinion that Open source projects would be better if core coders were paid, but I feel it is my duty to share my thoughts.
:-)
So I will remind you that until 'Open source' is a mainstream idea, the people who believe in it will work tirelessly and uncompensated (like with any new idea or project). At some point, our system of commerce will understand and master how to compensate for intellectual property without locking up the code, and all will be well in geekdom. Until the concept of Open Source and intellectual property can be understood by mere stockholders, they don't see how they will make money, hence they are not interested in subsidizing something that they do not understand will lead to the pot of gold.
You are not wasting your time reading Slashdot, you will meet women who also read it (if that is your intention). I know I love my geek.
Hello everything.
All the advantages of Open Source Software included in the report are true (IMHO).
But there is one thing the report forgot to mention.
There is few Open Source Documentation. The existent documentation is shitty: poor, bad explained, often out-of-date or incorrect.
And you always gets mad to install and configure the product.
Come on. Don't treat me as a troll. You know that this is true. I have experience with Open Source Products too and I can't remember all the nights I spent without sleeping trying to figure out why some Open Source product doesn't work the way it is supposed to work. And after some days of anguish, found some clue on the Internet that tells me that I have to do something (of course, this information wasn't part of the documentation).
Commercial products are easier because of the extensive documentation. Open Source products are made by people who love programming but don't love writing manuals or documentation.
This is the other side of the story. I'm not against Open Source Products (I use several of them and now I am teaching a course about how to use several of them) but the lack of decent documentation is a major drawback which makes difficult the adoption of Open Source as the general standard.
Only my two cents.
Vicent Palasí
I know of an Avaya product installed on a large corporate network. It runs HP-UX internally!! According to my buddy the security geek (and I quote), "Avaya fears Open Source". They don't even install OpenSSH, all their traffic is telnet or worse. Nor do they use Samba or Apache - although their products could be greatly improved by either one.
And get this: they won't let their customers know the root password. That's right, you buy a closed box with a known hackable OS (and it's not secured AT ALL - my buddy found a dozen known vulnerabilities left open) and then they expect you to install it behind your firewall!
--The Rev
Mozilla is an excellent project to study. It failed to meet deadlines most of the time. It broke ground.
IMHO, the only reason Mozilla materialized, was the long-term vision of Netscape/AOL-TimeWarner. By sticking to their guns, they can soon cut loose IE technology from their AOL software. It has been a gutsy move, and it appears to be paying off.
Stop the brainwash
i basically agree with all of this
ed edwards
No root to the box? A dozen known vulnerabilities left? That should pretty much render the root password useless. At least one of those vulnerabilities should get your root privs.
Smash a stack and edit the passwd file.
-- I'd say your post was about 3 monkeys, 18 minutes.
i basically agree with all of this
Nope. Pregnancy would imply sex with females. Not gonna happen in the open sores crowd.
I just wanted to point out that the conclusion states that Open Source software will have a lower bug rate than closed source software that was subjected only to feature testing (making sure that each feature works independently of the others). A lot of commercial software (such as what I work on) goes through a much more thorough testing cycle than that. I'd like to see a comparrison between such software and an open source project.
cubicle != cubical
cubicle Pronunciation Key (kyb-kl)
n.
A small compartment, as for work or study.
A small sleeping compartment, especially within a dormitory.
Moron.
Even so, they didn't set out to do it that way, did they?. Wasn't their hand was forced by the market drubbing they were taking?
How can we afford to ever sleep
So sound again
--ebtg
hi all... ... I have few BIG clarifications/doubts about the open source community .... .. who pays them ? Is everything a volunteering work ????
...
I am a newbie to the Open source community.. just started to closely watch the activites going on in the various Open source forums
* There are so many working in the open source projects
* how do they manage to put in so much effort apart from their regular job at some commercial company ? what is the driving force ?? interests in programming ? or not satisfied with their regular job? or is it do something to STOP microsoft !! i am really not clear about this !!
* how do they find time to do so much ?
* is the company they work for aware of the employee who is working for them spending so much time for some thing not useful to them !! (either during the work or after work !! )
I am sure lots of them reading this are people with deep roots in OPen source development
can clarify my doubts about the Open source !!!
It's much harder to produce a bug free graphical UI application than it is a daemon. Users can (and will) do a magnitude more things than you can receive on an open socket. When "talking" to a user, you will also need to give him a lot more functionality and a much more diverse interface (accessibility, keyboard navigation, mouse navigation) than you will ever need to give another application that's communicating with yours via a clearly defined protocol.
Well in the case of Apache, they have a huge ego and instead of responding to user requests, they ignore them (or say no) and instead try to push features nobody cares about. I suppose this sounds like flamebait but it is the truth...go read the apache lists sometime.
I'm sure others can do a better job explaining, but I'll try...
There are so many working in the open source projects .. who pays them ? Is everything a volunteering work ????
A lot (most?) of OSS is volunteer work. However, some businesses do pay people to develop for open source. I know IBM does, and I'm sure there are others.
how do they manage to put in so much effort apart from their regular job at some commercial company ? what is the driving force ?? interests in programming ? or not satisfied with their regular job? or is it do something to STOP microsoft !! i am really not clear about this !!
Everyone's drive is different. The little bit of OSS development that I've done started out as, "Why hasn't anybody done this? Guess I'll do it myself.". However, it soon turned into wanting to give back something to the community that has given so much to me. Some people do dislike MS enough to work against them. Others do it just because they want to develop and their regular jobs don't satisfy that need.
how do they find time to do so much ?
Ask them. For me, I usually spend an hour or so after supper doing either contract work when it comes my way, or developing to learn. Personally, development has become something of a hobby. I hardly watch TV anymore, partly because I sit and fidget because I find TV boring, and when I fidget, I get nasty glares from my fiance.
* is the company they work for aware of the employee who is working for them spending so much time for some thing not useful to them !! (either during the work or after work !! )
Again, ask them. For everyone its different. For me, I had to fill out a conflict of intrest form when I started getting contract work to do in my spare time. I work for the Government so I had to say I wouldn't use work time/materials on these contracts (nothing about posting to slashdot though).
Wow, FUD. According to our study we created to reach our preconcieved notion open source methods are superior.
Where to start?
Open source projects are generally quicker to respond to user requests.
I'm sorry but comparing two open source products to "commercial products" which is who? what product? what project? I don't see any quantative data besides a few lines refering to commercial products as a whole and saying the authors have experience with them is not scientific. I take exception to this because the paper sepcifically tries to appear scientific but yet offers no data comparing either project referenced (Apache and Mozilla) to a commercial counterpart or their ability to respond to bugs.
Open source projects tend to have a lower bug-rate than commercial projects
Again, where is the data? I see the scietific method they use for tracking bugs per line of code and they go into great detail comparing the two projects but yet we see no comparison to commercial project bug counts or the same method applied to commercial projects. The paper is laced with phrases such as "One might speculate". Yeah one might. Of course one might not speculate and offer evidence. If I create a hypothesis should I not have to back it up and test for truth?
And then there is the method of caculating bugs per line of code. They go into great detail about bug counts, when the fix was checked in, the lines of code, etc. But yet how do you measure importance? Some bugs are obviously greater than others. For instance, two teams create two identical applications. One application has 15 bugs and the other application has just 1. They both have the same lines of code, the same project size, same budget, everything is the same. The project with just one bug is obviously superior according to the methods they use, EXCEPT that particular bug allows a remote user to gain Root/Super User access. Which one has failed according to your quantitive data? Which project had the best method? They speak in depth about how this cannot be measured, then show you how they measured it?
Although I think this paper has good intentions and shows insight into some OSS projects,
1. The reference to commercial software as a whole is unfair and offers no value and
2. The method for caculating bugs is not an effective way to measure anything.
This paper is basically the equivilent of Microsoft, Oracle, Sun, or any other entity creating a study that never tests or proves anything and reaching a preconcieved notion. I can see this message being modded as a "troll" but oh well, this paper is not as scientific as it tries to appear.
"Open source projects tend to have a lower bug-rate than commercial projects"
True. But open source projects are much more precisely targetted, and less functional. Not necessarily in a bad way, but in a way that is very different from marketable commercial software.
Take, for example, IIS vs. Apache. On one hand, yes, Apache is so much better at serving web pages -- faster, more stable, more secure, cheaper etc. But functionally, they don't really do the same thing. IIS encapsulates ASP scripting, database access, file security, web serving, ftp serving, mail serving and a very powerful management interface. Apache is just a core web server. It performs one small task out of dozens, and as such the developers can concentrate on making that work best.
It's hard to do the same with commercial software. You have to keep adding features to stay ahead of the competition -- merely having the fastest webserver is not enough, because hype sells servers, not actual results. For this reason, there are a lot of open source projects that would never survive as viable market solutions. Apache's one of them...considering that "all it does" is serve pages and it relies on "third party" modules to do anything fancier than powerful URL rewrites and server side includes, its market price would be low and thus the margins. Never mind that it's stable as a rock while IIS is as insubstantial as a fart in the wind.
This is a big problem with the adoption of open source as well. You can't just "switch" like you can from, say, Word to WordPerfect. If you use SQL Server and enterprise manager, for example, you can't just "switch" to MySQL. MySQL has no totalitarian interface on par with enterprise manager. It has no massive searchable help database and no "for dummies" option for managing jobs and indexes. If you plug in to MySQL with a SQL Server only toolset, you're in for a shock learning curve, even if the databases themselves are on par with each other and MySQL less buggy. The difference is that what's important to the MySQL developers isn't what sells SQL Server.
Hey freaks: now you're ju
Apache has always been open source and has always been rock stable. Mozilla hasnt always been open source and hasnt always been stable and since becoming opensource it has become far more stable enough said!
Oh I see. If I remember my math correctly, Mozilla is chock full-o-bugs but its enormous code bloat offsets that and lowers the density. What a way to measure!
What do you think RedHat/Mandrake/SuSE/etc. do? They provide support!
If you buy an official distribution in the computer shop, you get support. You can grab the phone and... *gasp*... CALL them!
* There are so many working in the open source projects .. who pays them ? Is everything a volunteering work ????
Most members of open source projects are communists working to effect the downfall of capitalism. They live in communes funded by Fidel Castro around the world. There may even be one of these communes in your neighborhood - look for a ramshackle house with unkempt premises occupied by fair-skinned, over-weight men with long hair and beards. However, it is very rare to see a commune member outside during the daylight hours.
* how do they manage to put in so much effort apart from their regular job at some commercial company ? what is the driving force ?? interests in programming ? or not satisfied with their regular job? or is it do something to STOP microsoft !! i am really not clear about this !!
Being members of the commune precludes them from actually having real jobs. Of course, many of these so-called "developers" would never be able to get real software jobs due to the fact that they have no "skillz".
* how do they find time to do so much ?
Castro's scientists have concocted special drugs (chiefly a mix of amphetamines) which is given to the commune members at regular intervals. Given that these developers are able to work for 36-48 hours straight, it is a wonder they do not accomplish more.
80% of all statistics are made up
M@
Krispy Cream is people
Open source projects are generally quicker to respond to user requests
:)
I recently mailed the developer of SNMP_Session.pm for perl regarding a certain functionality I though he had missed and my suggestions for how to incorporate it.
A most friendly reply was forthcoming within 48 hours including an excellent little overview of lexical closures
I work for a large corporation and we could struggle to get service like that from the 'support' contracts we *pay* most vendors for...
A Linux distribution is far more complex than any MS release, and it really shows in terms of server use. As the article points out, projects like Mozilla aren't small, and can't be written by a 10-15 member core team. More modularity may help, but I think you will always have problems that are bigger than that. OSS is pretty new, and studies like this are few and far between at this point. Over time we will also learn how to manage and plan for bigger OSS projects.
It is also my position that most important OSS developers should be paid for their work. The core groups, particularly for big important project shouldn't be doing this by hacking all night in addition to their day job. The larger community is often applying the project, so making it work is just part of their job, but the core people are doing a full time job. Some jobs are compatible with doing almost full time OSS work, but we need more of this.
Is it just me or is this the driest most boring article ever written?
Kudos to the moderators for braving such a dangerously sleep-inducing piece of research for us mere mortals.
And in the end it just tells us that the Linux TCO is lower than the TCO for windows?
What time did you say the movie was?
Blearf. Blearf, I say.
In contrast, closed source development usually involves assigning people to projects. Their primary motivation isn't the software itself (which they will likely never use), but their job and their stock. Determining features involves a few people guessing hard about what features end users may or may not want. Oh, sure, they listen, but as anybody who has gathered requirements knows, users generally aren't very good at communicating what tradeoffs are important to them. And when closed source projects fail in the market, any new entrant has to start from scratch.
It's not surprising that open source development is winning in the long run. It's central planning (Microsoft, Apple) vs. a free market of ideas (open source) all over again. And we already have a good idea which of the two approaches of organizing large numbers of people around a common goal works better.
Sort of a different angle on the idea that OSS programmers go after the problems they are most interested in. When you're being paid, your employers desires will factor in, but it should be a lot easier to align your desires with an OSS project than the typical situation.
From WordNet (r) 1.7 [wn]:
cubical
adj : shaped like a cube [syn: {cubelike}, {cube-shaped}, {cubiform},
{cuboid}, {cuboidal}]
Stupid fuckwit.
Lovely! Now that you proved that the spelling is not an incorrectly spelled word, what word does your adjective modify?
Open Source projects tend to have less men with whips walking around your cubical head.
The above sentence would work as a grammatically correct sentence.
No, I think you are missing the point. Linux distributions are not quite there on the desktop yet. As a developer/admin, they are more than ready for me, and my English major wife because she has me to keep the systems running. I don't recomend it (yet) to my artist friends, even if they can't afford a Mac.
If you are willing to tinker a little bit and learn something about how systems work, then go for it, it is more than ready. BTW, if your not willing to do this, I wouldn't recomend tinkering under the hood of your Windows box either. And don't forget to back up your important files either even if you don't play with stuff.
Hey, necessity is the mother of invention. So they had to be beat up before they were willing to do it. Netscape should have been OSS all along, NCSA mozilla was.
So, they used Apache and Mozilla as their sampling of open source projects? Talk about biasing the study -- they picked 2 of the most well-known and "successful" projects of recent years, and extended their findings to all of open source.
Why not perform an arbitrary sampling of SourceForge projects, and compare with an equal number of commerical ventures? That would at least give an valid basis to examine the effectiveness of "open source" development and support.
Seems to me that the vast majority of projects on SourceForge are doomed by apathy and neglect, where at least a commercial project has a monetary incentive.
Matt Slot / Bitwise Operator / Ambrosia Software, Inc.
This study is bad because it only considers the two most successful open source projects.
p df
2 /0 6/05/1530208&mode=thread&tid=156
A more complete study of the top 100 most active projects on SourceForge comes to a completely different conclusion:
http://opensource.mit.edu/papers/krishnamurthy.
This different paper was discussed on Slashdot under the topic "Open Source Developed by Individuals, Not Large Groups", submitted on June 5, 2002. Here is the URL:
http://developers.slashdot.org/article.pl?sid=0
> Does anyone know of an online source for this study?
/. effect), & (4) I'm not sure my methodology is solid. But if _Peopleware_ demonstrated this fact before me, then I'm more comfortable describing this bit of research, since it confirms their discovery.
Well, in December of 2001 I compiled some figures to satisfy my curiousity about how long does it actually take to write reliable software, & I compared the time between releases of MS OS software -- Win 3.1 & its decendants as well as Win NT & its decendants -- with the time between releases of versions of Linux. I had expected that MS would be the winner in terms of time-to-market, but was surprised that Linux on average *was* faster.
For the product family from Win 3.1 to Win XP, MS required an average of 28.75 months, with a maximum of 41 months (between Win 3.1 & Win 95) & a minimum of 13 months (between Win ME & Win XP). For the product family from Win NT 3.1 to Win XP, the average time between releases was 24.75 months, the longest being between NT 4.0 & Win 2000, & the shortest was between NT 3.1 & 3.5.
In comparison, the average time between major releases of Linux was 20.5 months, the longest being between versions 2.2 & 2.4, the shortest was between versions 1.2 & 2.0.
I'll admit that after some thought I saw this was not entirely a fair comparison: the various Windows releases involved a much larger code base that incorporated far more functionality than the Linux kernel (e.g., a web browser & mail services), so I then compared the development cycles for two projects that maintain similarly more functional OSs: the Debian distribution of Linux, & FreeBSD. The results still showed that non-commercial software -- which was developed without a deadline set by management -- had at least as fast of development cycles.
Debian took 24 months to go from release 1.1 to 2.0 -- with an average time of 10.6 months between the minor (i.e. x.0, x.1, & x.2) releases. FreeBSD had an average time of 25 months between x.0 releases, but an average time of 18 months between new forks of the -STABLE & -CURRENT branches. (With FreeBSD I'm not sure which is a fairer way to measure cycles, but I would lean to the time between the new forks of the -STABLE & -CURRENT branches.)
The reason I haven't published this (& much of my work still remains in handwritten notes) because (1) I feel this is too good to be true for Open Source, (2) I'd like to examine non-commercial projects with a longer history (e.g. emacs or sendmail), (3) I would need a far more resilient web site to publish this on than my own personal one (gotta prepare for the
Geoff
I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
I had 3 slices of garlic bread. For lunch i had a pack of tic tacs :)
As reference above. If you have a team of 10 leading a team of 100 and the 10 are brilliant and the 100 are average what do you do ?
Fire the 100 give the money to the 10.
How motivated would you be if delivery means you get 10 times your current salary ?
An Eye for an Eye will make the whole world blind - Gandhi
So please submit bug reports for the documentation. You don't have to be a coder for that, or even know anything about how the software is supposed to work. If any part of the documentation is incorrect, out of date, unclear or even mis-spelled, that's a bug. Report it - politely :)
True, developers are often having too much fun coding, and it's hard to make yourself go to the documentation and keep it up to date. But a bug report can give you that little nudge to get it done. And the more specific the suggestions for improvement, the more everyone benefits.
-- What do you need?
-- Gnus. Lots of Gnus.
A master was asked the question, "What is the Way?" by a curious monk.
"It is right before your eyes," said the master.
"Why do I not see it for myself?"
"Because you are thinking of yourself."
"What about you: do you see it?"
"So long as you see double, saying `I don't', and `you do', and so
on, your eyes are clouded," said the master.
"When there is neither `I' nor `You', can one see it?"
"When there is neither `I' nor `You',
who is the one that wants to see it?"
- this post brought to you by the Automated Last Post Generator...