In response to "Free Code
For Sale: The New Business of
Open Source"

Hi Christopher

The latest copy of CIO magazine published in Australia carries your piece from a few weeks ago titled 'Free Code For Sale: The New Business of Open Source'. This is also available online, here:

http://www.cio.com.au/index.php?taxid=14&id=990878255

so I'll quote from that version.

There are a few flaws in analysis or concept contained in that piece, which I feel must be brought to your attention. This is in no way a metaphorical 'slap' aimed in your direction - I appreciate your efforts in writing such long and detailed articles, ruminating on the somewhat complex topics that open source raises. But there are some issues nonetheless, so let's jump into them.

I'll take bits from the article and add my comment below them. And yes, I do understand that many of the comments I take from the piece aren't yours, but the subjects' interviewed for the article.

Regardless, it is you who is giving these people (who are either intentionally misconstruing open source or are merely clueless,) a voice. It is therefore appropriate that I give you the correct pespective for sanity-checking referenced quotes in future articles.

Yes, I can't stop these people having the views they have - we're in a free society where people can say what they want - however, you're not quoting from everyone who has an opinion, but supposedly selecting from industry players whom your readers believe are well versed in the subject matter at hand or perhaps even experts. Reading their comments to you, makes me understand that they are anything but.

So, let's start. Your article states:

1) And that could lead to situations in which CIOs are seduced into using what seems to be free technology only to find they must pay to make it work down the road, says Michael Goulde, senior analyst for Forrester Research. Adds Tango: "This model has been around for years. It's called a trial version."

Comment: 'Buyers' should always do their due diligence whenever acquiring any piece of software for business use. If software claims to be based primarily but not wholly on open source licenced code, then they should assess which bits of that solution are indeed open source and which are not.

They should then ask themselves the following:

"What would happen if the non-open (i.e prioprietary) bits are shut down or held to some kind of licence hike ransom? What would happen to my operation?"

If, after a risk analysis, they discover that the answer to this question is that either the risk or impact is not sufficiently high, they can then proceed to deploy that application. If however the risk or impact is high, they should consider a pure open source application.

You understand that the original pututive situation raised in your article, that where the 'buyer' or user is held over a barrel, cannot happen with open source software, but happens every day with proprietary software.

2) Proprietary software companies have been giving away trial versions of their software for years. But the code is closed, and the free versions are lesser versions of what you'd get if you paid full price. "That's no different from what these so-called open source firms are doing with their community [open source] and enterprise [proprietary] editions of their software," says Barry Strasnick, CIO of CitiStreet, a benefits management company.

Comment: Can you name even a single open source solution provider, even the ones who operate on a mixed-source business model, which doesn't offer a significantly viable business-grade version of their product, as wholly open source?

If they actually tried to play this trick, their open source version wouldn't gain enough critical mass to be useful or used by anyone. Sure, SugarCRM has some proprietary extensions, but their core open source version is great for 90% of businesses.

Remember, open source developers aren't generally stupid. They don't stumble on a small mound of code which doesn't serve some valuable purpose and decide to build atop that code to make it fully-fledged, unless that code gives them enough of a starting platform to make it worthwhile climbing the learning curve to understand the code and extend it.

Whereupon, this new code which has just made the previously less useful application suddenly useful, is not owned by the original mixed-source solution provider, but the community. The provider cannot proprietarise that codebase.

3) CIO of Owens Forest Products, "My fear is that if a company has a free open source version and a commercial version with enhanced features, the free version [may suffer] down the line."

Comment: Consider this scenario. As a user, I acquire and deploy a piece of software which is open source. At some point, I discover that the vendor of that software has let the open source version fall behind in either features or support.

If I had done my due diligence properly, I would only have acquired that open source solution after I'd ascertained that there was a broad level of community usage and support for that software. As such, I would now fall back on to that community and work with them to continue the free-access regime and communal support approach to maintaining and updating that software.

If it's important enough to me, I will also hire a developer to make changes and fixes, every now and then. Most importantly, I would tell the mixed source vendor to take a hike when he came hocking his proprietary wares.

The key point is that the impact to my business would be mininal. Certainly, much less than what would happen if that original software were proprietary. Think of JD Edwards or Peoplesoft users, for example. They have no recourse to ongoing support and new features for their selected proprietary applications. They must now do whatever the hell Oracle tells them. In answer to "Jump!" they must now ask "How high, Sir?"

4) The company you're buying from is a community, the references you're checking when you're doing your due diligence are postings on a bulletin board, and the developers posting them may not even be employed.

Comment: You include some references to open source due diligence checklists. Might I suggest you add the one contained in the publication I'd written for the Australian government, The Guide to Open Source Software

5) But others in the community wanted to guarantee that Snort would remain open. They formed a group in 2003 called Bleeding Snort to provide open source intrusion-detection rules and definitions for Snort (similar to the virus definition files you download for your antivirus program). It was a prescient move.

Comment: In this paragraph, you show a glimpse of the power of open source software to ensure ongoing access rights to users. This is of critical importance for CIOs to understand. You can't do this with proprietary software. Not one bit.

6) But the fact is, not all open source security software has remained open. A software package called Nessus was initially released under an open source licence in 1998, but the latest version (3.0) has been released under a commercial licence (earlier versions remain available as open source) - though it is still free to users.

Comment: Yes, Deraison decided to take Nessus proprietary, which means that at that precise juncture, the community forked the code, which it has a right to do, to maintain an open source version in perpetuity. This version is now available at:

http://www.openvas.org/doku.php

And because it is open source, while it may take a while (it took OpenOffice.org and Mozilla over two years each to accrue a community and a viable codebase) it will eventually become a viable competitor, even to the monetized proprietary Nessus. It will also have the communitarian goodwill and group guerilla marketing that money can't buy. Even Microsoft money.

This is how open source is supposed to work. If a codebase is sufficiently important to enough people, it can be kept open and free.

Cheers,

Con Zymaris