Asay the Alfrescan

Gary Edwards (Open Document Foundation) and I were talking yesterday, and he mentioned the NASCIO (National Association of State CIOs) Conference coming up. I checked out last year’s conference and found an interesting set of slides from an open source session they held.

From the slides, some useful data on why state governments are buying into open source. (Note: The survey was to CIO-level IT people within state governments. Pretty credible data, especially since NASCIO gets 350-450 senior government IT folks out to its annual conference, and restricts the survey (unless I’m reading the site wrong) to the most senior IT officials).

Anyway, why are state CIOs buying into open source? Well, for one thing, because it costs less. But also because it works better:

As for where they’re currently at in adoption the answer is hugely positive: not very far. Why is this positive? Because I’d rather be at 25% and growing than 99% and shrinking.

What’s holding it back? Again, the news is good, because it reveals, in the first place, a lack of understanding about how much the open source market has matured (support) and, in the second instance, a need for more capable IT staff. This will happen organically as the youth are being raised on open source. In 10 years, it will be Windows/SQL Server/etc. expertise that will be lacking, not Linux / MySQL / JBoss / SugarCRM / JasperSoft / Alfresco / Digium / etc. expertise. Microsoft will be the Buick driven by my grandmother (bless her!), and open source will be the Honda or Toyota that everyone drives because it’s cheaper, works better, never breaks, etc.

Why am I so optimistic on this open source future? Because the customer satisfaction it brings:

Time to call your state government and vote open source. Sounds like they’ll be happy to get that call.

Computer Business Review has an interesting review of the United States Department of Defense report “Open Technology Development“. [PDF] If you haven’t read it, you need to take a look. It is one of the most clear-sighted documents on open source that I’ve yet read, and should banish CIO doubts as to the core benefits of open source: cost savings, security, speed of development, robustness of development, etc.

SCO and others have been crying ‘Foul’ on the US government’s increasing adoption of open source, suggesting (as Darl McBride writes here in his letter to the US Senate and House)

“I assert that open source software - available widely through the Internet - has the potential to provide our nation’s enemies or potential enemies with computing capabilities that are restricted by US law.”

Think that’s a bit silly? Try this one, from the CEO of Green Hills Software:

“Now that foreign intelligence agencies and terrorists know that Linux is going to control our most advanced defense systems, they can use fake identities to contribute subversive software that will soon be incorporated into our most advanced defense systems.”

Apparently O’Dowd (Green Hills CEO) has never actually taken the time to learn how open source and, specifically, Linux, operates. But we’ll forgive his abject ignorance on the condition that someone pays his tuition to head back to school at some point. He needs it.

Anyway, back to the Department of Defense’s report. It has a treasure trove of insight, nicely counterbalancing the ignorance noted above:

Currently within DoD, there is no internal distribution policy or mechanism for DoD developed and paid for software code. By not enabling internal distribution, DoD creates an arbitrary scarcity of its own software code, which increases the development and maintenance costs of information technology across the Department.

Other negative consequences include lock-in to obsolete proprietary technologies, the inability to extend existing capabilities in months vs. years, and snarls of interoperability that stem from the opacity and stove-piping of information systems….

Software code has become central to the warfighter’s ability to conduct missions. If this shift is going to be an advantage, rather than an Achilles’ heel, DoD must pursue an active strategy to manage its software knowledge base and foster an internal culture of open interfaces, modularity and reuse. This entails a parallel shift in acquisitions methodologies and business process to facilitate discovery and re-use of software code across DoD.

The national security implications of open technology development (OTD) are clear: increased technological agility for warfighters, more robust and competitive options for program managers, and higher levels of accountability in the defense industrial base….

DoD needs to use open technology design and development methodologies to increase the speed at which military systems are delivered to the warfighter, and accelerate the development of new, adaptive capabilities that leverage DoDÂ?s massive investments in software infrastructure.

To be fair, the DoD is not talking about open source exclusively in this report. It is talking more broadly about open development:

