The H.264 vs WebM discussion goes to the heart of how we define the term ‘standard’.  There are many interpretations of what exactly constitutes a standard, but central to the meaning of a standard is the notion of collaboration between companies and the creation of a viable ecosystem. Hence, standards are often tied to the idea of shared control and a defined governance process. Control can take many facets: the ability to contribute to the specification, the ability to change the specification, transparency etc.  People often conflate the concept of open standards and open source software and this is one area where confusion can be problematic.

Consider the case of Android.

Open source projects, like standards projects, usually have a defined governance process which dictates how changes are made to the code base (in the case of an open source project) and the specification (in the case of a standard).  The idea of single firm (or person) control of an open source project is commonly discussed and in many regards accepted (Linus Torvalds is considered the benevolent dictator or the Linux Kernel).  Android software is open sourced, supposedly free but if we examine the governance process we can see that it is controlled by one company (Google).  By that, I mean, anyone can contribute to Android, but which contributions make it to the final build is controlled by the governance model (hence by Google).

In the standards context, however, there has typically been much more concern about single firm control of a specification.  Witness lots of discussion over the years questioning whether the “benevolent dictator” title could be applied to Sun’s stewardship of the Java specification.  This concern exists because where a standard defines required interoperability interface information, vendors without a say in development may be placed at an extreme competitive disadvantage.  By contrast, in the open source context, a vendor can simply chose whether or not to use code from an open source project or write its own code.

So there should be concern when one company essentially sets the framework for the collaboration for the ecosystem and effectively controls both the inputs and outputs to the process.  WebM is clearly not a standard with an open and inclusive governance process, but instead  a technology that was developed by a single company in a closed process.

We are likely to see more of such discussions in the future, since a growing number of potentially important technologies (the SPDY project, a possible replacement for HTTP comes to mind).

Why is that?

The Web has evolved very well with simple hypertext and http protocols but we are now entering an era of greater complexity.  In this new era, it is critical that the new technologies are developed and managed by an open and inclusive process.  Ecosystems built and managed by one company will come under greater scrutiny.

That’s why the H.264 v.s. WebM discussion goes to the heart of what is a ‘standard’.

Background

The Web was initially not designed to deploy video content but users have always felt the need for video content. To fill in the gap for web based video, Adobe stepped in with Flash. Flash became a de-facto web standard and was deployed as a Web based plugin. This is normal for the Web – i.e. third party plugins are encouraged as a way to evolve the Web. Over time, the Flash plugin became the dominant de-facto standard for video on the Web. With HTML5, Web standards bodies have decided to create a new standard which supports the deployment of video on the Web natively (i.e. without a plugin). Overall, this is considered to be a good idea with the HTML5 standard seen as the official avenue to deploy (standards based) video. However, this left the question of which video format should be deployed within the next generation browsers. Which has resulted in the current debate between H.264 and WebM.

The players and the stakes

There is a lot at stake here, much like the VHS vs Betamax wars a generation ago. This is especially more so if we consider Web video will be a part of emerging mobile devices. Even though the H.264 format is a standard, there are some companies who own IPR related to the standard. MPEG-LA, the body which owns the IPR has made some concessions towards royalties but for many, including the Chrome group at Google, there remain concerns. The alternative is WebM, which is not a standard but is open source and royalty free. WebM is not a standard since it is developed by Google. It is open sourced but Google maintains the governance model (much as it does for Android). In contrast, H.264 is also open sourced BUT is not royalty free.

There is precedence with this move of one person/entity maintaining the governance model – such as Linux with Linus Torvalds – but when companies become custodians of an open source product, even when it is royalty free, there is an obvious conflict of interest and we see that with Google-Android. The rationale behind such a move from Google is self-interest i.e. encourage adoption of WebM when it is free, open sourced and royalty-free and hope that it becomes a de-facto standard for video and usage patterns could be captured for marketing.

Observations and Conclusions

