Open Source Studies

Not to be obvious... by roachmotel3 · 2002-10-08 04:02 · Score: 2, Insightful

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.

Re:Not to be obvious... by gpinzone · 2002-10-08 04:43 · Score: 5, Insightful

It depends how you define successful. Yes, Apache and Mozilla are great products, but if there are so great, why aren't people dropping their closed source software and downloading their open source counterparts in droves? Hell, the two examples given are not only open source, but they're free!

Obviously it all can't be a success. How about the downsides? What about time to market? How long did Mozilla take to deliver a 1.0? What about lack of common features that customers want? (When I say customers, I mean the target audience as a whole, not just the geek community.)
Re:Not to be obvious... by Lazar+Dobrescu · 2002-10-08 05:03 · Score: 2, Insightful

As far as I can tell, people ARE downloading apache, and using it more than it's closed source counterparts...
Re:Not to be obvious... by timeOday · 2002-10-08 05:40 · Score: 5, Interesting

Yes, Apache and Mozilla are great products, but if there are so great, why aren't people dropping their closed source software and downloading their open source counterparts in droves? Hell, the two examples given are not only open source, but they're free!
Apache seems an odd example for you to cite. It's the #1 webserver on the planet - in other words, people *are* downloading it in droves. As for Mozilla, remember that its entrenched competitor is also "free."
Re:Not to be obvious... by 5KVGhost · 2002-10-08 05:47 · Score: 4, Insightful

OpenSource development is more successful because the people involved love what they're doing.

Unfortunately that implies a disadvantage, too: Things they don't love doing often don't get done at all.
Re:Not to be obvious... by AlienArtifact · 2002-10-08 06:12 · Score: 3, Insightful

I think there are several factors to consider when evaluating the adoption trends for open source software among businesses and organizations.
Quality: Many businesses make the assumption that commercial software is more rigorously developed and tested than open source software. The rationale here is that a commercial software vendor has an economic incentive to ensure quality and correct problems. There is also an expectation of accountability from an organization that exchanges products for currency.
Support: When investing in a mission critical software package, an organization wants to rely on the vendor to provide assistance and support that may be beyond the capabilities of its own staff. This is coupled with a desire for fast response to critical problems - if your company's livelihood depends on your webserver being up, you want to partner with a vendor that can deliver immediate service and support.
Integration: In today's computing landscape, software does not exist in isolation - software is expected to interface and collaborate with other packages and components that are part of the portfolio of an organization. Unfortunately, integrating diverse software components is a daunting and error-prone task. Organizations tend to favor vendors that provide installation and configuration support as well as consulting services geared toward integrating their products with the systems they already have deployed.
Maintainability: Organizations make software acquisition decisions based on the long-term. From their perspective, they want to invest in a "platform" that has long-term viability. This viewpoint is often associated with buying applications from an established vendor who they expect to be stable and viable enough to last the long-haul.
Usability: When a company makes a purchasing decision for a software package, one of the factors considered is whether the software is usable. This includes how easy it is to configure and maintain, the quality of the GUI (if any), the ease with which you can understand how the software operates, and so on. Open source software, is often viewed as being written "by hackers for hackers". In reality, open source software usually IS targeted to the upper echelon of software users, making it more difficult for organizations lacking highly experienced staff from being able to adequately deploy and use such software.
There are many other factors (both real and perceptual) that impact organization decision-making when it comes to open source software. Vendors tend to market their products to corporate decisions makers aggressively, whereas open source software does not. In many cases the merit of an software solutions is less important than the "relationship" between the IT decision makers and vendors. Not all organizations are aware of the wealth of open source solutions available to them in virtually all domains. And, clearly, if you don't know something exists you won't use it.
The reality is that much open source software meets the quality, support, integration, maintainability, and usability requirements that organizations demand. In many cases, open source software is actually better than the commercial alternatives. The free availability of source code makes it possible for the user community to find more of the potential problems and defects than in closed, black-box commercial alternatives. Skilled consumers can actually submit fixes to the community maintaining the open source solution making turn-around of bug fixes considerably faster. Open source software tends to be more compliant with other industry trends and open source alternatives, vs. the proprietary NIH (not invented here) mentality prevalent among large commercial software vendors.
This is not to say that open software doesn't have its downside. The availability of source code makes it possible for hackers to discover holes and back-doors more easily than with closed commercial software. Installation and configuration is often a tricky, complicated proposition. You can't get an SLA for an open source program. Maintaining, integrating an operating open source software often requires a higher class of user or IT professional than shrink-wrapped software.
Organizations need to learn to better recognize and weigh the benefits of open source against its downside. And while there is a place for both open source and commercial applications in the business environment, organizations need to overcome the "false" impressions they hold of open source software and leverage its benefit.
Re:Not to be obvious... by pmz · 2002-10-08 07:01 · Score: 2

...why aren't people dropping their closed source software and downloading their open source counterparts in droves?

People are switching to Open Source in droves. What is Apache's share of public web servers? Why are entire governments seriously considering using Open Source as a matter of national security and enabling democracy? Why are the people around me increasingly becoming agitated at ass-hole companies like Microsoft and looking towards alternatives?

What about time to market?

How is time to market relevant for Open Source software? Getting software released on a deadline implies that the released software is, by definition, immature and buggy. Not having a deadline means whatever is released was ready to be released. What does an Open Source software project have to lose by taking the amount of time really needed to do something right?

What about lack of common features that customers want?

What features are you referring to? Would the "target audience" really be better served by hard-core MS Office lock-in or undocumented private kernel APIs? What about extended communications protocols that dictate what type of server clients can connect to? Are these good things?

