Archive for June, 2009

Software Sustainability

Published by Ross Gardler on June 30, 2009 in Community, Development and Discussion. 0 Comments

The EPSRC recently issued a call titled “Software Sustainability“. This topic is something that is close to the heart of OSS Watch, so naturally OSS Watch submitted a bid (and, in fact, were named as partners on a number of other bids).

Collaboration is the key

OSS Watch have been acutely aware for some time that the “standard” approach to software sustainability in our sector is to “throw more money at it”. Indeed, most of the bids into this call, that we are aware of, take this approach. At OSS Watch we take a longer term view. We believe that sustainability is about reducing long term cost through collaborative development, this requires a short-medium term investment in developing collaborative software development skills. Unfortunately, our sector is more accustomed to competition for grants than to collaboration for value for money.

Evidence of this can be seen in the OSS Watch experience during the writing the our EPSRC bids. We were approached by a number of people who refused to allow us to talk to others about their plans, a ludicrous situation since some of the gaps in experience in one proposal could be closed by bringing in another member of our network. In other cases we invited representatives of potentially competing bids to view and discuss our own bid in order to find points of collaboration. Some joined our open mailing list  and viewed our draft proposal in the wiki but not once did they contribute, they didn’t even acknowledge our invite. In other words they wanted to take, but not to give.

The end result of this competition is, in this case, a number of less than ideal bids. This prompted OSS Watch to sumbit a bid that explicitly called for the EPSRC to match our own bid with another with, in the funders eyes, a suitable domain specific expertise. Assuming that our bid is seen as valuable in itself we look forward to sharing our expertise with one or more of the other bid teams.

How do we collaborate?

It is our belief that to create sustainable software that survives between one development team (i.e. grant) and the next (i.e. another grant) we need to change this culture of competition into one of collaboration. In the non-academic sectors there are significant examples of this working on both large and small scales.

The problem with this approach is that project team currently expect their own chances of survival to be dependant on their “ownership” of the outputs and knowledge acquired during the first grant. Indeed OSS Watch are an example of this. As OSS Watch manager I am responsible for ensuring we have enough grant funding for over five full time staff. If I encourage others to enter our space am I putting my team at risk?

I don’t beleive so, my team have a very specific set of experiences and skills. Collectively we cover most aspects of open source software development. Our network reaches far and wide into the academic and non-academic open source communities, but we are not omnipresent. By being clear about our specialisms and recognising other groups expertise we should be able to increase the amount of grant money we receive as we will get access to more varied pots through our cooperation. What the sector needs to realise and accept is that by being the expert one will be invited to participate in more projects not compete for less.

Whilst OSS Watch’s experience in this EPSRC bid would seem to simultaneously support and undermine this argument, it is our belief that in the long run cooperation is where value and sustainability lies. There  are examples of this happening with niche software produced in the academic sector too. For example TexGen, a project at University of Nottingham has recieved significant additional funding as a direct result of the openness of their software outputs.

Sucessful collaboration means fully open collaboration

Unfortunately, TexGen is the exception rather than the rule. Even where collaboration is the goal, our sector still tends to artificially limit membership of the community to those who are funded. This can be seen in the Community Source model, popular in large US projects which excludes some parties from participation and therefore limits the sharing of both costs and rewards to a smaller group than is necessary.

The community source model aims to add a level of control to open development projects that it is believed does not exist in true open source. However, I would argue that this is a lack of understanding of the open development model rather than fact.

My own experience shows me that there are decision making models in open development that allow for the level of central planning and control needed in major projects whilst still ensuring the doors are open to anyone who wishes to contribute in a sensible and constructive way. Indeed, if this were not the case then open source, and sustainable, products such as Eclipse, which is found at the heart of a large number of varied third party tools, would not exist.

In order to demonstrate this to be the case OSS Watch have been working with some experienced community source practioners in the Matterhorn Project. Together we have drawn up a governance model for this new project which appears to satisfy the control concerns of the funders whilst also satisfying OSS Watch’s concerns about keeping the community open.

