Open source still the best way to develop software

Can we trust Fortify

It's amazing how many bloggers report Fortify's study without verification. the guys at osourcemobile.com have done a fantastic job in two articles about Fortify's study. Read the first article here.

There is a follow-up article on the same site

If many eyes are so good then:

Why do Commercial Vendors consonantly innovate new products while OpenSource regurgitates existing products? (Name some products that OpenSource invented without a successful commercial predecessor)

Why do Commercial Vendors consistently fix bugs, upgrade security, etc, while multiple security publications identify OpenSource bugs and no one cares enough to fix them?

Why are Commercial Vendors consistently years ahead of OpenSource releases with new features?

Why can I simply use software from Commercial Vendors while OpenSource software requires me to jump through hoops after hoops to get it to function correctly?

I could go on for quite a while, but OpenSource is simply copying commercial products, doing the fun stuff. The hard stuff, like consistently fixing security holes, is left to the commercial vendors.

There’s simply no incentive for the OpenSource Developer to tackle the really hard stuff that the Commercial guys are simply expected to do.

It’s a double standard at best.

No.

Some people think they should get good software for free. I can't disagree more. The first law of economics applies: There Is NO Such Thing As A Free Lunch. Someone is paying, somewhere, for everything.

Frankly there is nothing wrong with that. Everyone deserves to get paid for their work. You pay the car repairman to change the oil in your car, and the plumber to unclog your drains. Why should software be any different? Do you honestly think you deserve to have brilliant people waiting on your every computer software need? You really think we want to anticipate every problem you're going to have, and write a cool little utility to solve it for you? For free?

Oh, but you argue, open source doesn't mean free software. You mean that the source code is open to criticism by peer review, and the final product is better because of it. Wrong again! The software is no better than the programmers who wrote it, and it doesn't matter whether you paid for it or not!

Also, because open source software is out there for the world to see, anyone can download it, compile it, and create whatever product it is, and use it, for free. They just have to be smart enough to compile it, or hire someone who is. They're not paying anyone for that software. They're not going to tell you they're using it for free either. They're just going to compile it and use it, for free.

If you didn't tell them they can't use the compiled product without paying you, guess what? They won't tell you they're using it. Thousands of shareware authors never being paid for their work will attest to the fact that nobody is going to pay for something they can get for free.

I'd rather buy an operating system or piece of software, because I can get help and support for it. I have someone to blame when something goes wrong. I can get help to do whatever I wanted to do in the first place. I'm not up a creek without a paddle. I don't have anyone to blame but myself for using free software when it breaks. I can't get $0 back from free.

Writing free stuff so the world can see what a good programmer you are can only go so far. If you want to program for a living, that implies you want to make money doing this. How will you make money if you give away your product (which is really the source code, not the compiled executable) for free? Maybe you do something else for a living, and programming is just a hobby. How good is your work, if you just do it for fun?

Oh, but you want to get paid just for maintenance? Why should I use free software that I have to pay for maintenance on? I'd rather buy software that I only pay for once, and not have to put out money every time it breaks. If it breaks often enough for the programmers to make money just doing maintenance, it was a crappy program to start with.

And you think Microsoft is bad? At least their service packs are free. Most of the time their software works. People have thrown so much criticism at them over the last decade that their stuff has generally become pretty damn good (ok, except Vista, but XP is good).

Get a clue kids. There's no such thing as a free lunch. Open source is a straw man. The real desire is to get something for nothing. That's just not the way the world works. Good programmers deserve their 6 figure salaries, and their companies deserve to charge money for their software. I'll buy that over open source any time.

-rm

Law of many eyes

It is currently working, Fortify themselves count as those eyeballs looking at the code.

In java there are findbugs and pmd for static analysis. I am not sure what is available for c and c++ or any other languages. Maybe Gentoo could use one of those static analysis tools as part of a process of some sort, since they already have all the sources for many projects.

Fortify's analysis

Well, the headlines everywhere are using a too-broad paintbrush, and Fortify's recommendation "to have a security bug email address" is kinda silly. Out of 16,233 "Total Issues" among the current software package releases, 14425 occur within "Hipergate 3.0.26", with over 178 issues per 1000 lines of code. (JBoss 4.22, in contrast, had just 72 "Total Issues" and just 0.27 issues per 1000 lines of code.) And yet, these projects are bundled together in one big heap, and various declarations about the poor quality of code, bad project management, and bad bug triage are made....