A lot is at stake here but here are some observations:

- Adobe used a proprietary extension to the Web to solve a practical problem. Thus, Adobe was an innovator.

- The h.264 standard includes IPR.

- The free and open source initiative is actually controlled by one company (through the governance model).

- Two products in the same company (Chrome and YouTube) are following somewhat different strategies with respect to video

The only conclusion we can draw is: such paradoxes increasingly common

There is a curious paradox which we are seeing increasingly. We see closed systems built on open standards and open source. I illustrate the phenomenon giving three instances below (Apple and Facetime, Open source and the Cloud and SPDY – the proposed new protocol from Google to replace HTTP). I seek comments on these.

APPLE AND FACE TIME

Face time is a mechanism on the new iPhone 4 devices for person to person video calling. Face time includes a whole slew of Open standards (source imtc blog) including H.264, AAC, SIP, STUN, TURN, ICE, RTP, and SRTP. For instance, H.264 is a video compression standard; AAC is an advanced audio coding standard, SIP (Session Initiation Protocol) is the de-facto standard of IP Communications solutions, including both Voice and Video communications; STUN, TURN and ICE are typically used together to support Firewall and NAT traversal functionality; RTP (Real-time Transport Protocol), is used in Voice and Video over IP implementations to carry over real-time media; SRTP supports encryption, message authentication and integrity and is widely used in both IP Video and Voice implementations.

Thus, we have a wide range of open and industry standards but collectively, the Apple Face time system is closed and not interoperable. By that, I mean the system can only be used to make video calls to another person on iPhone version 4 (not even previous versions of the iPhone) on wifi (cellular connections will not do!). This totally goes against the principles of network effects and interoperability but nevertheless it is a system getting a lot of traction in the press whereas the many previous attempts to create a standardised person to person video calling from standards bodies like 3GPPP are yet to be accepted by the industry commercially from (3GPP R4 onwards).

CLOUD AND OPEN SOURCE

There has been a lot of discussion for the Cloud computing and Open source. But much of it is vendor driven and does not really address the core principles behind the issue. Hence, it was interesting to see this blog from James Urquhart – The intersection of open source and cloud computing.

To summarise the key discussion in the above blog: (emphasis mine)

1) The definition of IT infrastructure has shifted significantly in the last 15 years or so, and much of that term now encompasses software as well as hardware. Operating systems have long been considered infrastructure in the world of client-server. Middleware and data bases, such as J2EE application servers and relational database management systems have also been largely described as common infrastructure.

2) A very common practice in enterprise IT organizations is to create standard builds of key software infrastructure stacks, to create a common operations framework on which application code is the only variant–at least in theory.

3) As many of these infrastructure components shifted to open-source options, they received a tremendous amount of attention from application developers. The reason for this was two-fold. The first was the fact that these projects were available for download for free–a characteristic the average developer loves in tools and infrastructure. The second is that developers were free to manipulate the entire software infrastructure stack if they so chose–though most rarely, if ever, actually did so.

4) Developers who wanted to play with infrastructure code were able to do so for two reasons: Firstly, the source code and instructions for building the software were freely available for manipulation on the developer’s own system and secondly, the developer could then build and deploy the software on said system to test and then utilize any changes.

5) What changes in cloud computing is that deployment of infrastructure software is strictly under the control of the cloud service provider. If I’m a user of Google App Engine, for example, I can’t go into the source code for their management systems, change something to suit me, and push it out to the wider Google service environment. Of course, we want it that way–it would be ridiculous to allow anyone who wants to change the way App Engine works to affect all other users of that environment. The security implications alone make that completely unreasonable, much less the other operational problems it would present.

6) Which means that the only users of open-source infrastructure projects in the public cloud are the cloud providers. They may see themselves as responsible users of open source and contribute back, or they may not. In any case, the incentive for the average application developer to delve into infrastructure code is weakened, if not outright removed.