--
Healthcare article at Kuro5hin
Re:Not to be obvious... by Gerry+Gleason · 2002-10-08 07:27 · Score: 3, Interesting

Taking just Mozilla, since Apache is the most successful product in its category. Mozilla is only recently past 1.0, and the paper (if anyone read it, I just finished and I see over 100 comments) was analysing it before 1.0 came out. Nobody expects OSS development to be as fast as commercial, and it doesn't have to be. OSS is going to be much more concerned with quality, stability than artificially aggressive deadlines.
Also note the fast, and in some cases parallel development of derivative products. I don't have the details, but there are a host of 'Gekko' based browsers, and the direct spin-off Phenix is proceeding very fast indeed. People are reporting it to be useable and fast at the 0.2 release.
There is one issue to worry about (from the paper). One hypothesis is that if a project doesn't achieve critical mass, it won't get enough of a user following to get the many eyes effect. I suspect that this may be weakened by a number of factors. Even if a project doesn't acheive critical mass, it may be reworked in another form because the code is still available for experimentation.
Re:Not to be obvious... by Gerry+Gleason · 2002-10-08 07:31 · Score: 2

Unfortunately that implies a disadvantage, too: Things they don't love doing often don't get done at all.
I don't think this is true. There is always somebody that will find any given problem interesting. If not, it probably wasn't worth doing.
Examples to the contrary?
Re:Not to be obvious... by gmuslera · 2002-10-08 07:55 · Score: 2, Insightful

All right, so open source is used more for web serving and penguin downhill racing simulators. Anything else?
Most of internet infrastructure is open source based, not only web serving, think in DNS (bind most used DNS server, by far) or mail serving (sendmail, qmail, postfix are used by more than 50% of the mail servers, and probably each one of them is more used alone than the most sucessful closed source counterpart).
Re:Not to be obvious... by bolthole · 2002-10-08 12:01 · Score: 2

