In the California Performance Review (CPR) released August 3rd, 2004, the review board is recommending to our Governator that he consider open source alternatives to their IT solutions. Consider is good, favor is bad. The problem is that the review is so heavily slanted to open-source as this magic bullet for solving the world’s IT problems…that there may be risk that a top-down initiative is given to adopt an open-source only approach to IT. No doubt the government needs to streamline their approach to IT, and they are likely wasting money on legacy system maintenance, pre-built packaged software deployment (often referred to as custom-of-the-shelf, or COTS products) and possibly lack the IT horsepower in some areas to make effective, forward-thinking decisions. Still, that doesn’t mean it’s right to take the completely opposite stand: open-source or bust!

Since I’m planning to attend the hearing in San Diego tomorrow and contribute, I have been reading the CPR, and in there they quote the following resource for their list of features that distinguish open-source.

http://www.opensource.org/docs/definition.php

In fact, they use the entire list verbatim, without realizing that perhaps not all items in this list are absolutely unique to open-source. In my opinion this is misleading, and therefore deserves a good commentary bashing. Here’s my shallow, sarcastic and somewhat glib interpretation of “the list”:

1. Free Redistribution: The software can be given as part of a package with other applications;

Not all third party applications require a license fee to redistribute therefore this does not “distinguish” open-source. For example, Microsoft .NET developers can build applications targeting the platform, and redistribute the runtime to support their application.

2. Source Code: The code must either be distributed with the software or easily accessible;

Great! So now our government IT departments will spend time writing code at the kernel level, and hopefully it won’t introduce bugs to the system. Well, I’m sure that along with affording the most qualified administrators and developers, they’ll also have an entire QA team that can verify modifications to the operating system or software plumbing source are “ok”.

Oh for goodness sake, that’s why vendors charge for their products. It’s an economy of scale - you pay a vendor to make sure they test their products, support them into the future, and are held accountable for security and other software patches. Sure, it’s not a perfect science, sometimes we wait for patches, but the overall good outweighs the potential disaster of taking on that responsibility in-house.

3. Derived Works: The code can be altered and distributed by the new author under the same license conditions as the product on which it is based;

Right, and what’s more, when those licenses are invalidated by all of the infringing patents that lurk, they get to violate those as well. Neat! C’mon people you are reaching for bullet points here. Oh, you want an example of the potential problem? Here ya go:

http://news.com.com/Group%3A+Linux+potentially+infringes+283+patents/2100-7344_3-5291403.html?tag=nl

4. Integrity of the author's source code: Derived works must not interfere with the original author's intent or work;

Terrific! So, correct me if I’m wrong, but basically does this mean that anyone who modifies source and gives it back to the community to share is on an honor system to “not interfere”. And if someone fails to meet this requirement, are they sent to jail? Do they receive a good IM scolding? Will they lose all their network gaming friends?

Basically my concern here is “who is accountable?” Software vendors are accountable for their software quality. They are obligated to follow business practices, follow development procedures, and answer to their clients. Sure, not all clients are satisfied all of the time…but you can bet they’ll do everything in their power to address critical issues.

5. No discrimination against persons or groups;

This is an interesting bullet. So, do software vendors discriminate? If you ask me, and I’m assuming you did because you are reading my blog, the discrimination comes from the higher barrier to entry in the open-source community. Because there are fewer productivity tools and in some cases even fewer helpful references for getting started, fewer new developers are able to quickly be productive. Worse, they may take 4x, 6x, 10x to do the job of a seasoned engineer, therefore there are fewer in the community skilled enough to save companies on development costs. This also feeds the issue of #2 above.

6. No discrimination against fields of endeavor: Distributed software cannot be restricted in who can use it based on their intent;

Again with the “discrimination” thing, but this is completely vague so I have nothing more to say here except:

 What on earth do you mean by this?

7. Distribution of license: The rights of the program must apply to all to whom the program is re-distributed without need for an additional license;

See #1