This last point is critical – there is no real incentive for the average developer to contribute code to open source cloud initiatives and even if they did so, there is no guarantee (ex the Google App Engine example above), that such changes would be accepted. Thus, open source and cloud have some incompatibilities by the above perspective.

SPDY – THE NEW PROPOSED OPEN SOURCE REPLACEMENT for HTTP from Google

Google wants to speed up the Web by ditching HTTP and replacing it by a new protocol called SPDY. In a nutshell (source Wikipedia), SPDY is a TCP-based application-level protocol for transporting web content. Created by Google, the goal of SPDY is to reduce web page load time. This is achieved by prioritizing and multiplexing the transfer of several files so that only one connection per client is required. All transmissions are SSL encrypted and gzip compressed by design (in contrast to HTTP, the headers are compressed too). Moreover, servers may hint or even push content instead of awaiting individual requests for each resource of a web page.

This is all well and good but as the ars technica article points out there are some issues:

1) Mandatory use of SSL is not always needed: So should we all praise Google and switch to SPDY forthwith? Not quite yet. With the mandatory SSL encryption and gzip compression, SPDY will hit server and client CPUs much harder than traditional HTTP. Of course HTTP also runs over SSL in many cases, but there’s also lots of content out there that doesn’t need encryption. Making SSL mandatory is a strange move that has the potential to increase the number of people who don’t bother getting a proper certificate for their server, meaning that users will become even more blasé about ignoring the resulting security warnings. This, in turn, would pave the way for more man-in-the-middle attacks.

2) SSL on small devices: On small devices, SSL slows down the communication significantly, and because it can’t be cached, SSL-protected sites are often slower on big machines as well. The extra CPU cycles also mean that more servers are needed to handle the same number of clients.

3) Designed by web people rather than network people: It also looks like this protocol is designed by Web people, rather than network people. How the IETF applications area will respond to this effort is a big unknown. For instance, one thing that isn’t mentioned in the protocol specification is how a browser knows that it should set up a SPDY connection rather than an HTTP connection. Are we going to see SPDY:// in URLs rather than HTTP://? That wouldn’t work with browsers that don’t support the new protocol.

Some more comments:

1) Traditionally, bodies like IETF did not replace protocols wholesale. Rather, they added features incrementally thus providing a backward compatibility path to existing users.

2) The protocol may be open source but I expect that the governance model is still managed by Google. This has implications to which features are chosen to be implemented in the protocol.

3) The ‘network’ guys who may not be very happy with this could create their own version of the protocol and could also ‘open source’ it under their own governance model. This will create two versions of the protocol – both ‘open sourced’.

4) Historically, funding for the Internet protocol development came directly or indirectly from bodies such as the National Science Foundation and DARPA and companies did not get involved in low level protocols – open sourced or not.

While it is good to talk of evolution of HTTP, much more thinking needs to be done about the mechanism of this change and the belief that it is open source may not be sufficient in itself.

CONCLUSION

In all these cases, the interpretation of Open vs. Closed is relative. It depends on perspective. It also ties to innovation. The conclusion, if any, is that this is a scope for debate and that the previous, relatively simple demarcation between Open vs. closed may not be so clear with Cloud, Mobility and other emerging domains

The event is aimed at addressing some of the hot topics in the ongoing standards debate. As the importance of standards to our society is continuously increasing and gaining in technological complexity, compatibility and quality are key for competing companies who are striving towards establishing a common ground. Thus, the debate regarding proprietary standards vs open source based on collaborative efforts is central in mapping the future developments of ICT standardization.

Key questions up for discussion at this June event include: Should standards be based on open-efforts or on proprietary models? Should countries in Europe opt for a more specific model of standardisation? How should we consider the relationship between patents and standards, and what are the implications of not allowing standards to be protected by IPRs? Is the dichotomy between open and proprietary standards at all justified, or are these types of standards in fact complimentary?