At first glance this model may seem somewhat heavyweight for a smaller project. Therefore, OSS Watch have also worked with other parties to develop a much lighter touch governance model suitable for “rapid innovation” projects that are funded for just six months.

Those of you who read these models will realise that they are essentially the same model, it’s just that one defines more formal roles than the other since it has more initial stakeholders. This means that should the rapid innovation project be succesful it’s model can grow to accommodate a growing, and as yet unknown, community. It is this growth that is the start of sustainability through a collaborative development model.

The practice of open development

Now that OSS Watch have started to show that closed communities are not required, the next step is to encourage people to develop their software in such a way as to ensure non-community members are empowered to participate. It is these third party contributions that spread the cost of development across multiple financial pots and thus reduces centralised risk.

We recognise that policy is all very well but it is practice that matters. The adoption of open development practice requires a significant cultural change, but this is a change that our research shows is desired by enough practitioners to make it viable.

OSS Watch argues that funding projects to experiment with software ideas and then spending more money to “harden” the few that have promise is wasteful. We believe all software should be developed openly from the outset. By doing this the cost of sustaining software that successfully meets user needs is decreased since initial outputs, of all kinds, are reusable. Where software does not meet user need, as can often be the case in research software development,  the increased level of collaboration and awareness within the community serves to increase the chances of success in future projects. This is because the community is sharing not only the “hardened” successes, but also the lessons learnt in other projects.

The ÆGIS 1st Pan European open accessibility Workshop

Published by stevelee on June 12, 2009 in Community, Development, Software, Standards and Strategy and Policy. 0 Comments

To be honest I’m enthusiastic about the potential of the European ÆGIS project which launched last week. I see the blend of open source and accessibility, open accessibility, as having the potential to provide the most appropriate solutions for users of accessibility and assistive technology. So I’ve spent the last few years developing and promoting the concepts of fair access to all and user engagement whenever I get the opportunity. This has brought be into contact with enthusiastically dedicated  people and projects. The scale and scope of ÆGIS gives the impression open accessibility is now coming of age. The strap line of ‘Open Accessibility Everywhere: Groundwork, Infrastructure, Standards’ indicates the wide scope of the project which aims to use open source, open development and open standards to ‘enable people with disabilities, the elderly and anyone else who is disadvantaged when using Internet services, Desktop PC or Mobile phones’. It will do this by providing developers with a framework, architecture and toolkits, whilst also creating end user applications. 4 pilot studies will inform the subsequent development phases.

The Pan-European Workshop completed the launch week activities at Research In Motion’s Slough Offices and shared the proceedings with Raising The Floor an initiative by Gregg Vanderheiden and Jim Fruchterman to bring together all parties working on web accessibility, again using open practices. Greg has been involved in accessibility for many years and in his Introduction, Peter Korn, technical lead on ÆGIS sited Greg as his primary mentor. Peter in turn has been very active in open accessibility, especially the GNOME desktop which is used in Linux (e.g Ubuntu) and Sun’s Solaris. Peter along with Will Walker has taken a key role in orchestrating the  resources of their employer Sun to bear on making GNOME a focus of much open accessibility work, including infrastructure, the Orca screen reader, GOK on screen keyboard and collaboration with the Firefox web browser accessibility team.

In addition to hearing more about ÆGIS, the workshop offered the opportunity to catch up with some of the collaborators from the Ace Centre, OATSoft.org, aIDEAS & Mozilla as well as being something of a ‘tweatup’ for those who follow each other on Twitter, including Henni of Opera, Steve Faulkener and Gez Lemon of TPG and Davis Sloan of the University of Dundee. There was woefully little time to chat and I completely missed David Banes of AbilityNet and David McKay of Inference Labs, Cambridge (Dasher is an alternative text input program). I did finally meet Jutta Treviranus, director of ATRC at University of Toronto. Jutta is the boss of long term open accessibility developer David Bolter (e.g. GOK, dojo, ARIA), and we also heard the news that David is taking a years break from ATRC to work on Mozilla core accessibility with Maroc and Surkov.