Very often, these bugs are deep and broad, and having an email address does nothing to solve them. The project mgrs must WANT to solve them first. And obviously, this CMS software (Hipergate) cares nothing about security, and blithely assumes that all input to update databases will be "friendly" and doesn't need to be checked for excess length or inappropriate content. (At least, this is the way a cursory look at the code seemed to me.)

(Oddly, Tomcat, another widely used J2EE server, did much worse than JBoss. That was interesting!)

But it then tries to draw these crazy conclusions, lumping "good projects" together with Hipergate, software with an error rate HUNDREDS OF TIMES worse. And of course, these java-based DB apps have little in common with, say, the Linux kernel. Fortify's tool only analyzes Java, and that tends to be a preferred language for "quick and dirty" coding.

Hipergate's class hierarchy is certainly enterprise-SIZED, but it's definitely not of Enterprise QUALITY. I've been a software Test/integration analyst, for companies you've heard of. In an "Enterprise" App, the Application itself needs to take steps to protect the quality, safety, and security of the data. This should be done in a framework within DB access Methods, not just "hoping the individual UI-level module developers will do it first", or assuming that "all of our users are well-meaning employees who would never create a fraudulent buffer-overflow query".

This design would have FLUNKED my review. If the UI and other "high-level" methods want to do some input validation first, that's great-- we'll end up checking it twice. :))) But it's a need which is common to ALL of the DB Updating classes, and the common code of the DB update stack should be doing some checks.

Fortify's paper has some nice data, although only a few projects were discussed. Terrible conclusions, though, and even worse headlines. "Many Eyes" isn't broke-- in fact, I just did a 20 minute look at Hipergate SOURCE CODE to make this short summary of what I saw with my two eyes! But project managers should (IMO) care about the security of their project, or ANNOUNCE that they don't. It's better to design in than to patch on, but either way works (at least somewhat) -- you just have to care enough to invest the effort.

K.I.S.S. and The Geek Principle, too

While "many eyes" is important FLOSS has many other advantages on the quality side. The mere fact that it is open means the guy who stumbles on a bug can actually do something about it. I think FLOSS also tends to be simpler so the KISS principle applies. The geeks who write FLOSS like to keep things as simple as possible in order to accomplish a task by the most direct route. That automatically makes it easier to create the software and to debug it. Geeks value something that works well and in a transparent manner far more than the folks who created Vista, for instance. If you are creating software to work well and to establish your credibility/tickle your geeky fancy, you are much more likely to produce good code than someone who is attempting to lock-in users or to mess with the competition. It is all about priorities.

I decided to use FLOSS and GNU/Linux in the fall of 2000 when the commercial software I was using crashed every hour for me and my students. I knew I made software that did not crash and that principles of modularity/isolation/completeness were well developed in software engineering. Why was M$ not doing that when they created Lose '95? They had other priorities. I went from one crash an hour to no crashes in six months on five systems and have never doubted the FLOSS development model except briefly ever since. The Debian SSH key debacle did mess me up/test my faith but that was fixed in a few days, well, and I am sure many lessons were learned. Has M$ learned anything about software quality if Vista is their state of the art?

I have also dealt with other commercial/non-FLOSS software and I have seen on several occasions the holders of the rights to software protect their rights instead of responding properly to bugs. On the one hand they have salesmen extolling the virtues of their software and on the other, bug reports go into a black hole. I have dealt with one company that took years, and a threat to install FLOSS, before they would make their package run for my employer. For another employer, it took many weeks to install the non-FLOSS stuff when I already had the FLOSS equivalent running in minutes. When software sells on lock-in rather than quality, there is little motivation to produce good software.

Not having to deal with stuff irrelevant to quality, like licences, also greatly reduces the cost of ownership/operation of FLOSS. Cost is an important quality of software where FLOSS wins easily. Last year, I met an owner of a new PC with Vista who could not get it to run. Vista denied her service on account of validation! What quality is that? I installed Debian Etch and in minutes she had an OS that worked for her and not against her. Plan B was shipping the PC back to the supplier at a cost of $200 or so for freight. Who can doubt that FLOSS is better quality?

Another time, I worked at a place that decided to upgrade the software. The supplier of non-FLOSS stuff insisted that my employer install every version of the software released in the last five years, and pay the licence fee each time, in order to migrate the data to the newest release. They could do that because of lock-in. That is definitely not something you would expect from FLOSS.

The horrors of non-free software go far beyond not being able to see the code.