I don't think this is true. There is always somebody that will find any given problem interesting. If not, it probably wasn't worth doing.
So a free, fully functional word processor was not worth doing? for 10-20 years?
OpenOffice is the only fully functional one fitting the bill, and it is only open now, because someone PAID a lot of people a lot of money to write a non-free product, that then got re-released.
There was a clear and obvious need for one, for an extended period of time, but noone had enough interest (and time) to make it happen as a free software project. The closest stuff were things like "EZ" (from the Andrew project) which people "got by" on. their(the writers') need was filled, so it never progressed further.
Re:Not to be obvious... by Gerry+Gleason · 2002-10-08 13:06 · Score: 2

Oops, accidentially hit the "log out" link when I was trying to post.
Forgot this comment too. A word processor is a very big project, not a good choice unless you can get a lot of support. I'm way more interested in engineering tools anyway. How are we going to have free hardware designs if we don't have high quality free CAD tools and such. These are even more complex that word processors. It will take time, but I think as more people see the advantages of Open/Free Source as a development model, it will happen.
Re:Not to be obvious... by timeOday · 2002-10-08 14:03 · Score: 2

Apache is only #1 because Internet Information Server is not available on the operating systems run by the majority of web servers.
"Only"? That's one big advantage of open source, right there - platform independence. Once gcc is ported to a new platform, watch out.
If you look at the market where Apache and IIS compete, you see IIS with a near 90% marketshare while Apache struggles for second place against other servers like Xitami and WebSitePro/Visnetic.
Assuming I've chosen the Apache webserver (as most people do), why would I then spend money on a host OS unnecessarily?

of course 15 coders makes for less bugs by PissedOffGuy · 2002-10-08 04:02 · Score: 4, Insightful

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.

Re:of course 15 coders makes for less bugs by roachmotel3 · 2002-10-08 04:07 · Score: 4, Insightful

Do you really think that projects like Apache, OpenOffice, Mozilla, Xfree86, and Linux are less complex than say, IIS, Word, IE, or Win98?

I mean, seriously, if you look at functionality, things are getting very close between the OSS world and the Microsoft world.

I'm not saying that there are many straight forward OpenSource Projects, but let's be real -- there is a complete OpenSource O/S, that runs and performs amazingly given a core team of 15 people.
Re:of course 15 coders makes for less bugs by Tet · 2002-10-08 04:14 · Score: 5, Insightful

if these projects average 15 coders, on average they're also significantly less complex projects
If you think that many software projects need more than 15 coders, you obviously don't have much experience of software development. In all my years of software development, I've never seen a core team bigger than 10 people. Sure, Word may well have 150 developers working on it. But don't for one second believe they're all actively coding Word in one big team. Most will be working in smaller groups of 4 or 5 on one specific area (for example, the spell checker).

--
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Re:of course 15 coders makes for less bugs by Java+Pimp · 2002-10-08 04:19 · Score: 2, Informative

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.

In addition, a small number of developers makes for better communication among the developers. The projects don't neccessarily need to be less complex but with a small number of coders, each will have a better understanding of what the others are doing. Less misunderstanding of what another's code is supposed to do makes for less problems down the road.

--
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
Re:of course 15 coders makes for less bugs by JoeBuck · 2002-10-08 04:24 · Score: 2

There are very few proprietary projects that have more than 10-15 core coders, and when the projects are bigger, they get broken down into sub-projects of more manageable size.
Re:of course 15 coders makes for less bugs by gpinzone · 2002-10-08 04:48 · Score: 5, Insightful

Do you really think that projects like Apache, OpenOffice, Mozilla, Xfree86, and Linux are less complex than say, IIS, Word, IE, or Win98?

Yes. They are. Microsoft products don't just end at the product itself. They try to integrate their products into the OS. Internet Explorer just isn't a web browser. If it were, you'd never be able to have the level of security holes as it does. Without getting into a debate over whether or not it makes sense to integrate the browser into the OS, just realize that part of IE development is the OS development itself. On the whole, none of these projects are as complex.
Re:of course 15 coders makes for less bugs by schon · 2002-10-08 05:06 · Score: 2

What I mean is that if you want to run an open source web server, you use Apache

Not necessarily. In the case of X, this is (probably) true, but there are alternatives to Apache. Take Caudium, for example. It's a fully-featured GPL web server, that has pretty much every feature Apache has, and then some. It's easier to administer (especially for people familiar with point-and-click interfaces), faster, and scales better than Apache.

Apache is much more well known, and I wouldn't recommend changing if you already use it, but if you were starting from scratch, I'd highly recommend Caudium.
Re:of course 15 coders makes for less bugs by gpinzone · 2002-10-08 06:47 · Score: 2
Besides, integrating IE into Windows makes their development environment LESS complex -- it allows them to reuse code between pieces of software MUCH more efficiently. Your OS no longer needs software to display JPGs, GIFs, or to even browse the filesystem. Why, because the browser does it for you.

Two things:
1. It's more complex from a design perspective since you have to take into account not just the application at hand, but a whole slew of other apps that can share the same codebase that may have nothing to do with the Internet or web browsing, per se. By doing all that research up front, you do save time in coding. Meanwhile, Linux users are bickering over the GUI and whether it's a good idea to standardize KDE and Gnome.
2. Code reuse is a GOOD thing. Hmmm...add that one to the closed source software pile.
Re:of course 15 coders makes for less bugs by chris_mahan · 2002-10-08 07:17 · Score: 3, Interesting

I think that you make a good point:

The microsoft products are more complex.

The open-source products are less complex.

I'll have to agree with you on the complexity level.

However, this is most likely due to the microsoft vs unix way of doing things. In unix, a lot of little programs accomplish a lot together. In the MS world, a few monolithic programs accomplish a lot together.

So, taking program to program, the MS ones would be most complex, since they try to put everything and the kitchen sink in every single one of their flagship products.

And so, consequently, these monolithic multi-million code lines programs are more difficult to design, engineer, maintain, and debug.

But there are fewer of them, so more resources (programmers, program managers) can be assigned to each.

In the unix world, there are many more programs. And while each of these programs individually may be less complex, less encompassing in scope, and have fewer features, as a group they are able to outperform microsoft's systems.

Since each program is smaller and more easily defined in scope and requirements, then each program takes fewer programmers to design, implement, and maintain. As a result, it is possible for a smallish dedicated team to design, implement, and enhance a valuable and usable piece of software.

For example, I was surprised two years ago to find out that the core team of Postgresql is relatively small (currently the steering committee and major developers combine to less than 25 people) and yet it is no small feat.

For the unix world, the difficulty comes when there are a great many programs in use that have been developed over the years by different groups of people with different methodologies. These programs must work with each others, store their files in known locations, etc. This is especially important in linux, because there are so many more programs (including multiple guis) that need to share the same directory tree, and each have varying degrees of dependencies.

So the complexity still exists, it just falls outside of the program itself, and is rather a product of the environment.

Of course, having had my share of windows dll hell, I realize the problem of software dependencies is OS-agnostic.

----

I think I'll get back to work now... Is it lunch yet?

--
"Piter, too, is dead."
Re:of course 15 coders makes for less bugs by theLOUDroom · 2002-10-08 07:27 · Score: 2

Yeah, becuase no code resuse happens in the linux world.
Every heard of a library? Look into it. They exist on just about every OS. You'll find that they're used quite extensively on linux.
And what does the silly FUD about KDE and Gnome have to do with any of this? OMFG you a a choice about your desktop on linux! Do gas pumps with multiple nozzles freak you out too? Pepsi and Coke? Obsviously cola is in a sad state of affairs, because there is no standard brand, or standard container. Not to mention all these new drinks coming out. Some people like them, some don't....obviously the softdrink industy has entered some sort of death spiral.

--
Life is too short to proofread.
Re:of course 15 coders makes for less bugs by gpinzone · 2002-10-08 10:04 · Score: 2

Do gas pumps with multiple nozzles freak you out too? Pepsi and Coke?

Who was making silly generalizations? Whoa, maybe you really should proofread.

I'm an advanced user... by ajuda · 2002-10-08 04:04 · Score: 5, Funny

... and here is my bug sumission. It's spelled COMMERCIAL, not commersial I guess this submission was proprietary.

Re:I'm an advanced user... by unicron · 2002-10-08 04:58 · Score: 2

A friend of mine wrote a php driven webpage system(thcnet.net) that has a built in spell-checker. If you mispell the word, in the preview window the word itself becomes a link to that word under dictionary.com. Oh well, slashdot does have pretty graphics.

--
Finally, math books without any of that base 6 crap in them.

Not just open source by aengblom · 2002-10-08 04:06 · Score: 5, Insightful

"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

Primary Difference by Anonymous Coward · 2002-10-08 04:07 · Score: 3, Funny

Open Source projects tend to have less men with whips walking around your cubical.

"We are slaves."

It coule be better by bsharitt · 2002-10-08 04:08 · Score: 4, Insightful

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.

Re:It coule be better by JoeBuck · 2002-10-08 04:12 · Score: 5, Informative

For some of the best-known free software projects, particularly the Linux kernel and GCC, most of the core coders are paid to work on free software, either full-time or part-time.
Re:It coule be better by ChaosDiscord · 2002-10-08 04:23 · Score: 2

I bet most open source projects would be better if the 10-15 core coders were paid as full time employees.

Most open source projects would be even better than that if an infinite number of magical gnomes worked on the project full time.
Yes, it would be nice if more open source coders were paid for their work, but making do with what we have is a hallmark of open source hacking.

--
Search 2010 Gen Con events
Re:It coule be better by hyperturbopete · 2002-10-08 04:24 · Score: 2, Insightful

actually thats an interesting observation.

The core team is 10-15 people who arent even full time! wow :-)