The list of speakers include several prominent experts, including the keynote speaker Malcolm Harbour (MEP), which surely will create a high quality discussion.

For more information on the event, visit the Stockholm Network event page.

Ajit Jaokar spoke of the possibility that eHealth will take off in emerging markets and what the implications thereof could be. As an illustration, Jaokar mentioned the M-Pesa mobile payment service which took off in Kenya, serving 6.5 million subscribers by May 2009; such a service is yet to be deployed in Western countries. Jaokar argued that emerging markets have a way of solving real life problems which is likely to mean that eHealth innovation will take place in emerging markets. Further, the lack of infrastructure might actually provide further incentives, as it did in the M-Pesa case. The implications of such a development for global standards are not clear but it is important to not only think of eHealth as a ‘Western’ concept.

Highlighting the fact that the healthcare of yesterday is changing, and a new healthcare experience is emerging, Helen Disney discussed the challenges facing us in ‘the post-bureaucratic age’. New technology can revolutionize the way in which governments and citizens interact and move towards a bottom-up approach; but this requires the development of standards to build trust in new systems. Interoperability is one of the main challenges we are facing as companies are set to compete on delivering eHealth services. More open, network systems will benefit patients but at the same time it will be less easy for governments to intervene, argued Disney. This will ultimately affect which standards are going to be widely used. Further, Disney raised the question whether some of the poorest patients, who lack internet access, face a risk of being left behind in the eHealth-age.

Keith W Boone provided valuable input on US eHealth policy. He expressed concerns over the shotgun approach taken by recent US initiatives and called for more coordination in standardization efforts. Further, Boone was critical to the fact that there is no US ‘national program’, rather conflicts within government and between SSOs are impeding developments. Governments can help by offering a consolidated voice, setting national goals and driving standardization efforts. Unified efforts across the ICT spectra is needed to look after national interests.

Denise Silber expressed her optimism over Health 2.0 services as a driver of eHealth innovation and development. She drew the attention to existing services; blogs, wikis, search engines etc, and pointed to the fact that these are available by computer or mobile phone and contributing to participatory medicine. Lack of standards is not the issue, Silber argues, web to web synchronization is already possible. Security should not be an impediment either, online banks have succeeded and so should healthcare. Rather, the obstacle lies in data not being electronically available or safely portable. Silber called on doctors and laboratories to digitize their information and leave the rest to participatory medicine.

Recognizing that seamless access to information is important in eHealth, and that standards are vital in achieving this, Jay Kesan expressed concern over the likeliness of governments’ early involvement in the standardization process, choosing winners (and losers) prematurely. The reason for this, he said, is because the governmental role in healthcare is not as challenged as that in other sectors. Kesan argued that it is the ICT private sector that are the domain specialists and that they must be allowed to work towards standardization, jointly developing standards within private SSOs. Thus, competition should be fostered among private firms developing downstream, innovative, proprietary technologies relying upon ICT standards. Learning from past behavior, Kesan also argued that US authorities are more likely to focus on spectrum management and setting power ratings to avoid interference, while letting different industry solutions and standards compete with each other, European authorities will be prone to mandate interoperability.

Also, prior to the forum Talkstandards conducted an exclusive interview with David Ingram, Founding Chairman of openEHR. Ingram spoke of the difficulties of gathering all challenges of eHealth under one common umbrella, and expressed concern over governments sometimes being excessively enthusiastic. It is vital that governments appreciate the scope of ICT standardization and development, as to handle the challenges properly. The approach to eHealth should be practical and empirical, Ingram said, and welcomed the fact that practical progress toward interoperability is actively sought. Although difficult barriers to eHealth implementation exist in Europe which might be hard to overcome, Ingram is optimistic with the direction developments are taking. Ultimately, Ingram said, implementation is the best way to achieve progress since it offers a sense of learning-by-doing.

The discussion around these topics is bound to continue. Please visit the Open Forum Event Page for further reading.

Part III: Openness, implementation and governance

