The three commonly touted benefits to free and open source software (FOSS) in government are: (a) that it is inexpensive and so demonstrates that a government agency is being fiscally responsible and using taxpayer monies frugally, (b) that it avoids a government agency getting “locked in” to a commercial supplier, and (c) that it can be inspected by adequately ‘informed’ citizens because the source code is not hidden, thus consistent with open and transparent government.

The arguments seem compelling at first glance, but in reality there are a number of challenges experienced with FOSS:

Firstly, the low or no cost of FOSS only reflects the initial cost of the system. The total cost of software typically comprises three cost elements: (a) an upfront cost, (b) an ongoing cost and (c) a series of ongoing indirect and opportunity costs. FOSS has a low upfront cost element, but usually comes with high ongoing and indirect costs due to higher costs to locate and retain technical support. The cost of upgrading from FOSS is usually higher too because upgrade paths from one version to the next cannot be controlled as well as COTS software – many people contribute to the source code which makes up a FOSS product.

Secondly, the claim that FOSS avoids “locking in” a user to a particular commercial supplier is possibly false because it does not illuminate other forms of “lock in” which a user faces. Users of FOSS are often “locked in” to the product itself – a product that nobody or no company can support and a product which can be impossible to upgrade from. The user in effect becomes locked in to their own decision to use FOSS. The intellectual property behind FOSS is donated to the public domain and so it is not owned by any one company or person, the implication being that no one company or person takes ultimate responsibility for technical support of the users of the FOSS product – users have to be more technically independent and proactive when addressing their technical support needs. COTS authors usually reinvest a large part of their revenues back into technical support mechanisms to ensure their users get the most out of the COTS systems. COTS authors reinvest in technical support for their clients by building help desks and establishing telephone hotlines, writing documentation, providing online chat operators, developing training courses, setting up online communities of practice, and publishing lists of helpful information like “tips & tricks” and frequently asked questions (FAQs). The same quality and quantity of FOSS technical support is rare to find in one source. Typically technical support needs to be harvested from online user groups. There are instances of companies that “add value” to FOSS products but they charge for their version of the FOSS application and so by definition this excludes them from being considered FOSS due to the software charge.

Finally, the more philosophical attribute, that FOSS is consistent with the basic principles of open government because informed people can open and inspect source code may be flawed. The openness of government does not make sense when the granularity of the processes to be “opened” are so fine grained. An analogy: it would be difficult to argue that the inner workings of a photocopier must be visible to all for it to be accepted as an artefact that supports open government administration and therefore utilized by a government agency. A photocopier provides an organisation with certain ‘services’ and those services should be considered atomic or indivisible – they should be considered fine-grained enough to not warrant any further decomposition or revelation. The concept of open and transparent government processes taken to that level of detail does nothing to add value to the way in which a government serves its citizens. In fact, if a photocopier manufacturer could not protect and conceal its intellectual property and had to make it “open”, it is likely they would not be able to maintain a commercial business and future iterations of their photocopier may be jeopardised – government without access to a photocopier, because the photocopier is no longer profitable to build in an open way, may indirectly subtract value from government and its citizens. This is an exaggerated example, but the principle is the same. If opening a process adds no value or does not remove risk that a government process can be hijacked, then the reason to open the process is moot.

Dr. Yumita, the Executive Engineering Director of NHK (Nippon Hoso Kyokai, in English, the Japan Broadcasting Corporation) was a panel member in the last session of the ITU World Telecom 2009 Conference. During the panel discussion he outlined his vision for the next generation of TV currently in development. He explained that Japan is working extremely hard to develop the world’s first 3D television broadcasting system capable of running across the new generation of UHDTV or “super high vision” TV planned for introduction in the next couple of years in the country and around the world. The new broadcasting system would allow ultra HDTV (the next generation of HDTV) to display 3D video that will not require the cumbersome yet traditional red-blue glasses.

He explained how the broadcasting system will require enormous amounts of digital bandwidth between the broadcaster and the TV receiver and will be based on existing IP protocols but requiring next generation digital networks.  Dr Yumita also cited the significant progress made on “wide field” TV imagery, a display system which allows TV pictures with a 100-degree field of vision or more to be broadcast and displayed. Today’s widescreen TV typically displays a field of vision less than 30-degrees or so but humans often depend on at least 100-degrees of view. He explained that the new broadcast protocol is being designed to prepare for wall and ultra-large screen TV formats.

Today I experimented with the creation of an application in Python to run on the new Google App Engine (GAE) infrastructure. Things couldn’t have been easier. I whipped up a .yaml file, created a couple of Python classes, a simple CSS stylesheet and HTML form (to give the application a face) then ran a single command line command (“appcfg.py update myapp”) and a few seconds later, there it was! An online, robust, scalable web application operating on the Google infrastructure. I use Eclipse IDE because of its extensibility and because there exists a plugin to develop GAE applications in either Java or Python. I am a fan of python because of its efficient data types like lists and dictionaries. I was however curious as to why I need to locate all resources in a sub-folder called “src” under the application – why couldn’t the source files be located in the root directory of my local file system folder for the application? Anyway, something to test out another time. I am going to dig a little deeper into the data structures available to a GAE application tomorrow – I’ll let you know how it goes