A lot of companies are realizing (or should realize), though, that its a great deal to pay one of their employees (or contract out) to take an OSS project which is almost-right-for-them, and add the last 10% of missing functionality, etc. If they play their cards right, their one developer can leverage all the volunteer expertise out there and work with a huge part-time team backing him.

This can be better than paying for 100% of a commercial alternative.

Thus, many of the more focused OSS developers are actually on someone's payroll.

-peter

--
SUV's support terrorism !
Re:It coule be better by Jeppe+Salvesen · 2002-10-08 04:27 · Score: 2

When you are paid to do something, the one who pays usually at some point will feel that pressuring you to become more productive is justified by your paycheck. Rushes for deadlines leads to bugs.

That being said, usability could be better in some projects. I don't think paying the developers would pay off at all - you would rather need a clean application design and let GUI-oriented people deal with the user interaction. In Apache, it is not a problem. In Mozilla, I believe that is exactly what has been done (though I could be wrong..)

--
Stop the brainwash
Re:It coule be better by Soko · 2002-10-08 05:26 · Score: 4, Interesting

Does this make business sense? In a word,

Yes.

Paying people to work on an OSS project is strategic for any business for the following reasons:

1. You get in on the ground floor. If your competitors have core developers on an important Open Source project, you are at a disadvantage. They will have intimate knowledge of the product, since they helped generate the source code. You, on the other hand will have to read and decode the source. You then spend more time - and $ - getting up to speed in supporting your end users. Having a core developer means you're that much closer to the information you need.

2. Standards compliance. If you and 2 or 3 of your competitors are all working on an OSS product, it will become a standard, since everyone has to agree on the functionality of the package. It is impossible to do otherwise. Basically, you all agree to detente - you permenately remove a weapon from the arsenal. This stops an expensive "arms race", and also means less things to worry about and/or reverse engineer. Interoperability is assured then, so it means $ can be spent in more constructive ways.

3. Wealth of focused resources. A compelling Open Source product will attract the brightest users who have a vested interest in your product. The quality of bug reports usually is better and more diverse. For that matter, the coders outside of your organisation also will have a vested interest in your product, since they aren't motivated by getting paid to submit changes and bug fixes. This means development is focused on getting the right product in user's hands - not what marketing thinks is the right stuff. The feedback loop from the field is much better. Less $ wasted on dead end products, or going down the wrong development path.

4. Marketing. If your organisation starts an OSS project and keeps/pays the lead developers, your name is attached to it, even if others contribute to the code. Everyone knows that JFS is and IBM product, as well that XFS is an SGI product. They just happen to be OpenSource. This doesn't result in tangeable $, but other things that can lead to more $ - like goodwill from the development community, end users and sometimes even (gasp!) your competition.

5. Undercutting the competition. If your OSS project provides the same funtionality as a competitors closed source product at the same quality level (most indications state quality will be above Closed Source), you've effectively removed most of the reasons that your competitions product will be bought. If you're paying 2 developers and have 10 other regularily contributing code an OSS product under the GPL, but a competing product needs 20 developers to code (and untold others to support the product and the codrs too), well the math is easy. Cut throat, but effective business strategy.

There are likely many other benefits that come from "owning" OSS code, but I'll stop here for brevities sake.

Soko

P.S. - I haven't listed the downsides, since we, unh, know there aren't any /sarcasm ;-)

--
"Depression is merely anger without enthusiasm." - Anonymous
Re:It coule be better by Evan · 2002-10-08 06:35 · Score: 3, Informative

Lest anyone think that you're full of theory, here's a concrete example: Zope Corporation and the Zope application server.

Quick background: ZC wrote Zope, released it under a GPL-compatible license, and makes money from large (>$100,000) contracts to build applications using Zope.

1. ZC's engineers know the code better than anyone else, giving them an edge over other contractors who do Zope.

2. There are no direct competitors involved, but customers and community members alike ensure that Zope supports standards (WebDAV, XMLRPC, etc).

3. Several major features of Zope were developed by community members, then adopted into the core. This led directly to some of the authors joining the company.

4. ZC was originally Digital Creations, Inc. They finally changed their name because the association was so valuable. Most of the community called the company "Zope" already anyhow .

5. The fact that every single dollar of a contract with ZC is spent on custom development, and none on licences, is a *huge* marketing advatage.

6. If ZC hadn't made Zope Free, they would never have been able to compete with the likes of BEA and Vignette. The Zope community, and the fact that Zope solutions don't depend on ZC for maintenance, put Zope in a league that no penny-ante proprietary startup could reach.

Mirror by rgbrenner · 2002-10-08 04:09 · Score: 2, Informative

ALR-2002-003-paper.pdf

Complexity != number of coders by MosesJones · 2002-10-08 04:12 · Score: 5, Insightful

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

Re:Complexity != number of coders by plalonde2 · 2002-10-08 04:24 · Score: 2, Insightful

I disagree that open source is the best way to run a paid project. Not because the open source model doesn't work, but because it's hard enough to find and retain a core of 10-15 highly motivated, highly talented people; but to keep them interested on payroll to set deadlines is darned near impossible.
Open source developpers don't have the business constraints of hard deadline, make their own hours and release dates and take serious breaks off their projects.
Fundamentally, businesses need to manage their risk, deadlines, and content, in a much tighter way than open source projects allow.