(This is the last of three parts of the interview. Read Part I on The future of eHealth here, and Part II on eHealth in an international perspective here.)

Talkstandards [TS]: openEHR is well known for its advocacy of open standards and specifications, what is the rationale behind this view?

David Ingram [DI]: Insecurities are more easily avoided and safety is promoted by allowing users to “open the hood” of a specification.

This conjecture is based on my own experience, coming from physics and moving into medical services and being close to the implementation of health IT, as I have often witnessed a discrepancy in how users think a system will work and how it actually functions. When people can view the specifications beforehand they are more prepared on what they get. This helps implementation. Keeping an open process also helps making specifications better.

The issue of IPR is complex but I believe that open source is important in academic areas, it helps sharing and handling of information and contributes to a stronger development process. I also believe that there is an issue with patenting something that everyone uses; it would be like Pythagoras patenting his theorem. Open source specifications provide a body of knowledge that can serve as public education.

TS: The three usual activities of openEHR are said to be “…implementation, implementation, implementation”. How far has Europe come in implementing eHealth technologies? And what are the main barriers for further deployment?

DI: I believe that implementation is important because it offers a learning-by-doing approach to answering questions. There is much implementation in the process and healthcare is getting constantly better. Implementation of eHealth technology provides valuable knowledge and ensures that new solutions are built on a solid foundation and thus serves as a promoter of innovation.

The healthcare sector is traditionally conservative, putting much effort in maintaining ethical responsibilities, which to some extent could inhibit innovation. Although changes are coming fast, systems are evolving and we are constantly learning there is still a long way to go in developing eHealth solutions. We need to find a balance between innovation and professional assurance and I am optimistic about the direction developments are taking.

I do wish, however, that governments would prioritize moving further toward learning about the scope of the challenges we are facing and experiment with different solutions. More transparency need to be brought to the teamwork between organizations, governments, clinical practitioners etc, and openness in that collaboration is critical; this is also what we learned from the early NHS projects that brought into healthcare people with valuable knowledge.

TS: You have expressed a need to restructure the organization of openEHR and work to better meet the growing interest from different regions and sectors. Can you comment on this?

DI: I have stated that openEHR needs a new form of governance, mainly as recognition of the fact that the organization has grown to include many different stakeholders. The goal is to make barriers to adoption of our specifications as small as possible and provide a better public understanding of the practical details of the organization. openEHR has from the start been very flexible in the innovation of specifications, but providing a commercial interface as an open source environment for adoption has taken a bit longer.

We recognize that the currently small executive group brings agility and flexibility but it can also stand in contrast to the image of a truly democratic organization. Bringing openEHR to where we are today has taken time and resources we simply cannot continue to spend. We are actively seeking partnerships with other organizations of which the most predominant are those with IHTSDO and EuroRec. This sort of partnerships will offer us a chance to follow other examples of basic principles and practical approach, but also to bring governance forward and handle the growing size of openEHR.

Part II: eHealth in an international perspective

(This is the second of three parts of the interview. Read Part I on The future of eHealth here, and Part III on Openness, implementation and governance here.)

Talkstandards [TS]: There is a significant difference between health care systems in the USA and Europe. How are these differences reflected in eHealth standardization in your opinion?

David Ingram [DI]: Without being too specific, I think it is important to recognize the cultural differences that separate the USA and Europe. Healthcare in Europe is sometimes characterized as “socialized medicine” in the American debate while the US healthcare system is sometimes giving negative vibes in Europe particularly when it comes to the lack of universal coverage.

However in terms of health informatics, innovative companies in health information technology emerged earlier in North America than in Europe and similarly, academic progress in the area was making progress earlier in the US. This is because the North American industry came to recognize the need to build bridges between different systems and applications at an early stage, thus working towards interoperable standards.

In Europe, an educational gap between clinical practice and science on the one hand and information technology on the other contributed to bringing the clinical challenge of information technology into focus later. Progress was sought through clinical practice rather than IT.

