Archive for December, 2010

ChromeOS is *not* for consumers.

Finally, after much delays, Google has presented its second operating system after Android: ChromeOS. Actually, it is not that new- developers already had full access of the development source code, and I had already the opportunity to write about it in the past; Hexxeh made quite a name for himself by offering a USB image that is bootable on more systems, and providing a daily build service to help others try it at home. Google launched a parallel pilot program, delivering to many lucky US citizens an unbranded laptop (called Cr-48) preloaded with the latest build of ChromeOS; initial reports are not overall enthusiastic, due to problems with the Flash plugin and trackpad responsiveness to gestures; in general, many of the initial adopter are perplexed about the real value of such a proposition. And the explanation is simple: it’s not for them.


The reality is that ChromeOS is a quite imaginative play designed to enter the enterprise market – and has nothing to do with consumers, or at least it does have only limited impact there. Let’s forget for a moment the fact that the system does have many, many shortcomings and little problems (like the fact that sometimes you are exposed to the internal file system, for example, or that the system is still not fully optimized, or that the hardware support is abysmal). Many observers already commented on the device itself, like Joe Wilcox, Mary Jo Foley or Chris Dawson; what I would like to add is that Google is using the seed devices to collect end user experiences to focus the remaining development effort to create what in the end will be a different approach to enterprise computing – not for consumers. It is not about thin clients: the economics of such devices has always been difficult to justify, with the substantial expenditure in servers and infrastructure; just look at the new refreshment of the concept, in the form of VDI, and despite the hotness of the field, actual deployments are still limited.

Web-based applications change this economics: the only thing that needs to be delivered to the client is the payload (the page, js files, images, and so on), data persistence and identity (authentication, authorization and accounting). All three can be done in an extremely efficient way; the cost per user is one or two orders of magnitude smaller than traditional thin client backends or VDI. It is true that not all apps are web applications, but I believe that Google is making a bet, based on the great uptake of modern web toolkits, javascript and metacompilers like GWT. For those apps that cannot be replaced, Citrix is providing a very nice implementation of their Receiver app – giving a full, uncompromised user experience directly in the browser.

Let’s consider what advantages does this approach bring to the enterprise:

  • Activation: you don’t need an engineer to deploy a ChromeOS machine. Actually, anyone can do it, and without the need for any complex deployment server, initial authentication or activation keys. It works everywhere there is a form of connectivity, and as soon as you have completed it, your desktop environment is ready with all the links and apps already in place. It means: no need for large helpdesks (a limited support line is sufficient); no need to fiddle with apps or virtualization desktop layers, you can do it from an hotel room… everywhere you are. Your machine stop working? You activate another.
  • Management: There is no machine management – all activities are based on the login identity, and machines are basically shells that provide the execution capabilities. It means that things like hardware and software inventories will not be necessary anymore, along with patch deployment, app supervision, and all those nice enterprise platform management things that add quite a lot of money to the IT licensing budgeted costs.
  • Security: Since there are no additional apps installable, it is much easier to check for compliance and security. You basically have to log every web transaction on your web app-which is fairly easy. There is still one area that is uncovered (actually, not covered in any current commercial operating system…) that is information labelling, and I will mention it later in the “still to do” area.

So, basically ChromeOS tries to push a model of computation that is based on something like 90% of apps as web-based applications, that use local resources for computation and the browser as the main interface; and the remaining 10% through bitmap remotization like Citrix (I bet that it will not take much time to see VMware View as well). To fulfil this scenario Google still needs quite some work:

  • They need to find a way to bring ChromeOS to more machines. If the enterprise already has its own PCs, they will not throw them out of the window. The ideal thing would be to make it a bootable USB image, like we did for our own EveryDesk, or make an embeddable image like SplashTop. The amount of reinvention of the wheel that is coming with ChromeOS is actually appalling – come on, we did most of those things year ago.
  • Google has to substantially improve management of the individual ChromeOS data and app instances. There must be a way for an enterprise to allow for remote control of what apps can and cannot be installed, for example – to preload a user with the internal links and data shared to all. At the moment there is nothing in this area, and I suspect that it is better for them to develop something *before* initial enterprise enrolments. Come on, Google, you cannot count only on external developers for filling this gap.
  • The browser must implement multilevel security labels. That means that each app and web domain must have a label, cryptographically signed, to claim what “level” of security is implemented, and how information can flow in and out. For example, it must prevent secure information from the ERP application to be copied into FaceBook, or securely partition different domains. A very good example of this was the Sun JDS trusted extensions, unfortunately defunct like JDS itself. This is actually fairly easy to implement in the browser, as the only application that can access external resources and copy and paste between them – and Chrome already uses sandboxing, that can be used as basis for such a label-based containment. This would give a substantial advantage to ChromeOS, and would open up many additional markets in areas like financials, banking, law enforcement and government.