Due to my failure to understand the scale of the map I arrived after the start having wondered up and down the batch road. The first few talks by M Gonzalez-Sancho (EU Commision ICT for inclusion, information and media Directorate General) and E Bekiarias (CERTH-HIT) provided high level views of the EU’s inclusion policies and AEGIS (£12.6M funding) as well as feedback from the previous days user forum.

Peter Korn then gave a technical overview with demos of existing applications including old friends such as the accessibility APIs, GOK, Orca+eSpeak, Dasher and Accerciser. In addition Peter showed an as yet unreleased simulator of visual impairments such as macular degeneration.

Dr Bekiarias then presented the AEGIS use cases which appear to present a reasonably representative and useful range. I was pleased to see symbol support in OpenOffice.org along with synthetic voices. As Simon Judge pointed out the desktop had little for AAC and switch users but  there is more on the mobile platform.

After an all too brief lunch, Dr C Galinski (InfoTerm) gave a presentation on structured content standards. This was followed by a very effective talk by Greg on accessibility overall and Raising the Floor. He made the point that what we do determines if ICT is a blessing or a curse to many users. He provided a clear analysis of the ways of providing accessibility (adjust interface, provide alternative interface, select alternative or download new interface on demand) and asserted that the accessibility API’s are the only real chance for an affordable and lasting strategies for flexible interface options (and I agree). He also considered reducing cost to users and the part OSS plays, seeing this as enabling more direct paths for the transfer of research and allowing the public coverage of costs other than licences. he also suggested we might like to consider free public access (cf public/private schools) and the need to fund more than research – e.g hardening, awareness, support.

Before the panel discussion Peter announced the Open Accessibility Everywhere Group. The desire to bring together all interested parties including developers, researchers and users and so facilitate exchange of ideas it echos the original motivations that underly Oatsoft.org and later Project:Possibility. While Oatsoft’s funding was only for an initial evaluation phase we can hope that OAEG will succesfully fill this important community role and so help us push the open accessibility envelope. There is an overlap here with Raising the floor that will need to be worked out, though AEGIS adds desktop and mobile accessibility to RtF’s focus on web accessibility.

I was pleased to see a place for the open accessibility projects I have been personally active in. In addition to key projects such as Mozilla, GNOME and NVDA I saw some potential for those I have been closely involved in as a developer; Simon Judge thought Maavis has something to offer in many use cases, and the straight-street.com open symbol set has much to offer. Jambu may also be useful as a starting point for some work. I’m not sure about PowerTalk as it relies on MS technologies but at least that is now included in the EduApps USB stick collection. Greg again mentioned his interest in OATSoft.org as providing the master list of projects, though the announcement of the OAEG seem to indicate it would be providing similar functionality after all.

So all-in-all a useful workshop but perhaps too many presentations with too wide a scope; I would have liked more networking time. ÆGIS is an exciting project and a serious opportunity for the benefits of open accessibility to be realised by users and developers alike. There is a lot to be done and good management will be need to ensure it delivers, but building on open development gives it a very good foundation for success. I’m looking forward to being involved as well as watching what happens.

I’m greatful to Ross Gardler (OSS Watch manager) for being so supportive of open accessibility and providing me opportunities to make it part of OSS Watch’s portfolio of experience. My first project was AccessApps and we spent Tuesday in a highly constructive consultation with the Maavis project, working out ways forward by embracing open development.

That reminds me I have an article on open accessibility to take though OSS Watch’s thorough quality control process.

Google’s Video Games

Published by Rowan Wilson on June 11, 2009 in Development and Legal. 2 Comments