PDF alert! by Draoi · 2002-10-08 04:12 · Score: 4, Informative

That link points to a pdf file. Pity the /. troll link filter doesn't catch pdf's.

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

Re:PDF alert! by Draoi · 2002-10-08 04:43 · Score: 2

Hehe. Good ol' Adobe - and they own the PDF standard. You'd think they'd be the ones to get it right. Someone needs to tell them about Google ....

--
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Re:PDF alert! by bogie · 2002-10-08 05:03 · Score: 2, Insightful

Meh, this isn't 1996. We all can read pdf files on our Linux boxes. While html is always preferred for links, there is no need to call the file a "troll link".

--
If you wanna get rich, you know that payback is a bitch
Re:PDF alert! by Draoi · 2002-10-08 05:06 · Score: 2

Where'd I call it a 'troll link'?? Re-read.
The problem I have with stealth PDFs is that they're massive & I happen to be on an analog dialup most of the time. Why doesn't Taco modify the lameness filter to also include the main stories, eh?

--
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Re:PDF alert! by bogie · 2002-10-08 05:24 · Score: 2

Oh so now I'm a troll eh? Whatever.

My point is valid. All linux distros ship with tools to read pdf files. They have now for several years.

But feel free to mod me down again you won't make a dent.

--
If you wanna get rich, you know that payback is a bitch
Re:PDF alert! by Draoi · 2002-10-08 07:34 · Score: 2

They're only "massive" if you're trying to save-as. All modern webservers page-serve PDF's.
Not quite. This one doesn't & happens to be the one that I use, so there goes that theory. My alternatives include IE and Lynx, so go take yer pick ....

--
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Re:PDF alert! by Draoi · 2002-10-08 07:47 · Score: 2

Fine and good if I happened to live in America. Thanks for playing, try again ....

--
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein

OSS as an alternative by OmniVector · 2002-10-08 04:12 · Score: 5, Insightful

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

Re:OSS as an alternative by Anonymous Coward · 2002-10-08 04:28 · Score: 2, Insightful

Well, gee, when last have you phoned Microsoft for tech support? Probably never. So, what exactly is different with OSS tech support?
Re:OSS as an alternative by michaelggreer · 2002-10-08 04:49 · Score: 2, Insightful

Actually, my experience with OSS support has been tons better than commercial software. I can email the developers, who often respond in minutes with an answer. Also, I do not need to navigate some support labrynth just to see the mailing list of questions, or the FAQ. Commercial apps have little on OSS, from my experience. The best source for debugging Weblogic problems is not sitting on the phone for 2 hours, but going to the mailing lists, like an OSS project.
Re:OSS as an alternative by grumpygrodyguy · 2002-10-08 05:17 · Score: 3, Insightful

Actually, my experience with OSS support has been tons better than commercial software. I can email the developers, who often respond in minutes with an answer.

No no, I think you're missing the point. You're already "inside" the Linux community, he's talking about the other 99.99% of the human population. The issue here is useability.

He's not asking how to tweak the source code to get something to compile...he's asking what your mother would ask, what your father would ask, what your brother or sister would ask, and probably what almost everyone living on your street would ask. How can I get my soundcard to work in Linux?

OSS devs are the worst people to ask for help. When you say computers or Linux they start visualizing C code, and talking editors and compilers...they are someplace else entirely. I'm no fan of Microsoft, or AOL...but the main reason why they are successful is not because they sell a better product, but because they sell a product that people can actually use.

--
The government has a defect: it's potentially democratic. Corporations have no defect: they're pure tyrannies. -Chomsky
Re:OSS as an alternative by iabervon · 2002-10-08 06:22 · Score: 4, Insightful

I've relied much on my friends who have used linux to help me get my system running

But that has to be included in the support for OSS. In fact, that's the only kind of support that most people get with just about anything technology-related. Furthermore, it's the best support, because the person actually knows you, and both understands what you're saying and cares that you get it working. With commercial software, you often have to deal with people who don't care if your problem gets solved, so long as they get paid; furthermore, it's much harder to find someone who can actually fix something that's broken.

Customizability and ease of use are not actually in opposition at all; you just need to have the defaults set right. Each new option which gets set, by default, by looking at your usage, improves both ease of use and customizability. Local compilation doesn't make things more difficult, because it can be done without any interaction; there's no reason that, when you download a binary and install it, the system couldn't download the source and compile it in the background, and then replace the binary installation with the compiled one. In fact, compiling a program locally is much likely to work than using a precompiled binary, and compiling most programs doesn't take as long as reading their documentation on recent hardware.

BTW, the unacceptably-slow Linux installation took less time than Windows ever has.
Re:OSS as an alternative by dh003i · 2002-10-08 17:21 · Score: 2

Firstly, support on newsgroups, forums, odcs, manuals, google, etc, is not compulsory. No one has to help you.

But many people do. And the help they provide is very superior to that offered by standard support services. They tell you how to fix something, how to do what YOU want. They don't tell you, "oh, well what did you install last? uninstall that. That didn't work? Ok, reinstall the entire OS".

Standard support services (like the support you receive upon buying MS windows) only support you if you pretty much stick with the defaults, and their solutions are always something that's blatantly obvious yet unnecessary. I.e., uninstalling entire programs to resolve a conflict rather than getting to the bottom of that conflict and fixing it.

As someone who uses WinME for my gaming OS, I'll tell you that every time I've called technical support, I've talked to idiots. I know more than anyone I've ever talked to on technical support. They obviously don't know what the fuck they're talking about, and just read from a cookbook. Oh, you can't get your sound-card working even after trying all these steps proscribed, so the only other thing we're authorized to do is make you reinstall the OS.