Some welfare states in Europe has a problem of scale; managing healthcare for a population of 5-10 million is easier than for a population of 50-60 million. Governments can and should make priorities for industry and the health care sector. New cooperation between industry and government is needed to handle the challenges at hand. This can also be vital in avoiding lock-in in outdated technologies, which is a dangerous trap in the fast moving IT sector. This is an important rationale for openEHR to be open; to maximize the possibility to detect and adapt to new and superior technology.

TS: Health care markets have historically been local and national. Is it possible that eHealth and ICT standards contribute to the longstanding European vision of a single market for healthcare services?

DI: The European single market is an important economic driver but considerable impediments exist, e.g. cultural, financial and political barriers, which mean that full integration will take time. I do believe that the goals are good, but it is key to have a bottom-up approach. Change needs to come from the grass root level. One particularly challenging task in this perspective is to reach harmonization of data.

In order to create a single healthcare service market, trust and understanding are vital elements. It is important not to generalize as patient preferences differ between areas of healthcare. For certain services familiarity is essential for assurance while in other areas patients are more open to evidence-based and innovative treatment.

Part I: The Future of eHealth

(This is the first of three parts of the interview. Read Part II on eHealth in an international perspective here, and Part III on Openness, implementation and governance here.)

TalkStandards (TS): There is currently a great deal of political hopes that eHealth can improve health care. Are these hopes realistic?

David Ingram (DI): The greatest challenge for eHealth today is trying to collect the disparity of ideas and efforts under one single umbrella to gain sufficient momentum and progress. Depending on the specific issue, hopes may or may not correspond with prospects. Generally, I am afraid that governments tend to be excessively enthusiastic about getting eHealth services up and running. Sometimes they do not fully realize the complexity of standardization processes of IT solutions.

Today, information technology is embedded in everything that we do. It has been a long learning process. Unfortunately ICT is sometimes taken for granted, and solutions are expected to come automatically. Therefore, governments run into trouble when trying to build a complex system. Technology is constantly evolving and we must learn how to best exploit these new technologies to manage information in order to reap the full benefits of eHealth.

TS: A distinguished feature of the openEHR is the way in which the patient is put at the center of development. What are the outlooks of creating a system where the patient fully controls his or her information?

DI: This is an interesting issue as we already see this sort of systems developing today. There are many long term treatments that need regular and careful monitoring. An example is system of 5000 patients with a coagulation deficiency who can regularly sample blood autonomously and upload the result to their medical institution for analysis.

However, it is important not to generalize when discussing this issue. There are territories where patients are reluctant to accept autonomous care, where they need the assurance of being under professional care and responsibility. In these cases they rather visit hospitals or a general practitioner in person. However, there can be different areas where patients could request autonomy and there is no certain rule that applies since patient preferences differ.

TS: What important trends do you see in the near future and what role is openEHR playing in this development?

DI: First and foremost, I welcome that the challenge of accomplishing practical progress toward interoperability is being addressed. Many different stakeholders – public as well as private – are involved in eHealth development and need to collaborate. We need to capture information as close to the physical encounter as possible and simplify it in order to facilitate sharing. This requires clear specifications which can serve to give us an overview of each patient’s information.

Another important trend is trying to understand and learn how genomics interact with treatment, especially for cancer patients. 30-40 years ago treatment policies mainly included “weed-killers”, which while targeting the malignant cancer cells, also caused much damage to healthy tissue. Today, with the use of IT systems, we can gather data which allows us to analyze which patient responds to what treatment. As a result disease profiling allows customized treatment, for instance oncology has moved towards a more efficient management of cancer. With the combination of making healthcare delivery better and managing individual data better in the long term, personalized treatment is now a reality.

In reality, openEHR is still a relatively small player. Our goal is to provide base standardization that can be adapted to a shared infrastructure as well as being adapted to local requirements, which often vary. Our approach is empirical and pragmatic, which in our opinion is the best way to contribute to the systemic landscape.

