Fed's role in code testing is good news

Fed's role in code testing is good news

Summary: In the end, Homeland Security can't force other government agencies to abandon Windows or Linux.

SHARE:
TOPICS: Open Source
2

In reference to Homeland Security spending $1.24M to test open source code, David Berlind noted that "No matter how this news is sliced, it isn't good for providers of commercial alternatives to these open source products." I disagree. Aside from the fact that the biggest providers of open source products are commercial providers (RedHat and Novell, for instance -- not to mention IBM and Sun) ...

What if such a study reveals the inherent problems with poorly documented changes to open source code? Homeland Security cannot force other government agencies to abandon Windows, UNIX, or Linux. (Have you ever known a programmer who can document code worth a damn?)

Without some central repository of changes to open source code, anyone could make a subtle change to open source code which might lead to vulnerabilities when that code interacts with some other (unanticipated) piece of open source code. Without some central organization testing each and every modification to open source code, vulnerabilities will creep in. Enter Homeland Security ...

The underlying assumption is that open source developers are more competent (and less mischievous) than those developing code for profit or those selling that code for profit. That strikes me as an extremely naive assumption.

You are also assuming that, should such a study find open source code to be less buggy, that the enterprise and the government would flock to it. I doubt that -- mainly because they will continue to want the service and support available only from commercial vendors -- whether they are RedHat or Sun, IBM or Novell.

If open source wins, RedHat will say "I told you so" ... and so will Sun or Microsoft if they are exonerated. IMO, more likely than not, in an unbiased study nobody will come out significantly better than anyone else.

It is certainly true that having the government debug your code for them is a significant advantage for open source developers, but it is also a Catch-22. If the government determines that open source is actually more vulnerable to bugs than commercial code, it will not fair well for Linux vendors who want to be taken seriously by the enterprise.

In the end, whether in the enterprise or in government, the user buys Linux from RedHat (or whomever), Solaris from Sun, or Windows from Microsoft depending upon their needs, their budget, and their faith in the vendor. If the vendor fails to provide the quality and service they promise, then they will lose the business the next time around.

I would maintain that no code is perfect, and that a code's stability is more closely related to its maturity than any other single factor. In the end, Homeland Security cannot force other government agencies to abandon Windows, UNIX, or Linux. All have their place in government, and in the enterprise.

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

2 comments
Log in or register to join the discussion
  • Total ignorance of actual FLOSS practice

    "Without some central repository of changes to open source
    code, anyone could make a subtle change to open source
    code which might lead to vulnerabilities ... Without some
    central organization testing
    each and every modification to open source code,
    vulnerabilities will creep in."

    Um... don't look now but every major FLOSS project has
    such a central organization.
    LouS
  • Central Repository

    Yup, you missed the boat on that one, guy. There IS a central repository of code, and a mechanism to check each and every code contribution before it is added to the kernel, or any other project that exists for FLOSS. Even if a project is defunct, the practise of having the sources freely available stops most from adding those little 'back door' sneaks that closed source programmers often use in the course of their development efforts. Any one that reads through the code base would discover any such vulnerabilities and warn others fairly quickly, and the back door code would be simple to remove or change to shut it off. The kernel development team has their own repository for kernel code, and it has all the standard features for a code repository to keep undesirable code out of it. Only code that has been fully vetted by the team is allowed into the production kernel, and that only after it has been thouroughly tested and assessed. Any other vulnerabilities are caught by users and other concerned individuals who check submissions and test individual packages for such things on a regular basis. As has been noted, turn-around time for vulnerabilities is often one day or less for any such 'holes' found in applications. Volunteers keep a close eye on things, especially where their good name is at stake.
    Mil-spec-guy