Open Source == Faster bug fixes

solar writes "SecurityPortal.com is running a comparsion between RedHat, Microsoft, and Sun Microsystems on the response time between software bugs being found and patch releases. Find out if open-source is the champion bug squasher we all believe it to be. " Interesting bit.

Comments

Cheating on bug fix times?

[zlexiss]

Sometimes I wonder how many closed source bugs have been known before the bulletin/news went public, with the fix withheld until there was a known "problem". Which can make the response time seem really nice if you're just holding onto the bugfix and releasing at the right moment.

And I'll still wonder what's with the legalese every bulletin has about "no known people being affected" by the security bug.

zlxiss

Re:Cheating on bug fix times?

[wrook]

When I worked at a certain telecommunications company, we always joked about this. Bellcore specified that you needed a 30 day turnaround time for 70% of the bugs that were reported by customers. The only way we could reach this target was by introducing bugs with known solutions. That way it would only take 21 days to fix it (14 days to get to the right department and 7 days to verify the bug fix).

Re:Why is this surprising?

[Tower]

Not to mention that Windows "security" has been notably poor about keeping people out of where they should be... you want to delete kernel32.dll or add some extra bytes to ifshlp.sys - it may ask you, are you sure, but it lets you do them... not too great.

2k is supposed to have some provisions for not allowing other random progs to overwite dll in system/system32 (which would be nice) - every random Joe Blow app should *NOT* replace system-wide dll s. Ever. Even MS Office (are you listening, chief of software architecture??

Imagine installing BitchX or XAmp and having them overwite parts of QTLibs, Xlibs, and why not, glibc... our versions *have* to be better, right?

Oh well...

Statistics tell all sorts of lies

[throx]

Don't be too quick to judge based on the statistics Security Focus gave:

Looking at their results, the time to fix 50% of the bugs is 4 days for Red Hat and 3 days for Microsoft.

After 1 day, Microsoft fixed 42% of their bugs. Red Hat only 29%.

I know I'll probably get moderated to hell for this, but the simple fact is the "average" statistic tells nothing at all. What the results seem to be saying is that Microsoft is faster on simple bugs (probably better distribution channels) though they fail on the more difficult bugs (probably more complex code, but who can tell without the source).

John Wiltshire

It's more subtle than this

[MattMann]

Their metrics don't measure what's important. Open source has two huge bug-related benefits:

• if you are a developer and something you are working on is not working, you can figure out why. you don't run into the problem of an unresponsive undocumented API. Look at all the crap MSDN-CD is full of, and how impossible it would be to get any work done without it, and how many little SDK idioms you need to resort to.
• if a bug you encounter is important to you, but "unimportant" to other people -- because it is obscure, or the software is no longer being supported... many possible reasons -- you can fix it yourself or hire someone to. you are not dead in the water.

Important bugs in important software will be fixed just about as quickly in either system: the 5 key people who know the source behave more or less the same way in open or closed source situations. It's the vastly larger number that matter to most developers. And, as more and more developers realize this and enjoy more working on open source, it won't matter what the other guys think.

Re:Speed != Quality

[cburley]

As far as speed goes, big deal... give me a fix that works.

Didja read the article? I know it was /.'ed -- I waited a longish time for it -- but it addressed the quality-of-fix issue pretty well.

BTW, while I don't know for sure whether you're right that many OSS projects don't regression-test such fixes first, I do know the ones I've worked on could stand some improvement...and also that it's a bit easier to regression-test a fix to a small component than a large one, and that OSS thrives on collections of small components in a way Closed Source $$$-making development doesn't (the latter favors the development of monoliths, since they represent a harder-to-reverse-engineer, and therefore steeper, wall for competitors to climb).

Also, the article made mention of various Microsoft-issued "fixes" that, themselves, had to be fixed. Didn't mention that happening with GCC, though it has happened there (not security fixes AFAIK, but the same principle applies), but the implication was that the most heavily-funded closed-source-development organization in the world doesn't seem to do to well producing correct fixes in the first place.

CmdrTaco is UNINTERESTED (Flaimbait -1)

[cruise]

Taco, How can you find this information interesting while refusing to release the slashdot source via CVS and following the OpenSource model which so many other applications use.

Your comment says "interesting" while you still remain uninterested in your user's demands to Open the /. source.

Slow /. bugfixes is more interesting perhaps?


They are a threat to free speech and must be silenced! - Andrea Chen

Slashdot Readers: The UNIX Philosophy

[Anonymous Coward]

I think I'd like to point Slashdot readers to a wonderful book: The UNIX Philosophy by Mike Gancarz. This book explains the tenets and values that traditional UNIX programmers have held. It goes on to list the 9 most primary tenets:

1. Small Is Beautiful
   • Software Engineering Made Easy
   • Small programs are easy to understand
   • Small programs are easy to maintain
   • Small programs consume fewer system resources
   • Small programs are easier to combine with other tools
2. Make Each Program Do One Thing Well
   • By focusing on a single task, a program can eliminate much extraneous code that often results in excess overhead, unnecessary complexity, and lack of flexibility.
3. Build a Prototype As Soon As Possible
   • The fact is, everyone is on a learning curve
   • Even the masters know that changes are inevitable
   • Why do you think they call it "software"?
   • Prototyping is a learning process
   • Early prototyping reduces risk
4. Choose Portability over Efficiency
   • Next ----'s hardware will run faster (fill in "quarter", "year", whatever)
   • Don't spend too much time making a program run faster
   • The most efficient way is rarely portable
   • Portable software also reduces the need for user training
   • Good programs never die--they are ported to new hardware platforms
5. Store Numerical Data in Flat ASCII Files
   • ASCII text is a common interchange format
   • ASCII text is easily read and edited
   • ASCII data files simplify the use of UNIX text tools
   • Increased portability overcomes lack of speed
   • The lack of speed is overcome by next year's machine
6. Use Software Leverage to Your Advantage
   • Good programmers write code; great programmers "borrow" good code
   • Avoid the not-invented-here syndrome (i.e. don't reinvent the wheel just because you didn't invent it first!)
   • Allow other people to use your code to leverage their own work
   • Automate everything
7. Use Shell Scripts to Increase Leverage and Portability
   • Shell scripts give you awesome leverage
   • Shell scripts leverage your time, too
   • Shell scripts are more portable than C
   • Resist the desire to rewrite shell scripts in C
8. Avoid Captive User Interfaces
   • CUIs assume that the user is human
   • CUI command parsers are often big and ugly to write
   • CUIs tend to adopt a "big is beautiful" approach
   • Programs having CUIs are hard to combine with other programs
   • CUIs do not scale well
   • Most important, CUIs do not take advantage of software leverage
9. Make Every Program a Filter
   • Every program written since the dawn of computing is a filter (it takes input data, and processes it somehow to possibly produce output)
   • Programs do not create data--people do
   • Computers convert data from one form to another

As you probably guessed, Open Source _pushes_ Tenet 6 to the forefront. Let others use your code!

Along with those primary, religiously-followed tenets, 10 lesser tenets are typically followed:

1. Allow the user to tailor the environment (Yeah! This is seen plenty in Unix user interfaces)
2. Make operating system kernels small and lightweight (OK, so Linux doesn't go to any extreme with this one...)
3. Use lower case and keep it short (well-known and practiced throughout; lowercase is easier to read)
4. Save trees (Why print out programs when you have less, gless, lynx, etc?)
5. Silence is golden (make program output good enough for humans to understand, but terse enough for other programs to use!)
6. Think parallel ("There is an old joke in the computer world that goes something like: if one woman can have a baby in nine months, does that mean that nine women can have a baby in one month?")
7. The sum of the parts is greater than the whole (use small tools to build big projects!)
8. Look for the 90 percent solution (don't exhaust yourself making it work in every nitpick situation)
9. Worse is better (think VHS vs. Beta; VHS sucks but it won!)
10. Think hierarchically

The book also mentions something very important: The Three Systems of Man. Software goes through the First system, the "innovative" cycle where one or only a few develop something revolutionary, to the Second system, where committees are formed for the software so more people can feel they're worth something contributing to the idea, and the Third system, where experts who left the scene during the 2nd stage come back to implement the idea, now that the obvious solution for it is well-known and has been walked many times.

CREDITS: This posting contains lots of quotations from, of course, the book: The UNIX Philosophy by Mike Gancarz, Copyright 1995 Butterworth-Heinemann. ISBN 1-55558-123-4 ... about $19.95. Well worth the money.

You people are ruthless! We're working on it!

[Kurt Gray]

Disclaimer: I work at Andover.Net.

People calm down. We have our best perl coders here slaving over the Slash release. Patrick, Rob, and Pater are trying to convert their undocumented code and database schema into something that can be installed on other machines besides this one. The Slash code really is hardcoded in many ways and they are trying to unhardcode it for you now now. But they very much appreciate your flames so please keep 'em coming. =)

Re:Open Source doesn't always == faster bug fixes

[finkployd]

there seems to be a rather vocal fundamentalist open source community here on /.

Yeah, I've noticed that too. It's funny, you get the same kind of thing on Freshmeat.net, with all these open source programs for download. Strange stuff.

These people generally cite certain prime examples to support their arguments.

And we all know THAT is a really dumb way to support arguements. Better to just yell and scream.

Although Linux is a stable and it's security holes are filled quickly,

This seems to be in direct contention with your subject.

I don't think that there are any hugely successful pieces of open source software

This one is way too easy. I'm starting to think this whole post is sarcastic and you actually support linux. Either way, find a more popular web server than Apache (suprise, open source). Seems PERL is pretty open, as is sendmail. I'm not sure what you mean by a monopoly when refering to the latter.

I don't work for free, I have to pay bills. Infact, I'm quite happy to be paid a lot of money for what I do.

Hey, we are all happy for you, now when are you going to get to the part about "Open Source doesn't always == faster bug fixes", or was this just a clever way to repeat the tired "open source cannot make money" monologue?

Finkployd


Bill Gates: "Innovation"

Speed != Quality

[Rombuu]

Sure, open source can get bug fixes out there faster... but its not like for most open source projects anyone is going out and regression testing the fixes against anything to make sure nothing else is broken by the fix, etc...

As far as speed goes, big deal... give me a fix that works.

Re:Open Source!=Redhat

[bero-rh]

Redhat is kinda slow at getting out the official fix. For example, the linux kernel is at 2.2.14 but Redhat has not put out a official rmp yet even though 2.2.14 contains a bunch of fixes

Red Hat has actually released several 2.2.14 RPMs in Raw Hide, our more experimental version. If you want to be on the bleeding edge, use that.

Also, check the source RPM for Red Hat's 2.2.13 kernel - it already contains a number of the fixes that later made it into the official 2.2.14 kernel.

We don't put out errata RPMs for every minor bug (misspelled man pages and such); this stuff gets fixed in Raw Hide and then makes it into the next release.

Errata RPMs are released only when they fix a MAJOR bug, such as a security problem (such as the bind update currently available) or a real functionality problem (such as the lynx update).
Releasing them for every minor problem, or every base version update, would be a bad idea because it would be very hard to keep track of everything. (And of course it would lead to "You need to update 1500 packages before Red Hat Linux works well" FUD from Microsoft and other people who don't care to check what an update does before writing flames).

Re:RedHat's response time

[bero-rh]

The fact that we're reading your message shows we're paying attention to the community. ;)
The thing that slows Red Hat errata down is called Quality Assurance. Bugfixed packages don't leave Red Hat without having run at least a couple of tests to verify

• the new package actually fixes the problem
  
• the package still does what it is supposed to do
  
• it doesn't introduce any new similar problems
  

I'd rather delay a package for a day than having to release yet another security update for the same package the next day...

Bumblebees flying AND:Poor research

[dpilot]

The assumption was that bee wings act like airplane wings. Uner those assumptions, a bee would not be able to fly. Somewhat more recently it was shown that bee wings do not work the same as airplane (or ornithoper) wings. Aside from the flapping thing, there's a basic modal difference.

Airplane and ornithopter (and bird?) wings work on laminar airflow. Try 'too hard' to fly, and you get turbulence above the wing. In other words, a stall.

The bee has a different method of dealing with this. Rather than prevent turbulence, the bee wing uses turbulence, and has a machanism for continually spinning the turbulent vortices off of the wing. In this flight mode, a given size wing has much as 50X more effective lift than in laminar mode.

I'm not sure we can apply this to the whole Linux vs Microsoft thing, other than to say that a new modality changes the whole landscape. But I guess that's what Open Source is all about. In this case, we're the bee.