Also, if call-up support is so important to you, you can purchase it. Though if you have any brains about you, you'll know everything that any "technical support" service will tell you.

--
social sciences can never use experience to verify their statemen

Conflict? by lseltzer · 2002-10-08 04:12 · Score: 5, Interesting

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.

Re:Conflict? by Salamander · 2002-10-08 04:45 · Score: 2

What on Earth makes you think that an author's involvement with the subject of a study is likely to make them more objective?

--
Slashdot - News for Herds. Stuff that Splatters.

Still Lags by Pave+Low · 2002-10-08 04:13 · Score: 2, Insightful

While Open Source can make for cool code for the cool apps, it still lags far behind the big boys when it comes to the most mundane things, copy-n-paste, fonts, printing, etc.

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.

not always... by *xpenguin* · 2002-10-08 04:16 · Score: 2

Open source projects are generally quicker to respond to user requests.

Oh, please stop making me feel bad.

Re:not always... by *xpenguin* · 2002-10-08 04:59 · Score: 2

No, my point was that I write open source software and never respond to user requests.

Much like closed source by mikewas · 2002-10-08 04:18 · Score: 5, Insightful

The number of developers that are actually contributing seems much like the commercial closed-source projects I've worked on. There's always a small team that really understands the code that does most of the work. The core tends to be about half of the team on small projects. Everybody else performs ancillary functions or just goofs off. On larger projects communication breaks down and the core is limited to a no more than a few subgroups of one to 7 developers each. The subgroups tend to work independently, only occasionally interacting with one another -- usually though some spokesman or leader.

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

Re:Much like closed source by brad-x · 2002-10-08 04:38 · Score: 2, Insightful

One would hope that the situation surrounding 'goof offs' doesn't exist in the open source world; although I'm sure they equate with developers who work for a while and then lose interest in the project. I can't imagine such people would stick around for long, in any event.

Although this would explain a lot about Mozilla.. :P

--
// -- http://www.BRAD-X.com/ -- //
Re:Much like closed source by mikewas · 2002-10-08 05:40 · Score: 2

What really amazes me is that the goof-offs exist in the commercial world. After all, for open-source you can just ignore them. But on commercial projects somebody is actually paying them so the goof-offs are displacing somebody who might actually be a useful contributer!
I once spent months getting a goof-off off of my team. After demonstrating that he had failed to actually do anything for 3 months, that he couldn't even turn the product on & make it work, he just got reassigned to another project. PHB's words: "I made sure I didn't hurt his feelings."

--

"Glory is fleeting, but obscurity is forever." --Napoleon Bonaparte
Re:Much like closed source by Observer · 2002-10-08 08:10 · Score: 2

The number of developers that are actually contributing seems much like the commercial closed-source projects I've worked on. ...
This is one of the few /.comments moderated up to +5 Insightful that fully deserves the ranking, imho. I'd add just one observation from my own experience of over 25 years programming for my living: if you've got a project of any sort of complexity, then for it to deliver a usable result on schedule then there needs to be just one person whose decisions on tricky questions are final and accepted by the rest of the project. (S)he may operate as a benevolent dictator, or be imposed from outside and be initially resented until it's clear that the decisions are, on the whole, pushing the project in the right direction, or even be someone who holds no formal directive role but whose 'suggestions' are never ignored - but some sort of deadlock-breaker is essential.

Google HTML version by kisrael · 2002-10-08 04:18 · Score: 4, Informative

HTML version via since the original is slashdotted and a PDF anyway.

--
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death

What About OSS Failures? by theduck · 2002-10-08 04:19 · Score: 5, Insightful

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

Re:What About OSS Failures? by FortKnox · 2002-10-08 04:34 · Score: 2, Insightful

Not only that, but I'd like to see projects that have deadlines that HAVE to be met, as opposed to your hobby code that's finished when its finished.

--
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Re:What About OSS Failures? by zericm · 2002-10-08 05:27 · Score: 3, Interesting

Not only that, but I'd like to see projects that have deadlines that HAVE to be met, as opposed to your hobby code that's finished when its finished.

I'm working on a closed source project -- a vendor product with a huge amount of customized code -- that has some hard deadlines: first release for testing by mid-August; pilot by mid-September; general release by November 1. Except that we ran into problems getting the team up to speed, so we cut the scope of the project, and decided to skip the august release. And then we ran into more delay and we moved the pilot to the end of September. Then we decided to push the pilot to mid-October. Now we are skipping the pilot and going straight to general release in November.

I can hardly wait for the cries of incompetence, but I respond with the real-world: lay-offs happen. Or key people get new jobs. Or reorgs interfere. Or the business users change the scope (find me a company where business users are ignored). I have as yet to see a plan that accounts for all of these items.

I've worked in large corporations since 1993, as both a programmer and tech lead, with mature and immature development teams. Development is about negotiation. Dates and deliverables are constantly re-evaluated. If a project date can slip then it will slip. If the date is hard, then the scope is cut. In other words, closed source projects are finished when they are finished.

--
The welfare of the people has always been the alibi of tyrants. - Albert Camus
Re:What About OSS Failures? by schon · 2002-10-08 05:29 · Score: 2

I'd like to see projects that have deadlines that HAVE to be met

What happens when you have a closed source software deadline that HAS to be met?

You get Windows 95.
Re:What About OSS Failures? by FooBarWidget · 2002-10-08 08:21 · Score: 2

But still no match to Unix in the high-end server market.
Re:What About OSS Failures? by kubrick · 2002-10-08 14:58 · Score: 2

What happens when you have a closed source software deadline that HAS to be met?