Biography David Ingram, Professor of Health Informatics, University College London

David Ingram is Director of the Centre for Health Informatics and Multiprofessional Education (CHIME) at University College London. After undergraduate Physics at Magdalen College Oxford, his career posts have been in industry, the National Health Service and University Medical Schools. CHIME is active in a wide range of international research programmes, and offers an extensive, multi-disciplinary educational programme, in quality, information and governance for health. The work of CHIME is founded on close working partnerships, with health service professionals, industry and community groups, and contributes to every-day services within the NHS and further afield.

David Ingram’s work in health informatics has covered contributions in the areas of mathematical modelling of biological and clinical systems, informatics in medical education, and formal methods for modelling health information requirements and architectures. Since 1990, he has been co-ordinating partner and partner in six major EU Health Informatics Framework Programme projects, focusing on health record architecture, implementation and standards, internationally. He is currently a principal investigator in the Medical Research Council e-Science Programme (Clinical e-Science Framework project, CLEF). He is active in research on representation of knowledge about inherited diseases. In 2003, CHIME was officially designated as a World Health Organisation Collaborating Centre, working on genetics knowledge management for patient advisory systems.

David Ingram’s professional activities include membership of the MRC Health and Bioinformatics Advisory Board, the national e-Science Advisory Board, the eScience Advisory Board of the Central Computing Laboratory for the Research Councils and the UK Council for Health Informatics Professions. He is the founder and chairman of the board of the openEHR Foundation, which is dedicated to sharing of standardised and open source software to support interoperable electronic health records. He is a Trustee of Starthere, an innovative charity which is establishing a national, highly accessible network of electronic signposts to local healthcare support services. He is international advisor to the EU project promoting health informatics in the accession states of the EU. He was elected Honorary Member of the Royal College of Physicians of London, in 1999, in recognition of his contributions to medical science.

Like many people, I am a fan of HTML5 and recent developments in the evolution of HTML5 indicate that it will now become the technology of choice for all browser vendors. Flash is the current de-facto web standard for video. With HTML5, we won’t need the embedded flash plug-in since video will be rendered natively in the browser. This is a good development of course.

But it is not that simple.

If you use flash (a proprietary but de-facto format), a majority of current web users can render video (with a free plug-in). If you don’t use flash, the option is H.264 codec, which has licensing requirements from MPEG LA. The Mozilla browser supports another alternative – the open source OGG Theora format, but there are some licensing requirements for OGG Theora which are unclear. Google has acquired On2 supposedly for the intention of open sourcing it with a view of solving the above problem.

Thus, the alternatives to Flash are H.264, OGG Theora and On2, the future directions of all are not clear yet.

If we ‘flash back’ ten years ago, Flash has been a great boon for the Web and has brought the Web to its current state even with a proprietary format. The question is – what will we see ‘flash forward’ in the next 10 years?

Clearly, HTML5 will have a significant role to play in the next decade. This means, the Web becomes a platform. However, the ‘flash back – flash forward’ story illustrates the point that proprietary formats have a role to play in innovation at the initial stage of a new technology. In other words, the Web video has taken more than ten years to catch up through HTML5. One could argue that pragmatic developers will choose multiple options. This will mean ‘fragmentation’ but it will also mean that in a practical sense, certain features like video will take a longer time to standardise

Thus, Flash will have a role to play even in the ‘flash forward’, i.e. next decade.

As a broader concept, the story illustrates that while standards catch up eventually, proprietary formats have a role to play in the initial stage of the evolution of new innovation and subsequently, we will see a mix of standards.