In the private sector, changes in design methodologies for software development are enabling enormous gains in productivity and efficiency. Individuals and companies are able to leverage open technology platforms to rapidly deploy new solutions and capabilities to improve their competitive advantage. These open technology platforms may be open source or proprietary software applications with open standards and published interfaces that allow the rapid development of new capabilities by third parties without coordination agreements.

It’s the mash-up mentality, in some ways, that seems to appeal most to the DoD. But it’s not just about “Web 2.0″ thinking. It’s about how to make the DoD a participant in the wider software community, thereby saving development cycles and development dollars, as this fascinating excerpt indicates:

DoD has two competing interests:

1. Provide for the defense of the U.S., and;

2. Support and grow the U.S. industrial base, which provides materiel and systems so that DoD can accomplish its mission.

These trade-offs are well understood for physical goods and services, but not as well understood for digital ones. DoD can easily calculate the cost difference between developing or acquiring a physical good or service by simply comparing make or buy costs. There is however a fundamental difference between physical and digital products. Digital goods (software code, music, movies, etc.) once created can be copied perfectly with relative ease: limiting distribution enforces scarcity, but that scarcity is arbitrary and negotiated, rather than an innate property of the product. SoftwareÂ?s
ability to be replicated also means it can be incorporated into other software systems without Â?using upÂ? the original component, as one would with physical components.

The business model of purchasing physical goods and services has served DoD well in the past; but it falls short when applied to software acquisition. By treating DoD-developed software code as a physical good, DoD is limiting and restricting the ability of the market to compete for the provision of new and innovative solutions and capabilities. By enabling industry to leverage an open code development model, DoD would provide the market incentives to increase the agility and competitiveness of the industrial base.

Currently within DoD, there is no internal distribution policy or mechanism for DoD developed and paid for software code. By not enabling internal distribution, DoD creates an arbitrary scarcity of its own software code, which increases the development and maintenance costs of information technology across the Department. Other negative consequences include lock-in to obsolete proprietary technologies, the inability to extend existing capabilities in months vs. years, and snarls of interoperability that stem from the opacity and stove-piping of information systems.

DoD needs to evaluate the impact that locking into one set of proprietary standards or products may have to its ability to react and respond to adversaries and more importantly, to technological change that is accelerating regardless of military conflict. In order to remain competitive in a rapidly shifting technological landscape (including the disruptive technologies leveraged by our adversaries), DoDÂ?s software development and business processes must break out of the industrial-era acquisitions mold.

Amazing stuff. The DoD summarizes as follows, and shows a clear understanding of open source’s benefits:

To summarize: OSS and open source development methodologies are important to the National Security and National Interest of the U.S. for the following reasons:

• Enhances agility of IT industries to more rapidly adapt and change to user needed capabilities.

• Strengthens the industrial base by not protecting industry from competition. Makes industry more likely to compete on ideas and execution versus product lock-in.
• Adoption recognizes a change in our position with regard to balance of trade of IT.
• Enables DoD to secure the infrastructure and increase security by understanding what is actually in the source code of software installed in DoD networks.
• Rapidly respond to adversary actions as well as rapid changes in the technology industrial base.

Amen. Now if you’re a CIO tasked with saving money and resources for a large or small enterprise, wouldn’t it seem prudent to follow the lead of an organization tasked with saving taxpayers’ money and lives? Yeah. Me, too.

Back in my international relations days, reading Foreign Policy and Foreign Affairs was an imperative. And yet I never found Foreign Policy to be nearly as informative as Foreign Affairs.

Unfortunately, I must report that FP’s coverage of software is even worse than that of international relations, if this piece by Caroline Benner of the University of Washington is any indication. Benner rightly points out that governments moving to open source should be thoughtful, not knee-jerk, in so doing. But that’s about all she manages to say, and not as well as others before her.

Here’s the best section from the piece:

…[G]overnments tend not to like software they can’t audit for trapdoors that would allow an outsider access. Many countries also argue that open source is better than proprietary software at adapting to local needs, because you can change the behavior of the program by changing its code. With tiny budgets to spend on foreign-produced information technology and little infrastructure to create their own, open source looks like an attractive way for poor nations to gain access to the information age.