HTML 5 – the next version of the language used to create web pages – is due to be finalised somewhere between 2010 and 2012, depending on whether you believe the W3C or the WHATWG, the two groups who are contributing to the language specification. One of the expected benefits of the new version is that it will allow page authors to reference and embed videos in their pages without requiring end users to have a specific browser plugin installed. At the moment, Adobe’s Flash and Apple’s Quicktime are the most popular methods for getting video into web pages, but this irks many web purists who feel that the requirement to install these plugins undermines the goal of a truly ‘open’ standards-based web. After all, while web video playback depends upon vendor-specific software, the vendors in question have enormous power to control which browsers and operating systems they will support and therefore which will be widely used. There is of course a powerful pragmatic counter-argument to this, which says that the success of the web is driven by adoption not contemplation and any solution that has been generally adopted has to be considered the correct one. If you are a business wanting to outshine your competitor’s web presence, you are likely to adopt whatever is the most attractive, eye-catching and available technology at the time without worrying to much about high-minded ideals of openness. Into this argument, HTML5 – and specifically its <video> tag – strides to resolve the question once and for all.  That at least was the idea. 

 Proprietary plugins are not the only things that threaten the ‘open’ web. Patents covering the use and creation of certain types of media file are also a problem. It would be fairly pointless to sweep away proprietary video playback plugins if you then replace them with in-browser functionality that requires a patent licence to actually include. Therefore as well as mandating that compliant browsers should be able to playback video URLs indicated by the <video> tag, the HTML5 specification originally directed that every browser should – at the very least – be able to decode the ogg theora multimedia encoding format. Theora – named after a character from Max Headroom an 80s sci-fi TV drama – is an open standard for the encoding of video which is of a similar quality to the patented H.264 MPEG4 encoding standard used in Quicktime and on many Blu-Ray High Definition video discs. Theora derives from work done by technology firm On2 who have granted a worldwide royalty-free licence to anyone who wishes to incorporate theora encoding and decoding functionality into their products. The software for actually doing the encoding and decoding is released under the open source BSD licence. It all sounds great I’m sure you’ll agree – patent-free video (and audio – ogg has a project called vorbis that handles that) playing right in your browser and no-one has to install a plugin or pay a patent licence.

 Unfortunately Apple and Nokia – companies that would be creating HTML5 browsers in the future – lobbied successfully to have the theora/vorbis mandate removed. Nokia puzzlingly claimed(pdf) that theora was proprietary, and less puzzlingly pointed out that the format had no accompanying Digital Rights Management implementation that might help providers make money from their content. Apple argued that although the On2 patents in theora were licensed royalty-free, there was no guarantee that there were not other video-related patents out there that might be infringed upon by theora (particularly submarine patents – meaning patents that have yet to be fully published for administrative reasons but which it is still possible to inadvertently infringe). Apple also claimed that there were few-if-any hardware implementations of theora decoders, meaning that low-powered devices like mobile phones could not incorporate a specialised decoding chip to take the pressure of video work off their overworked central processors and sagging batteries. Open web enthusiasts pointed out that no video format is free of submarine patent concerns, and mandating theora in HTML5 would almost certainly mean that there soon would be theora decoding hardware available. Some uncharitable commentators also pointed out that Apple held one of the essential patents for MPEG4 decoding, and so stood to make money from additional licence sales if MPEG4 became a common format for the contents of the HTML5 <video> tag. 

So the issue was already a vexed one when last week Google announced on the WHATWG mailing list that their support for the <video> tag in version 3 of their browser Google Chrome was going to use LGPLv2.1-licensed free software video library ffmpeg to decode both theora and MPEG4 H.264. Why was this controversial? Well as I mentioned above, H.264 is subject to a whole cupboard-load of patents, and anyone who looks like they have a bit of money would be well advised to get a comprehensive licence from the relevant group or be prepared for a writ on the corporate doormat one morning. Clearly anyone with a pocket-book the size of Google’s would have taken this essential step. However even doing this might well not allow you to distribute ffmpeg safely. The LGPLv2.1 – like the GPLv2 – contains a clause which aims to prevent the software it covers becoming subject to additional responsibilities and fees. This clause (section 11) reads: 