8. License must not be specific to a product; Meaning that an operating system product cannot be restricted to be free only if used with another specific product;

Hey, free is free, however you get it free…who cares? Besides that, I have no idea how this comment really helps government IT.

9. License must not contaminate other software; and

Well, the term was “restrict” not contaminate…I guess this is intended to draw attention…and, well look there you have it. The point here was to ensure open-source software license didn’t require other software shipped with it to be open-source. I don’t know how other vendor’s infringe on this…anyone else know?

10. License must be technology-neutral.

Meaning, you can use open-source software to build any type of software application your little heart desires. Yep, I can do that with other platforms as well.

So, let’s review shall we? What have we all learned?

#1 and #7 make good points that perhaps some costs can be saved on open-source. No argument here, some software platforms require license fees. They also require support fees for additional support. Choose the right tool for the right job then…decide if you want to save money in development time & effort, in the number of developers on staff, or in the costs for licenses. Leave the choice open.

#2 is great for people that write their own compilers. Sounds like a good time to get a high-paying Government job. Otherwise -  useless.

#3 is a potentially dangerous reason why not to choose open-source.

#4 makes no case for open-source as better, sorry.

#5 and #6 are, well, just silly.

#8, #9, #10 – bla bla bla - no compelling argument for or against from what I can see…

Following the overview the review proceeds to talk about the core benefits of using open-source in mission-critical implementations because it is, and I quote from the CPR:

• More secure due to the extreme scrutiny of the source code before being deployed;
• Can be run in multiple environments (i.e. Unix, Linux and Microsoft);
• May be less expensive to manage (no maintenance contracts or upgrade costs); and
• Often less vulnerable to viruses.

More secure?

Ok we all know security flaw are well publicized when it relates to the big giant, Microsoft. However, there are also Web sites devoted to Linux security flaws. Microsoft stays on top of their security patches because they have to, to be credible, to survive. In the Linux world concerns over the timeliness of patches is an issue. Also, recent concerns have evolved related to the fact that a malicious attacker could modify the Linux source and reintroduce it to the open-source community resulting in numerous implementations using corrupt packages. How can this be prevented? Companies have to test the software internally. So, now you have to hire an operating system QA team on top of your software QA team, if you even have one. Right.

Multiple Environments?

It is true that Microsoft solutions only run on Microsoft operating systems. But what about other vendor solutions such as BEA WebLogic? They run on Windows, Linux, Unix. And besides that, most companies can’t afford to staff up on multiple operating systems and platform environments. Platform choices are made based on many factors including the application of choice, the current install base, and the skill set of the team to manage it. Interoperability through Web services makes it to connect disparate systems - that’s the whole point. The right tool for the right job and all that jazz.

Less Expensive?

Possibly for some, but not for all. What about productivity? What about licensing fees paid to third-party vendors that will provide security patches for open-source? What about hardware costs? What about the price for more seasoned developers? A larger QA team? The cycles burned trying to figure out code that isn’t well documented? I could go on…

That’s why the choice needs to be there. It is imperative that each government entity make choices that are right for their requirements, their environment, the existing staff, existing hardware and infrastructure, and so forth.

Less Vulnerable?

See #1.

Ok, so now that I've had my fun sharing my less politically correct thoughts...let's come back to the basic message of this commentary:

• The selection of software vendor and platform is one that should be made based on requirements and leverage on a case-by-case basis.
• Open-source should not be excluded from this selection process, but should not be preferred by policy as that might exclude a government entity from making a better choice for their needs and leveraging existing assets.
• The CIO Council and regional CIO to california should take an interest in defining standards for evaluating ROI on product selection, and should take active role in guiding the selection process and insuring that well educated IT and development staff are employed to manage this selection and implementation process.

All in all, my disappointment in the CPR is that it appears to have been written with a clear slant for open-source because it is “free“ without considering all of the other costs involved for developer productivity, testing, training, maintenance, security, monitoring activities, manageability and more. They should be terminated :)