You get Windows 95.

Not a great example to choose, as for a couple of years beforehand Microsoft were touting how great their update to Windows, formerly codenamed 'Chicago' and now called 'Windows 94', was going to be. :)

Aimed at releasing late 1994, actually launched in July 1995.

--
deus does not exist but if he does

Up to old tricks by gnovos · 2002-10-08 04:20 · Score: 5, Insightful

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

Re:Up to old tricks by schon · 2002-10-08 05:13 · Score: 2

this kind of approach to building is a fudamentally old way of getting the job done.

True, however you missed the first bit of that sentence.

It is often characterized as a fundamentally new way to develop software

Which basically means "this is how others see it", not "this is how we see it."

They didn't say that it was a new way to do things, but that others percieve it as a new way to do things.
Re:Up to old tricks by Gerry+Gleason · 2002-10-08 08:57 · Score: 2

GPL is new since the Homebrew era. Sharing in the public domain can be dangerous, but with GPL your competitor can't take it private.
Some of us actually built our first computers from bags of 74xx chips with a soldering iron.

Open source projects tend to have a lower bug-rate by vlad_petric · 2002-10-08 04:26 · Score: 3, Troll

I quite agree for Apache, but Mozilla ?? Let's stay in the realm of reason.

The Raven

--

The Raven

One thing the report forgot to mention ... by Taco+Cowboy · 2002-10-08 04:26 · Score: 4, Insightful

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 ... With Open Source, we can.

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 !

AOLserver by yerricde · 2002-10-08 04:30 · Score: 2

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

"Don't confuse me with facts..." by dpbsmith · 2002-10-08 04:38 · Score: 5, Informative

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!

Re:Open source projects tend to have a lower bug-r by dhogaza · 2002-10-08 04:42 · Score: 5, Informative

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

critical mass most important element by truth_revealed · 2002-10-08 04:44 · Score: 3, Insightful

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?

Structure... by ackthpt · 2002-10-08 04:54 · Score: 2, Funny

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

It's all about the QA! by rockmuelle · 2002-10-08 05:00 · Score: 2, Insightful

"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

Re:It's all about the QA! by grumpygrodyguy · 2002-10-08 05:43 · Score: 3, Interesting

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.

Yes, but on the flipside OS software is like a box of chocolates, you never know what you're going to get.

Without reliability, business won't endorse open source software. So what ends up happening is you have hundreds of so-called "advanced users" who are basically hobbiests with a sense of adventure spending thier time using faulty software...so that eventually the rest of us will get a useful product. Sure it's thorough, and the bugs do get found...but there are side-effects to this.

For a lot of us who were using Mozilla in the beta stages, it was a complete mess. I remember one bug that was just so rediculous it rendered the entire browswer unusable. As I recall the only way to type a URL into the browser address window was to doubleclick on the text, and hold down the mouse while typing the URL. It was maddening and I stopped using it after a few days. The bug was addressed, and fixed in the next version. But it wasn't for another 8 months(long after the 1.0 release) that I picked up and tried mozilla again.

The point is, I wanted a web browser, not an adventure. Most users want things they can trust. They want working e-mail, office applications, web browsers, etc. Businesses are even more fickle about this. In a business environment software has to be reliable or it could end up costing millions, there is just no room for "software speculation".

OSS projects like Apache and the Linux kernel are stable because they have enjoyed years of meticulous care. I say care because in those cases the user and the developer were the same person. But where are you going to find daring OSS beta-testers for office applications and enterprise level software? These are products that need to work now. 5 years of screw-ups may produce a good product in the end...but most companies can't afford those 5 years.

--
The government has a defect: it's potentially democratic. Corporations have no defect: they're pure tyrannies. -Chomsky
Re:It's all about the QA! by Zathrus · 2002-10-08 06:17 · Score: 3, Interesting

You're a new coder, aren't you?

In most industries the QA department is a joke. A really bad one. QA is the last thing budgeted and the first thing cut -- because when you have a deadline to hit management always thinks that QA is superfluous. I've heard VP's state that it's better to have a buggy product out than no product at all. And the VP in question really didn't care just how buggy it was. With that kind of attitude toward release quality QA can be viewed as nothing but an impediment to getting product out (and, to be fair, some QA departments do view that as their job - preventing anything from being released). So some QA departments just rubber stamp things instead of doing real testing.

On top of that getting good QA people is extremely difficult. A good QA tester has to have enough technical expertise to design test programs, methods, and sets themselves (having the coders do this defeats the purpose of QA), but doesn't want to be a coder fulltime. That particular combination of abilities and desires is very rare indeed.

Finally, and perhaps worst of all, a good QA department is invisible. If QA has done their job then there will be minimal complaints from end users -- sure, there will be issues, but nothing huge. When you never have any huge problems, management tends to forget that it was QA that caught those huge problems before the product shipped.

Where does QA work? Usually in industries like Aerospace, Medical, telecomm, and power generation -- industries which don't have a margin for error. They have decades old QA practices that often got instituted the hard way. They also have relatively little competition and insanely high development costs.

Frankly, OSS does a far better job of QA than most closed shops, because the QA team is not paid by the same company/group developing the software. So there's no incentive to not report a bug, but there's also no incentive to block release -- if a major bug is revealed then Joe Blow user isn't going to get fired for failing to find it.

Oh, I'm sure you won't agree with me. Get another decade or so of experience in the real world and I suspect that you'll think differently.
Re:It's all about the QA! by jazman_777 · 2002-10-08 06:54 · Score: 2, Funny

to be fair, some QA departments do view that as their job - preventing anything from being released
And to be fair, with some products, that's a good thing.