If, as a consequence of a court judgment or allegation of patent infringement or
for any other reason (not limited to patent issues), conditions are imposed on
you (whether by court order, agreement or otherwise)that contradict the
conditions of this License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy simultaneously your obligations
under this License and any other pertinent obligations, then as a consequence you
may not distribute the Library at all.  For example, if a patent license would
not permit royalty-free redistribution of the Library by all those who receive copies
directly or indirectly through you, then the only way you could satisfy both it
and this License would be to refrain entirely from distribution of the Library.

This clause is generally understood to mean that paying for patent licences to distribute LGPLv2.1-licensed code is impossible; once you pay for the licence you lose your right to distribute, so it’s never worth doing (and this in turn acts as a deterrent to patent owners looking to get per-copy royalties on LGPLv2.1- and GPLv2-licensed software – even if you win the case against the distributor, you kill the product and will get no royalties going forward). Nevertheless, Google’s lawyers seemed to have found a way through waters which had previously been thought unnavigable. As the argument on the thread continued, it emerged that Google’s approach had been to seek a patent licence for Chrome itself, not the ffmpeg library that was actually doing the video decoding. The LGPLv2.1 is designed to allow code it covers to co-exist in an uneasy peace with code covered by any other kind of licence, including patent licences. In this was free software libraries could be used wit
h proprietary software in a way that would be impossible if they were covered by the full GPLv2. Google argued that as long as they never sought patent rights to use ffmpeg, no-one could accuse them of not passing on those rights to others in a way that ffmpeg’s licence mandated. All their permissions to use patents rested with Chrome itself – however it chose to do the decoding. 

 Now this is a sly move, and not one that has been attempted in as high-profile a piece of software as Chrome up to now. Will Google get away with it? Well that question really reduces to the question: Who might try to stop them? In this case Google Chrome is relying on licences from the MPEG-LA for the patents used to decode MPEG4 (and possibly theora if they want to rule out any future challenges from MPEG-LA on that score) and a software licence from the ffmpeg project. The likelihood is that Google have paid well for complete coverage from the MPEG-LA, and so a challenge from that quarter seems unlikely. What about the ffmpeg project?  Well they clearly explain that they have no specific knowledge of any patents infringed by distributing ffmpeg. Of course, everyone is aware that the project very likely infringes on many patents in the H.264 patent pool at the very least, but time and experience has taught programmers operating in patent-rich problem domains to never read the relevant patents. It only increases the likelihood that you will infringe upon them and increase the damages if it can be shown that you knowingly infringed. What this means for ffmpeg is that it would be very difficult for them to argue that Google is not in compliance with the LGPLv2.1 for ffmpeg because they have licensed some patents ostensibly for use in Chrome. To do so they would have to explain exactly which of the patents licensed were in reality embodied in ffmpeg, and would therefore trigger Google’s responsibilities inder the LGPLv2.1. This could be seen as an unwise move for ffmpeg. With neither the MPEG-LA or ffmpeg likely to question Google’s actions, it seems likely they will get no substantial challenge to their actions. 

Open Development embraced by OMII-UK projects

Published by stevelee on June 2, 2009 in Community, Development, Software and Strategy and Policy. 1 Comment

Towards the end of April I found myself spending  2 enjoyable days in the company of OMII-UK members at the OMII-UK collaboration Workshop along with others involved in e-Research in various capacities.  Steve Brewer,  project manager of the Engage project, invited me to provide OSS Watch input at the event which included Open Source and Open Development as a key theme. This provided an opportunity for me to learn more about e-Research and meet those working in it, whilst also passing on some of our experience in open development to those project team members wanting to better embrace the techniques. Dr Mario Antonioletti, principle consultant at EPCC and long time OGSA-DAI project team member subsequently requested that I facilitate a session which became the following:

How to invigorate your project with open development: Using an OSI approved open source licence on your project artefacts and putting them on a public server is one thing but how do you nurture a lively community that ensures your project continues to develop and becomes self sustaining?  Open development is the lifeblood of successful open source projects but how does it work, what tools and process make is successful? How does it mesh with the project life cycle and at what stage should it be introduced?  This breakout will explore open development and how it can be applied to individual projects. Come along and share questions, suggestions and experiences from your own projects.

This was a deliberate ploy to concentrate everyone’s energy on understanding open development as opposed to open source, as I explained in both this session and another lead by Steve Brewer on ‘Accelerating the deployment and uptake of open source tools in e-Research’. Working for OSS Watch has help me clarify my understanding of a fundamental principle of open source projects. This is something that, having been active  in several open source projects, I rather take for granted, but that is often not immediately apparent to newcomers to the scene.  The Apache Software Foundation say it well in their policy statement of  ‘community over code’, and back in 1992 the IETF’s phrase ‘We believe in: rough consensus and running code’ puts community decision making first. Having worked with active open source projects such as Mozilla and GNOME it’s clear to me that nurturing a vibrant and diverse community is the vital ingredient for success and sustainability. In contrast there is often a focus of attention on licence issues by those new to open source, and while this is a key part of the picture, OSS Watch now also emphasise  ‘open development’ in order to restore balance. This also helps projects more clearly see why fundamentals such as encouraging participation through the use of well tested collaboration tools and having a clear governance model are critical for their long term health.

Accordingly I was keen to steer discussion towards the issues surrounding open development and how to achieve it, as well as providing recommendations and clearly indicating OSS Watch’s desire to work with projects, providing support from our collective experience.

During the 2 days I chatted with members of at least 4 mature e-Research projects, each at an intermediate stage of practising open development; OGSA-DAI, DIASER, ALADDIN and Portal Access Grid. I encouraged all to go a stage further towards fully embracing open development, so it is exciting to hear announcements from 2 of them that clearly indicate that they heeded some of our recommendations.

Damian Brasher’s DIASER was already practising many of the principles and has now followed our recommendation to make early decisions and design notes available as project memory as these were not originally discussed on the public discussion lists. This involved considerable work but the outcome is that anyone can now find this information archived on public list and can more easily evaluate the project.

OGSA-DAI started as a closed community project though it is now released under an open source licence. During the workshop Mario stated his desire for the project to practice open development as I described it.  Thus it was a pleasure to see an article by Mike Jackson in the June 09 edition of National e-Science Centre news stating they are commited to achieving it.

OGSA-DAI: from open source product to open source project

The OGSA-DAI project has been funded by EPSRC for an additional year, until April 2010. This funding will enable us to evolve OGSA-DAI from an open source product into an open source project.

An international community of users and developers has formed around OGSA-DAI, our unique open source product for access to and integration of distributed heterogeneous data resources. This includes projects and institutions in a myriad of fields including medical research, environmental science, geo-sciences, the arts and humanities and business.

Moving to an open source project will provide the community with a focal point for the evolution, development, use and support of OGSA-DAI and its related components, providing a means by which
members can develop and release their components alongside the core product. It will also provide an avenue to ensure the sustainability of their components. Over the next few months we will set in place the
governance and infrastructure of the OGSA-DAI open source project. This will be done in conjunction with key community members, and will draw upon the expertise of our OMII-UK partners in Manchester and
Southampton and in the Globus Alliance. We aim to roll out our open source project site in October.

Our move to an open source project contributes to OMII-UK’s vision to promote software sustainability, and will guarantee that the lifetime of the OGSA-DAI product will exist out with any single institution or
funding stream. In addition, we will continue to develop the product and engage with international standardisation activities:

[snip]

The OGSA-DAI project -which involves both EPCC and the National e-Science Centre- is funded by EPSRC through OMII-UK.