So, after all, I think that Google is onto something, that this “something” needs work to mature before it can be brought to the market, and that the model it proposes is totally different from what we have up to now. Noone knows if it will be successful (remember the iPad? Its failure was nearly assured by pundits worldwide…) but at least it’s not a boring new PC.


OSS is about access to the code

I have a kind of a fetish – the idea that source code, even old or extremely specific for a single use, may be useful for a long time. Not only for porting to some other, strange platform, but for issues like prior art in software patents, for getting inspiration for techniques or simply because you don’t know when it may be of use. For this reason, I try to create public access archives of source code I manage to get my hands on, especially when such codes may require a written license to acquire, but may then later be redistributed.

Up to now, I have prepared public archives of the following projects:

DOD OSCMIS: a very large web-based application (more than half a GB of code), created by the Defense Information Systems Agency of the US Department of Defense, and currently in use and supporting 16000 users (including some in critical areas of the world, like a tactical site in Iraq). I wrote a description here, and the source code was requested in writing during 2009. I am indebted to Richard Nelson, the real hero of such a great effort, for creating such a large scale release, that I hope will spur additional interest and contributions. I believe that I’m the only European licensee, up to now :-) The source code is available at the SourceForge mirror:

NASA CODES: One of my oldest collection-and recovered by pure chance. Many years ago, we used to order CDs with source code on it (would you imagine it? How victorian…) since downloading them through our 14.4KBaud modems would have required too much time. So I ordered the Walnut Creek CD archive of the NASA COSMIC source code archive, a collection of public domain codes (mostly in Fortran) for things like “Aeroelastic Analysis for Rotorcraft in Flight or in a Wind Tunnel”. They are mostly obsolete, but since COSMIC was turned into a money-making enterprise that requires quite a substantial amount of money, I enjoy the idea of providing an access to the original codes.  The entire list of software descriptions is available here, and the codes are browsable at

Symbian: Ah, symbian. I already wrote about the high and lows of the Symbian OSS project, and since Nokia plans to shut down everything and make the source code accessible only through a direct request for an USB key or DVD, I though that an internet accessible archive would have been more… modern. It is a substantial, massive archive – I had to drop all Mercurial additions to make it fit in the space I had available, and still it amounts to 6.1Gb, Bzip-compressed. It is available at

I have performed no modifications or changes on the source code, and it remains under its original licenses. I hope that it may be useful for others, or at least become a nice historical artifact.


No, Microsoft, you still don’t get it.

There is a very nice article, in Linux for you, with a long and detailed interview with Vijay Rajagopalan, principal architect in Microsoft’s interoperability team. It is long and interesting, polite and with some very good questions. The interesting thing (for me) is that the answers depict a view of Microsoft that is not very aware of what open source, in itself, is. In fact, there is a part that is quite telling:

Q Don’t you think you should develop an open source business model to offer the tools in the first place?
There are many basic development tools offered for free. Eclipse also follows the same model, which is also called an express edition. These tools are free, and come with basic functionality, which is good for many open source development start-ups. In fact, all the Azure tools from Microsoft are free. All you need is Visual Studio Express and to install Azure. If you are a .Net developer, everything is free in that model too. In addition, just like other offerings in the ecosystem, the professional model is aimed at big enterprises with large-scale client licensing and support.” (emphasis mine.)

The question is: is MS interested in an OSS business model? The answer: we already give out things for free. Well, we can probably thank Richard Stallman for his insistence in the use of the word “free”, but the answer miss the mark substantially. OSS is not about having something for free, and it never was (at least, from the point of view of the researcher). OSS is about collaborative development; as evidenced in a recent post by Henrik Ingo, “The state of MySQL forks: co-operating without co-operating”, being open source allowed the creation of an ecosystem of companies that cooperate (while being more or less competitors) and not only this fact increases the viability of a product even as its main developer (in this case, Oracle) changes its plans, but allows for the integration of features that are coming from outside the company – as Henrik wrote, “HandlerSocket is in my opinion the greatest MySQL innovation since the addition of InnoDB – both developed outside of MySQL”.

Microsoft still uses the idea of “free” as a purely economic competition, while I see OSS as a way to allow for far faster development and improvement of a product. And, at least, I have some academic results that point out that, actually, a live and active project do improve faster than comparable proprietary projects. That’s the difference: not price, that may be lower or not, as RedHat demonstrates; it is competition on value and speed of change.

Ah, by the way: SugarCRM, despite being a nice company with a nice CEO, is not 100% open source, since that by definition would mean that all code and all releases are under a 100% open source license, and this is not the case. As I mentioned before, I am not against open core or whatever model a company wants to use – especially if it works for them, like the case of SugarCRM. My observation is that we must be careful how we handle words, or those words start to lose their value as bearers of meaning.