--
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Re:It's all about the QA! by Gerry+Gleason · 2002-10-08 08:04 · Score: 2

Excellent points, but I want to make an additional one about QA.
Where does QA work? Usually in industries like Aerospace, Medical, telecomm, and power generation -- industries which don't have a margin for error. They have decades old QA practices that often got instituted the hard way. They also have relatively little competition and insanely high development costs.
IMHO, these are areas of software development that could benefit most from the OSS model. At first glance it would seem to be hard to get a large enough user community to achieve critical mass, but that would miss an important fact about quality. It is a much larger concern of the user community, even in niche markets. In particular niches, the user quality requirements can drive the whole process. If they supported OSS instead of spending a fortune with a closed source vendor, then they would have the access and control to get the quality they require without spending as much money. Why? Because those costs are shared across the industry instead of being concentrated at the vendor.

Re:So what can MS do to respond? by ites · 2002-10-08 05:13 · Score: 2

Read my rant about Ites' Law below. It might give you some ideas about Microsoft's plans.

--
Sig for sale or rent. One previous user. Inquire within.

Mozilla succeeded through persistance and vision by Jeppe+Salvesen · 2002-10-08 05:25 · Score: 2

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

Re:So what can MS do to respond? by dstone · 2002-10-08 06:06 · Score: 2

I am sure MS must be coming to the conclusion that an open development model is better.

With 50,000 employees to draw from and no downsizing in sight, it may not be critical that MS get the most productivity out of their employees. "Productivity" was the point of this study. That's not necessarily the ultimate goal of MS. In fact, it's most certainly not. When Ballmer reports to his shareholders, he wants to say "we were most profitable", not "we were most productive". Short-sighted? Perhaps. But perhaps not in their market-share position. Anyways, my point is that MS is likely still convinced that their closed-source practices keep them immensely profitable. Now if you can find a study that shows open source practices are more profitable than Microsoft's current practices, then you might be on to something...

Re:Open source projects tend to have a lower bug-r by SashaM · 2002-10-08 06:40 · Score: 2, Insightful

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.

Re:Someone Please clarify!!!! by Nos. · 2002-10-08 06:48 · Score: 2, Informative

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

FUD by e2d2 · 2002-10-08 06:54 · Score: 5, Insightful

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.

Lower bug rate kind of a red herring by dasmegabyte · 2002-10-08 06:57 · Score: 5, Insightful

"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

Re:Lower bug rate kind of a red herring by dasmegabyte · 2002-10-09 11:28 · Score: 2

Yeah, but that's the problem. There's a handful of developers working in opposite directions on the same theoretical piece. Sure, it's choice...but it means that each progresses slower than if there was a unified push. Furthermore, when time comes to release the package, there are too many choices. How many text editors are there in the default package of linux, each with its own interface and able to do the same things as the others? It's very daunting for the switcher, who's used to one way of doing things, to be presented with a list of five with no "best of breed" winner. I mean, shit, WordPerfect used to have a "Switching from Word" mode, in which access and function keys and toolbar positions were remapped to help ease the transition. I can't even figure out what most of the mysql admin apps are doing or how they expect me to use my computer. Which is, of course, where postgres' pgadmin2 gets it right. It's very similar to enterprise manager...in fact, it's actually easier to use.

Oh, and MS' SQL management system isn't totally closed. We have people who use other apps to admin it, including some GPL stuff written in Perl. But none of that comes even close to the power of enterprise manager, so we stick anybody who can be trusted not to truncate sysobjects behind the wheel of E.M.

--
Hey freaks: now you're ju

Open Source != no phone support by FooBarWidget · 2002-10-08 06:59 · Score: 2

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!

Numbers make me crazy by msheppard · 2002-10-08 07:18 · Score: 2

80% of all statistics are made up

M@

--
Krispy Cream is people

It's called modularity by Gerry+Gleason · 2002-10-08 07:52 · Score: 2

MS products are buggy and insecure as hell, and I'm certain, without looking at the code, that they are complex in an intractible way that contributes little to functionality. Sure, they can get market driven features shoehorned into the product at a amazing rate, but it all leads to doom because it is unmaintainable. It also takes legions of engineers who are constantly made unhappy by the ugliness of their work.

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.

applying free market principles to software dev by g4dget · 2002-10-08 08:17 · Score: 3, Insightful

Open source is really in many ways what happens when you apply free market principles to software development: people participate, and their contributions survive, based on actual needs, capabilities, and quality. If open source projects fail to meet the needs of their users, they split, and some branch will adapt, but without throwing everything away.

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.

Scratch that itch by Gerry+Gleason · 2002-10-08 08:23 · Score: 2

A lot of companies are realizing (or should realize), though, that its a great deal to pay one of their employees (or contract out) to take an OSS project which is almost-right-for-them, and add the last 10% of missing functionality, etc. If they play their cards right, their one developer can leverage all the volunteer expertise out there and work with a huge part-time team backing him.

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.

Linux != OSS by Gerry+Gleason · 2002-10-08 08:35 · Score: 2

No no, I think you're missing the point. You're already "inside" the Linux community, he's talking about the other 99.99% of the human population. The issue here is useability.

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.

Re:Mozilla succeeded through persistance and visio by Gerry+Gleason · 2002-10-08 08:54 · Score: 2

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.

Not the Study Wanted, but My Own Research by llywrch · 2002-10-08 10:12 · Score: 2

> Does anyone know of an online source for this study?

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

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

Again get to the bible... by MosesJones · 2002-10-08 20:50 · Score: 2

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

Documentation bug reports by Peter+Harris · 2002-10-08 20:52 · Score: 2

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.

100 of 215 comments (clear)