Defining ‘Open’ is one thing, Defining ‘Open Business models’ is more complex and sometimes contradictory. So, the challenge is to think of Open business models on the basis of the ‘Open memo’. Let’s consider the example of Vinton Cerf referenced in the memo who defined the TCP/IP protocols that are the foundation of the Internet. TCP/IP is a textbook case of Network effects. However, note that in this case, there was a complete separation of the network effect and it’s business model. In contrast, there is a subtle but important difference when an organization creates a network effect through the Open philosophy (which Google has done), but at the same time seeks to ‘harness’ the benefits from that network effect (which is different from TCP/IP approach). The above point is the main reason for the contradictions that we see in the memo which others have also pointed out.

Gartner has a very interesting take on this in a blog called the Truth of Open in response to the memo. Gartner says:

Openness is by and large a strategy to reduce operating costs and remove supply chain dependencies. Open is not a revenue engine in its own right. In that regard, Rosenberg’s observation about sustaining competitive advantage through closed system are still valid. The only real change is that organizations are increasingly understanding how to balance both closed and open systems.

The truth is that closed systems still win. Open systems, practically speaking, are basically good for making others lose. The art of business in the 21st century is figuring out how to open up your suppliers’ and competitors’ business while keeping yours tightly sealed. And in that endeavour Google has proven highly successful.

In my view, the crux of creating a business model based on the Open philosophy lies in maintaining a leverage of control or in creating a barrier to entry. So, how many ways can we create a business model based on ‘Open’? Here is my list. Happy if you can suggest more.

a) Open source governance models: I have said this before Open is the new closed? – Bringing transparency to Open source by separating Open source licensing models i.e. Open source governance models are quite different from Open source development models and governance models are often ‘closed’.

b) Making others lose: As the Gartner link refers above, Open systems are a competitive strategy to reduce costs. In an extreme case, that involves making costs equal to zero. Better still if someone else is charging money for the same (software) product (Note that the model cannot work with hardware i.e. the incremental production costs of software are zero. Which helps leverage the model)

c) Abstraction: This is the classic business model for network effects i.e. create the value at a higher level of abstraction (in this case advertising). However, note that this model has two parts: First you must create the network effect and more importantly, you must then maintain a leverage of control. In this case, the leverage of control is through the search algorithms so as to lead the Google dance and make your partners follow. It is interesting that the memo says that the search algorithm is closed because it could be ‘gamed’, which is a direct contradiction on the Open (source) philosophy i.e. Linus’s law “given enough eyeballs, all bugs are shallow.”

d) Contradictions: Often you have to live with contradictions if you want a business model for Open. For instance, I would have loved the ability to tweet from Google reader. But I don’t think that this feature is forthcoming since Google and Twitter are competitors … unless Google acquires Twitter…

e) Scale: can be a competitive advantage. The Internet was supposed to ‘get rid of the middleman’, in reality, after the dust of the last decade has settled, there are only one or two massive intermediaries in each sector (Google/Amazon/Ebay etc)

f) Speed of execution for users (not customers): Like scale, speed of execution also offers a competitive advantage especially if the products are accepted by customers. In many ways, acceptance by the customer is the real evidence of success as the memo also implies i.e. the ability to create products that are accepted by the customer. However, there is a caveat here; in reality, we have ‘users’ and not ‘customers’ since most people do not pay for the services. Since the service is free, it creates users and not customers leading to greater speed of execution and a platform that helps to reinforce other products creating a competitive advantage

g) Metadata: Metadata (and not data) is the real driver to the business model. Thus, there is a lot of data flowing through in street view, scanned books, maps and mobile but it is the metadata (derived from the data) which is the foundation of the business model.

So, that’s all I could think of.

Last week, I visited India and my tech-savvy six year old was on Google maps showing his grandparents his ‘route to school’ on Google maps. He is very familiar with Google maps and can navigate it far better than I can. This indicates that: In the end, customers will neither know nor care about most of the above if they like the product/service.

This is both good and bad; the privacy implications of Cloud, Metadata etc are only now being realised. Altruism aside, it will be interesting to see how Open systems business models evolve from Open systems themselves. Comments welcome!