I’d like to congratulate both projects for taking these important steps toward open development and wish them every success. I’m sure the OSS Watch team will be most interested to hear how they progress, I know I am.

OSS Watch provide many articles about open source development including a guide to participating in an open source community and a review of one of the best books on the subject – Producing Open Source Software by Karl Fogel.

Guest Post: FOSS and the European Parliament

Published by Rowan Wilson on June 1, 2009 in Community, Guest, Procurement and Strategy and Policy. 0 Comments

From time to time OSS Watch will be publishing guest blog posts here to highlight interesting opinions from around the FOSS community. This post is by Gerry Gavigan, chairman of the Open Source Consortium.

Elections for the European Parliament are scheduled for 2 June 2009, and this seems like an ideal opportunity to broach the subject of ICT policies and draw the attention of candidates to the issues surrounding choices by government and its administration concerning software and systems. Hopefully, this will at least raise the profile and gain better consideration of the underpinning issues and lead to wider adoption of Free and Open Source Software.

One initiative attempting to do this is the Free Software Pact (FSP) providing candidates with a method to inform the voting public that “they favour the development and use of Free Software, and will protect it from possible threatening EU legislation.”

As Chairman of the Open Source Consortium I was asked to help promote the FSP. Fundamentally I agree with the underlying objectives of the FSP but I am not sure that the approach to implementation is well thought through.

I am convinced that level playing fields coupled with open and transparent processes topped off with effective governance (easier said than done, of course) are all that Free Software needs for new installations and also to trickle through the arteries and capillaries of existing ICT deployments, eventually eliminating the externalities of proprietary software (largely summarisable as the deadweight costs arising from distortions in the market). I should add that this opinion is vendor neutral. I don’t care who it is or how Free Software is supplied.

If we are to achieve this nirvana we need to approach those we are seeking to influence in terms that are meaningful to them. This is not always easy but that is not an excuse not to try. And it may require several goes. Additionally if one is seeking to influence politicians or administrations is is easier to go with the grain of things than start again somewhere else.

With that in mind and prompted by the FSP, it seems right to put my drafting where my opinions were. Accordingly the OSC has created a draft form letter that hope as many people as possible will send it to the candidates in their constituency.

Dear…

Support Implementation of draft European Interoperability Framework V2 “EIF V2″

As you are a candidate in the forthcoming elections for the European Parliament I am writing to seek your support for a simple measure that will help citizens, businesses and European society.

Information and Communications Technology (ICT) has become a critical part of European infrastructure; a modern economy cannot function without it.

Optimal choices in ICT need a European policy on interoperability in ICT.

Interoperability means it does not matter how you mix and match the constituent parts of ICT, they will just work with each other without problems or issues. Such choice also means that users of your ICT systems (e.g., users of European or national government on-line services) do not have to make ICT choices based on your decisions, e.g., having to use a specific web browser (that itself may require a specific operating system).

Many European and national ICT systems have been implemented using software which does not enable easy interoperability, and instead creates an effect where it becomes easier, and some cases necessary, to choose more of the same supplier’s products, and harder to choose competing products.

Moreover, once governments or local administrations have decided to use software that does not enable easy interoperability, that choice imposes a requirement for the citizen or customer to choose the same software.

This network effect prevents choice, competition and limits opportunities to promote innovation outside vendor control, in the whole European arena for ICT.

To have agreed as policy the (draft) EIF V2 ( http://ec.europa.eu/idabc/en/document/7728) will halt and eventually reverse this situation.

This draft has been criticised by vendors currently benefiting from the current uneven playing field, but its adoption would not prevent any vendor, current or future, from supplying ICT to European or national governments.

The EIF is not considered to by all to be perfect, but getting it firmly “inside the tent” would enable it to be improved. I urge you to adopt or adapt this letter and write.

You can find your existing MEPs and candidates here.

Gerry Gavigan