Trouble is, the benefits of open source are not always so clear-cut. Software is too complicated a creation to be captured in rhetoric, and assertions about some of the technical benefits of open source fail to tell the whole story.

Consider the issue of security. In a 2002 letter to Microsoft, Peruvian Congressman Edgar David Villanueva Núñez noted that, “Relative to the security of the software itself, it is well known that all software (whether proprietary or free) contains ‘errors’ or ‘bugs’ (in programmers’ slang). But it is also well-known that the bugs in free software are fewer.” Yet, ask computer security experts and they’ll tell you that’s not necessarily true. Software, with its millions of lines of code, is so complicated that experts don’t know for sure that open source has fewer bugs, nor can they say with certainty that having fewer bugs makes open source more secure. “There are really two reasons that it is very difficult to know whether software is secure,” says Stanford University computer scientist Alex Aiken. “The first reason is that even the simplest software program consists of hundreds of thousands to millions of parts, and potentially all of these have to be correct, or the system may have security vulnerabilities. The second reason is that we have no technology for systematically checking that the parts are correct and fit together in a way that ensures security.”

In this section and throughout the short article, however, Benner misunderstands the security benefits open source offers. It’s not that open source is inherently more secure - it is, after all, just software that someone has written, just as proprietary software is.

The real difference is in the visibility both “good guy” developers and hackers have into the source code. If someone cracks a security flaw in Linux, for example, I don’t need to wring my hands and wait for Microsoft to fix it (at their leisure, and when it’s good for their quarter). Instead, any active Linux user with competency can report and/or fix the problem. It is the breadth of the developer population available to fix a problem - 24 hours/day, 365 days/year - that is arguably open source’s great security asset.

Sure, you might counter, this is true of the “big projects” like Linux and Apache. What about the others? Well, for these others, they don’t face the same malevolent hacker threat, in the first place. In the second place, even with 200,000 downloads, as an example, my own company gets plenty of outside feedback (from customers, prospects, and partners) on our code. It’s enough for our needs. In short, the security community scales with the security threats in open source.

Benner questions other open source benefits - like the flexibility to tailor software to local requirements - but while her caution is welcome, it’s not particularly interesting. Of course, no one should blindly adopt open source. By the same token, no one should blindly stay with proprietary software. Both have their strengths and weaknesses. I’d prefer to deal with the weaknesses of open source, rather than those of proprietary source. It appears I’m not alone.

So, it’s actually not uncommon for me to find out that I’m an ignorant Muppet. But it’s somewhat uncommon for me to admit it publicly.

I’m in Venezuela meeting with partners and customers, some of which are government agencies. In so doing, I’ve asked for further clarification on Venezuela’s legislation (Decreto No. 3.390 [PDF download]) mandating the use of open source software. I’ve criticized this (and other governments’ open source legislation) in the past, not because of a disregard for open source software (My entire career has been spent promoting open source), but rather because I dislike government edicts that require use of a particular kind of software.

As it turns out, the Venezuelan legislation preferences open source software, but does not mandate its use in areas where it might not be a good fit. So, for example, the government isn’t throwing out its SAP ERP software (yet!), but will shift to open source ECM, CRM, operating systems, office suites, etc. because those currently have strong open source alternatives.

This, I believe, is smart legislation. In talking with people here, it’s clear that money really isn’t driving these decisions. Freedom is. Freedom from lock-in to vendors whose interests are not always aligned with the government’s. Freedom to build up the local economy by keeping Bolivares here, rather than wiring it back to the US, Europe, or anywhere else.

Here’s a relevant part of the legislation (in Spanish):

Articulo 1. La Administracion Publica Nacional empleara prioritariamente Software Libre desarrollado con Estandares Abiertos, en sus sistemas, proyectos y servicios informaticos. A tales fines, todos los organos y entes de la Administracion Publica Nacional iniciaran los procesos de migracion gradual y progresiva de estos hacia el Software Libre desarrollado con Estandares Abiertos.

Chavez is on the march….