SYNOPSIS

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