Web versus Apps: what is missing in HTML5
Posted by cdaffara in divertissements on September 2nd, 2010
If there is a concept that is clear in the analysts’ minds is the fact that mobile (in any form) is the hot market right now. Apple’s iOS devices are growing by leaps and bounds, dispelling the doom predictions of our beloved Ballmer: “There’s no chance that the iPhone is going to get any significant market share. No chance. … 2% or 3%, which is what Apple might get” or dismissing the iPad as “yet another pc”. The reality is that new mobile platform are consolidating a concept - the idea of the App store, that is an integrated approach to managing and buying applications – and the idea of “apps for everything”, even for data that comes off straight from a web site, like the recently launched Twitter app for the iPad, that is – in my own, clearly subjective opinion – beautiful.
After all the talks about platform independence, portability, universality of HTML5, and so on – why Apps? why closed (or half-open) app stores, when theoretically the same thing can be obtained through a web page? I have a set of personal opinion on that, and I believe that we still need some additional features and infrastructures from browsers (and probably operating systems) to really match the feature set and quality of apps. If – or when – those missing pieces are delivered to the browser, the whole development experience will in my opinion return back to the web as a medium, substantially enlarging the potential user base and reducing the importance of a single OS to develop for.
User Interfaces: this is, actually, one of the easiest things. HTML5, CSS3, Canvas, and a whole bunch of additions (like WebGL) are already closing in on the most refined native UI toolkits. There is still a margin – of course – but that gap is closing fast. Modern toolkits like Cappuccino (one of my favorites, used to create the stunning 280slides tool) are quite comparable to native UIs, and the few remaining features are being added at a frantic pace (thanks in part to the healthy competition between Mozilla and WebKit).
Video: actually, WebM is in my tests a very good alternative to H264, in terms of quality and in decoding efficiency (in my tests, WebM playback uses 20 to 30% less CPU than the ffmpeg H264 decoder, which is quite a good result). As for quality, the results of MSU graphics and media lab codec comparison found out that WebM is approximately equivalent to the baseline x264 encoding; that is, good enough for most applications. The substantial drawback of WebM is at the moment the dreadful encoding time – 5 to 20 times slower than comparable, more mature encoders. Substantial effort is needed before WebM can become encoding-wise competitive.
2D and casual gaming: ah, the hard point of gaming on the web. Up to now, gaming has been mainly relegated to the Flash engine, and is one of the parts still not replicated well by HTML5, Javascript et al; in fact, Flash is quite important for the casual gaming experience, and some quite stunning games are based on flash, and comparable to native games (if you want to waste some time, look at RoboKill2 as an example).However, given the fact that no fully compatible open source flash player exist, there are still issues with the real portability and platform independence of flash gaming in general (despite the excellent improvements in Gnash and LightSpark; also, it may even be possible to see in the future a native translator to Javascript like the SmokeScreen project. Actually, there is a great deal of overlap of Flash with recent evolutions of Canvas/HTML5/Javascript – it is clear that the overall evolution of the open web platform is going in the direction of integrating most of flash functionalities directly within HTML.
3D gaming: There is at the moment no way to create something like the Epic Citadel demo, or Carmack’s RAGE engine on iOS. The only potential alternative is WebGL, that is (like the previous links) based on OpenGL 2.0 ES, and paints on the HTML5 canvas (that, in the presence of proper support for hardware compositing, should allow for complex interfaces and effects). The problem is that browser support is still immature – most browsers are still experimenting in an accelerated compositing pipeline right now, and there are still lots of problems that need to be solved before the platform can be considered stable. However, after the basic infrastructure is done, there is no reason for not seeing things like the current state of the art demos on the web; modern in-browser Javascript JIT are good enough for action and scripting, web workers and web sockets are stable enough to create complex, asynchronous event models. It will take an additional year, probably, until the 3D support is good enough to see something like WoW inside a browser.
Local binary execution: for those things that actually cannot be done by a browser, local execution is the only alternative. For example, having a complex VPN client embedded in a web page is something that would simplify the task of connecting to a web (or non-web) in an easy way without downloading any additional package. This model was demonstrated by Google in its ChromeOS presentation, showing off a game based on the Unity web player, ported to the Native Client (NaCl) environment. The problem of the initial implementation of NaCl was that the binary was actually not portable across cpu architectures; the new pNaCl (portable NaCl) uses the incredibly good LLVM infrastructure to generate portable bytecodes.
Payment: there is one thing that is sorely missing or incomplete, and that is billing and payment management from the web application. Within iOS, and thanks to iTunes and carrier interactions, paying even in-game or in-app is easy and immediate. There is no similar ease of use and instant monetization within web applications, at the moment. One of the missing things is actually the overall management of digital identities, that is inextricably linked to the payment possibilities and channels.
DRM: yes, DRM. Or content protection, or whatever. Despite the clear indication that DRM schemes do not work, there is no shortage of studios or content producer that want to ensure that there is at least a minimum form of “protection” against unwanted use. I don’t believe that this form of protection is useful at all, but I am not confident in people accepting this in the next 5 years – and this means that DRM should be possible in the context of the browser. Possible alternatives are the use of a ported content execution engine (imagine a video player based on pNaCl, that brings its own DRM engine inside). Or integrating an open source DRM engine like DReaM (if it survives the Oracle changeover, that is). This kind of tool can also help to prevent cheating in online games (imagine a WoW like game, based on Javascript: what prevents the user to change the code on the fly with something like GreaseMonkey?) and other multiplayer environments.
App stores: what is an app store? A tool to reduce searching costs, and in Apple iTunes model a framework for app management and backup. In a sense, something like this is possible right now with some browser/OS integration (the excellent Jolicloud has something like that right now, and with some additional support for web packaging formats and remote synchronization like Mozilla Sync this can become ubiquitous).
What do you think? Is there something else missing? Comments are, as usual, welcome…
Windows phone 7, Android, and market relevance
Posted by cdaffara in divertissements on September 1st, 2010
Updated: despite the Business Insider claims, the list of motives is actually a perfect copy of those mentioned by Steve Ballmer in a CNN interview, and I also found that the list of motives for the claimed inferiority of Android is actually from 2008, as can be found here. I found quite funny that basically the same motivations apply two years later for a different OS (in 2008 it was Windows Mobile 6.5, a totally different operating system), and are quite similar to the list of motivations from MS to avoid open source – namely, inferior user experience, hidden costs and IPR risks. Maybe Microsoft has not changed so much as it would like to claim.
A recent Business Insider post provided, other than a nice retouched photo of Google’s Schmidt with menacing red eyes, a snippet of conversation with an anonymous MS employee that claimed that Android “free” OS is not free at all, and its costs are much higher than the $15 asked by Microsoft as licensing fees. Having had my stint on mobile economics, I would like to contribute some of my thoughts on what is actually implied by the MS employee, and why I believe that some parts of it are not accurate. Before flaming me as a Google fanboy, I would like to point out that I am not affiliated with Google, MS, anyone else (apart my own company, of course), and my cellphone is a Nokia. Enough said.
OEMs are not using the stock Android build. All Android OEMs are bearing costs beyond “free.” That goes with the definition of OEM – it is hardly a surprising idea. My gripe with the phrase is that the author had, conveniently, conflated the concept of “free” as “freely available operating system” with “free as in I have nothing to do, everything is done for me for free”. The second concept is actually quite uncommon, and I had never met an OEM product manager that believed in something like that. It reminds me a lot of the old taglines used in the infamous MS “comparisons”, that were – with blessings from all – sacked from Microsoft web site. So, in conclusion: yes, you will bear costs other than downloading Android from GIT. And – surprise – I am sure MS will ask for engineering costs for adapting WinPhone7 for any adaptation outside the stock image.
Lawsuits over disputed Android IP have been costly for Android OEMs. (See Apple/HTC, as just one example.) Microsoft indemnifies OEMs who license Windows Phone 7 against IP issues with the product. That is, legal disputes over the IP in Windows Phone 7 directed at OEMs will be handled by Microsoft. This goes a long way toward controlling legal costs at the OEM level. Ah, please, Microsoft – you are so friend of OSS, and you still drum the “IPR violation” song? Anyway, I am quite sure that indemnification can be quite easily acquired, probably from Google or from a third party. It depends on the kind of IPR that the OEM itself does have; in some cases such a patent safety scheme is uneconomical. It is, in any case, a business decision – Symbian did not had indemnification either (or only as an additional product) but that did not stopped Symbian from becoming the most widely used mobile OS.
Android’s laissez faire hardware landscape is a fragmented mess for device drivers. (For background, just like PCs, mobile devices need drivers for their various components—screen, GPS, WiFi, Bluetooth, 3G radio, accelerometer, etc.) Android OEMs have to put engineering resources into developing these drivers to get their devices working. The Windows Phone 7 “chassis strategy” allows devices to be created faster, saving significant engineering cost. It’s essentially plug and play, with device drivers authored by Microsoft. This (apart from the use of the clearly pejorative mention of “fragmented mess” is naturally true. It is also – another surprise – the reason of Windows success, namely the external ecosystem of hardware devices, mostly unpredictable, that were basically developed and managed outside of Microsoft control. After much bashing of Apple’s “walled garden”, now Microsoft seem to imply that the same model that brought them success is now useless, and that to win in mobile you have to adopt Apple centrally managed hardware experience. It may be true, or not – but I suspect that hardware manufacturers will be more happy to create many permutation and device models, designed for different price points and different users, in a way that would be incompatible with MS central control and central device driver development. What happens if I need to push on the market a device that deviates from the MS chassis? Will MS write the driver for me, for free? What if it doesn’t want to write it? The chassis model is nice if you are Apple, and are selling basically a single (or a few) models; if you are going to market with many hardware vendors, you are forcing the same, undifferentiated hardware on all OEM – and this is a great no-no. How are you going to go against competitors that do employ exactly the same model, bill of material, same procurement channel?
Also, this phrase is a clear indication that someone inside of MS still don’t understand what (real) open source is about. The amount of engineering necessary for creating a complex product out of OSS is substantially lower than proprietary alternatives, as I demonstrated here and here; the driver development effort can easily be shared among many different projects that use the same component, lowering the development costs substantially.
Windows Phone 7 has a software update architecture designed to make it easy for OEMs to plug-in their custom code, independent of the OS code. We’ve seen the delays due to Android OEMs having to sink engineering resources into each and every Android update. Some Android OEMs skip updates or stop updating their less popular devices. Because of the unique update architecture, Windows Phone 7 OEMs don’t need to roll their own updates based on the stock build. Costs are reduced significantly. This is another part that is, until Phone 7 is out, difficult to judge. It is a part that I believe stems from an underlying error: OEMs add code to differentiate and to push branded apps and services, not because they have to compensate for an OS missing functionality (especially now, with Android 2.2; Android 1.5 and 1.6 needed some addition from third parties because of lack of features). Carriers, once sold a device, are not that interested in providing updates – after all, you are already locked in a contract. I had seen no official documentation on why Phone7 can be so modular that no engineering is needed even for custom layers on top of the user interface – we will see.
Android OEMs need to pay for licenses for many must-have features that are standard in Windows Phone 7. For example, software to edit Office documents, audio/video codecs (see some costs here), or improved location services (for this, Moto licenses from Skyhook, just as Apple once did). Of course, all of these license fees add up. I like the concept of “must have” – it is widely different for every user and company. For example, I am sure that using Google Docs or Zoho (or Microsoft Web office, that is quite good on its own) would go against the “edit Office documents” part; as for the audio/video codecs, of course you have to license them… unless you use WebM or similar. Or, like many OEM, you are already a licensee for H264 and other covered standards- in this case, you pay around 1$ per device. As for other services: I found no mention of location services from MS, at least not in the public presentations. If anyone has more details on them, I would welcome any addition.
Windows Phone 7 supports automated testing. Android doesn’t. When OEMs hit the QA phase of the development lifecycle, it’s faster and less expensive to QA a Windows Phone 7 device than an Android device. Again: if you have a single chassis, or a few of them, testing is certainly easier. However, there are quite a few testing suites that allow (through the emulator) to provide a very good automated testing facility.
Finally, Windows Phone 7 comes with great user experiences in the Metro UI, Zune, Xbox LIVE, Exchange, and Visual Studio for app development. Creating these experiences for Android is costly. They’re not baked into the stock build of Android. Well, there are quite a few tools for app development on Android as well. How, exactly, Exchange should be counted as a great user experience is something I am not understanding well, but that is probably a limit of mine.
In synthesis, the new MS concept is “we do it like Apple”. I am not sure that this can work for anyone that is not Apple, though; first of all, because up to now product engineering excellence was not among MS most touted virtues, and because this will in turn go against the differentiation trend that OEM and telcos are pushing to make sure that their brand lines remain unique and appealing enough. How many Phone7 devices can a telco carry? 1? 2? It is possible to imagine a custom Android device for every price point instead – some carriers like Motorola and HTC are already pushing 5,6 devices and more, and low cost handsets are adding even more to the segmentation mix.
OSS 4.0 and licenses: not a clear-cut choice
Posted by cdaffara in OSS business models on August 25th, 2010
The (always great) Matthew Aslett posted today on some of his most recent results on the future of OSS licensing, in what he calls “Open Source 4.0″, characterized by corporate-dominated development communities. This form of evolution was one of the prediction in my previous posts – not for ethical,or community reasons, but for entirely practical and economic reasons: collaborative development is one of the strongest model in all the 11 basic components that we have identified in the FLOSSMETRICS group. In fact, I wrote in the past something like
“Many researchers are trying to identify whether there is a more “efficient” model among all those surveyed; what we found is that the most probable future outcome will be a continuous shift across model, with a long-term consolidation of development consortia (like Symbian and Eclipse) that provide strong legal infrastructure and development advantages, and product specialists that provide vertical offerings for specific markets“
which, I believe, matches quite well Matthew’s idea about OSS4.0. One area where I am (slightly) in disagreement with Matthew is related to licensing; I am not totally sure about the increased success of non-copyleft licenses in this next evolution of the open source market. Not because I believe that he is wrong (I would never do that – he is too nice 
) but because I believe that there are additional aspects that may introduce some differences.
The choice of an open source license for a project code release is not clear-cut, and depends on several factors; in general, when reusing code that comes from external projects, license compatibility is the first, major driver in license selection. Licenses do have an impact on development activity, depending on the kind of project and who controls the project evolution. Previous studies that shown that restrictive, copyleft licenses do have a negative impact on contribution (for example in Fershman and Gandal, “Open source software: motivation and restrictive licensing”) has been refuted by other researchers (Stewart, Ammeter, Maruping, “Impacts of License Choice and Organizational Sponsorship on User Interest and Development Activity in Open Source Software Projects”). An interesting result of that research is the following graph:
What we found is that for non-market sponsors and new code, there is an higher development activity from outside partners for code that is released under a non-copyleft license. But this implies that the code is new and not encumbered with previous license obligations, like for example the reuse of an existing, copyleft-licensed project. The graph shows the impact on development activity in open source projects, depending on license restrictiveness and the kind of “sponsor”, that is the entity that manages a project. “No sponsor” is the kind of project managed by a non-coordinated community, for example by volunteers; “market sponsor” are projects coordinated by a company, while “nonmarket sponsor” are project managed by a structured organization that is not inherently for-profit, like a development consortia (an example is the Eclipse Foundation). The research data identified a clear effect of how the project is coordinated and the kind of license; the license restrictiveness has been found to be correlated with decreased contributions for nonmarket sponsors, like OSS foundations, and is in general related to the higher percentage of “infrastructural” projects (like libraries, development tools, enabling technologies) of such foundations.
In general,the license selection follows from the main licensing and business model constraints:
- When the project is derived from an external FLOSS project, then the main constraint is the original license. In this case, the basic approach is to find a suitable license from those compatible with the original license, and select among the possible business models the one that is consistent with the selected exploitation strategy.
- When one of the partners has an Intellectual Property Rights licensing policy that is in conflict with a FLOSS license, the project can select a MIT or BSD license (if compatible with an eventual upstream release) or use an intermediate releaser; in the latter case there are no constraints on license selection. If a MIT or BSD license is selected, some models are of difficult application: for example, Open Core and Dual Licensing are difficult to implement because the license lack the reciprocity of copyleft.
- When there are no external licensing constraints, and external contributions are important, license can be more or less freely selected; for nonmarket entities, a non-copylefted license gives a greater probability of contribution.
So, if you are creating a nonmarket entity, and you are free to choose: choose non-copyleft licenses. In the other situations, it is not so simple, and it may even be difficult to avoid previous licensing requirements.
The point on intermediate releasers require some additional consideration. An especially important point of OSS licenses is related to “embedded IPR”, that is the relationship of the code released with software patents that may be held by the releasing authority. While the debate on software patents is still not entirely settled, with most OSS companies vigorously fighting the process of patenting software-based innovations, while on the other hand large software companies defending the practice (for example SAP) most open source licenses explicitly mention the fact that software patents held by the releasing authority are implicitly licensed for use with the code. This means that business practices that rely on separate patent licensing may be incompatible with some specific OSS licenses, in particular the Apache License and the GPL family of licenses. The Eclipse Public License gives patent grants to the original work and to enhanced versions based on the original work but not to code not directly derived from the release, while permissive licenses like BSD and MIT give no patent rights at all.
If, for compatibility or derivation, a license that gives explicitly IPR rights must be selected, and the company or research organization wants to maintain the rights to use IPR in a license-incompatible way a possible solution may be the use of an intermediate releaser; that is, an entity that has no IPR on its own, to which the releasing organization gives a copy of the source code for further publication. Since the intermediate release has no IPR, the license clauses that require patent grants are not activated, while the code is published with the required license; this approach has been used for example by Microsoft for some of its contributions to the Apache POI project.
This may become an important point of attention for companies that are interested in releasing source code under an OSS license; most software houses are still interested in maintaining their portfolio of patents, and are not willing to risk invalidation through “accidental licensing” of IPR embedded in source code (one of the reasons why Microsoft will never sell a Linux based system).
As I wrote in the beginning, there is for a large number of consortia a clear preference for non-copyleft licenses; but it is not possible to generalize: the panorama of OSS is so complex, right now, that even doing predictions is difficult.
Oracle, Sun, Java: lawsuits mark the exit road
Posted by cdaffara in blog, divertissements on August 25th, 2010
I already wrote a few words on the Oracle/Google lawsuits here and here, and I would like to thank all those that found them interesting enough to read and comment on. I found recently a very interesting post by Java author extraordinaire, James Gosling, where he answers on some of his readers’ comments. In the post there are many interesting ideas, and a few points that I believe are not totally accurate – or better, may be explained in a different way. In particular, I believe that the role of Java in the enterprise will remain and will become “legacy”, that is stable, plain and boring, while the real evolution will move from Java to… something else.
James clearly points out the fact that JavaME fragmentation was a substantial hurdle for developers, and believes that in a lesser way this may be true for Android as well. While it is true that fragmentation was a problem for Java on mobile, this was a common aspect of mobile development at the time (go ask a Windows Mobile developer about fragmentation. And see a grown man cry, as the song says). The problem of JavaME was not fragmentation, but lack of movement – the basic toolkits, the UI components, most of the libraries for one reason or the other remained largely unchanged apart a few bug fixes. JavaFX should have been promoted much, much earlier, and would have had a great impact on software development, like (I believe) the more recent Qt releases from Nokia and their idea of declarative user interfaces.
If we compare with the rest of Java, we see a much stronger push towards adding libraries, components, functionalities: all things that made Java one of the best choices for software developers in the enterprise space, because the developers can trust Sun to update and extend their platform, making their job easier and faster. It was the same approach that made Microsoft the king of software: create lots of tools and libraries for developers, sometimes even trying to push more than one approach at a time to see what sticks (like Fahrenheit) , or trying very experimental and skunkworks approach, that later are turned into more mature projects (like WinG). JavaEE and JavaSE followed the same model, with a consistent stream of additions and updates that created a confidence in developers – and, despite all the naysayers, for enterprise software Java was portable with very little effort, even for very large applications.
JavaME was not so lucky, and partly to guarantee uniform licensing Sun was forced to do everything on their own (a striking difference with Android, that – if you check the source code – included tons of external open source projects inside) limiting the rate of growth attainable. Some features that now we take for granted (like web browsing) were not included as default, or implemented by vendors in inconsistent way because Sun never gave guidance on the roadmap and product evolution; multimedia has been mostly an afterthought, usually forcing developers to create (or buy) external libraries to implement anything more complex than a video or audio player. As I wrote before: JavaFX should have been announced much, much earlier, and not as a reactive answer to the competition, but as part of a long-term roadmap that JavaEE had, while the rest of Java missed.
This is, in my opinion, one of the real reasons for the lawsuit: Sun (now Oracle) was unable to create and maintain a real roadmap outside of JavaEE (and partly JavaSE), and especially for JavaME they constantly followed – never led. This, as any developer will tell you, is never a good position; it’s full of dust and you miss all the scenery. So, since Oracle is really more interested in their own markets (the DB and the applications) and not really caring about software developers, ecosystems or openness, they probably believe that lawsuits do have a better return on investment.
OpenWorldForum 2010: Join me in the OSS governance session!
I will have the opportunity to present our most recent results on the best practices for OSS adoption at the Open World Forum governance session, moderated by Martin Michlmayr (HP community manager) and Matteo Melideo (QUALIPSO project consortium leader). The program is available here, and packs quite a substantial amount of high quality talks. I hope to see you there!
The Open World Forum is the premier global summit meeting bringing together decisions-makers from across the world to discuss the technological, financial and social impact of open technologies, and to cross-fertilize ideas and initiatives in these areas. At the hub of the Free/Open Source revolution, the event was first staged in 2008, and takes place every year in Paris with more than 140 speakers from 40 countries, a 1,500-strong international audience and numerous conferences, workshops and think-tanks. The 2010 Open World Forum will be held on 30 September and 1 October, under the banner of “Open is the future: Open Innovation – Open Enterprise – Open Society”. Organized by a unique network of partners including the main Free/Open Source communities and most of the leading IT players worldwide, the Open World Forum is a must-attend event to discover the latest trends in open technology, business and social issues and to explore the future of Free/Open Source initiatives. It also offers a unique opportunity to share insights and best practices with many of the most respected visionaries, entrepreneurs and community leaders, and network with technology gurus, CxOs, analysts, CIOs, researchers, government leaders and investors from six continents. To request an invitation, please visit http://www.openworldforum.org
EveryDesk beta3 released – now available as a VirtualBox image!
I am quite happy to announce the release of the third beta of our EveryDesk flash-based desktop, now available in VirtualBox format as well – so you can try it out without the need of a USB key. EveryDesk is a reinterpretation of the Linux desktop. It executes from a 4Gb USB Key, and allows the user to run a modern and efficient Linux Desktop on most PCs without the need of changing or removing the native operating system such as Windows. Designed to be used in Public Administrations or as an enterprise desktop, EveryDesk is a real OS on a USB key, not a live CD, and as such allows for extensive customization and adaptation to each Public Administration need. It is the result of the open sourcing of parts of the Conecta HealthDesk system, designed using the result of our past European projects COSPA (a large migration experiment for European Public Administrations), SPIRIT (open source health care), OpenTTT (OSS technology transfer) and CALIBRE (open source for industrial environments).
There are more than 120 changes from the previous edition; among them, all the medical applications are integrated in the same image – so there is no need to have a separate edition for Health Care applications. Among the updates:
- Latest edition of the DICOM browser for hospitals and medical applications; now supports per-user monitor calibration.
- Integrated medical dictionary in OpenOffice.org
- Integrated the After the Deadline OpenOffice grammar checker
- LikeWise 6 Active directory integration tool
- A fast, efficient and very capable RDP, NX and VNC connection manager: Remmina based on FreeRDP
- The latest VirtualBox
- Several ancillary additions, like a large complement of fonts
To facilitate the final bug fixing, we made the boot process visible – that will be reverted to silent boot as soon as the final testing is completed. As usual, you will find the images at our sourceforge page.
Oracle/Google: the strategy behind Sun, Oracle and the OSS implications
Posted by cdaffara in blog, divertissements on August 15th, 2010
In my previous post, I tried to provide some details on what in my opinion were the most relevant legal and licensing aspects of the recently launched Oracle lawsuit against Google. I would like now to provide some perspective on what may have been the motives behind this lawsuit, and what are the possible implications for the Java and Open Source communities.
First of all, it is clear that, as I mentioned before, Google turned the lawsuit into a positive event for their (slightly battered) public image. By turning the lawsuit against Android into an attack to the open source community, Google effectively created a positive image, as David unjustly accused by the Oracle giant. It is also clear that the lawsuit itself is actually quite weak, focusing on a copyright claim that is very vague (given the fact that Google never claimed to use Java), and a set of patent claims for techniques that are probably not relevant anymore (especially in the post-Bilski era). One of the possible reasons for this is to be sure that even the widely different Dalvik machine would be at least partially covered; the other is the fact that all of Classpath was included in the OIN “System Components” covered technologies. Since both Oracle and Google are part of OIN, I suspect that Oracle wanted to avoid any potential complication coming from this “broken marriage”.
But – this is not the only relevant aspect. Actually, an angle that is probably more important is the impact of the lawsuit on Java, Java for mobile, Android and the OSS communities that were part of the Sun technology landscape.
Enterprise Java: no change at all. Java is a very strong brand among corporate developers, and I doubt that the lawsuit will change anything at all; in fact, all the various licensee of the Java full specification are on perfectly legal grounds, and face no problem at all. Despite the opportunistic claims by Miguel De Icaza (that suggests that Mono/C# would have been a better choice), there is nothing in the lawsuit that would imply that other Java or Java-related technologies may be impacted (actually, Mono and the CLR are in the same situation as Dalvik, actually).
Mobile Java: as I mentioned before, the lawsuit put the last stone on the JavaME grave. The only potentially relevant route away from the land of the dead could have been JavaFX; that was too little, too late – incomplete, missing several pieces, missing a roadmap, and uselessly released as a binary-only project. Android used the Java language, extended it with mobile-specific classes that were more modern and more useful for recent smartphones and even non-phone applications (like entertainment devices, automotive and navigation devices). It is not a surprise, that coupled with the Google brand name, Android surged in popularity so much as to become a threat.
Oracle OSS projects: Oracle has always been an opportunistic user of open source. With the term “opportunistic” I am not implying any negative connotation: simply the observation that Oracle dabbled in open source whenever there was an opportunity to reduce its own research and development costs. If you look at oracle projects, it is clear that all projects are related to infrastructural functionality for the Oracle run-time and for developers tools (using Eclipse as a basis). I was not able to find any “intrinsic” open source project started or adopted by Oracle that was not focused on this approach. So, for those projects, I believe that there will be no difference; for example, I believe that the activity on the Oracle-sponsored BTRFS project will not change significantly. Oracle, actually does not care at all if they are seen as “enemies”, or if their projects are not used anymore by others. What they care for is for their patches to be included in Linux. Remember that Oracle is an “old style” company; it does have two basic product lines: its database and its set of enterprise applications. Everything else is not quite necessary, and probably will be abandoned.
Sun OSS projects: as for Sun, there is a long preamble first. Sun has always been, first and foremost, an engineering company – something like Silicon Graphics in the past, or more recently Google. Sun had open sourced something of value whenever it was necessary to establish a common platform or protocol, like NFS or NIS+; but it was the advent of Jonathan Schwartz that actually turned things towards open source. The ponytailed CEO tried to turn the Sun behemoth towards a fully open strategy, but was unable to manage the conversion before being ousted out. It is a pity, actually – Sun could have leveraged its size, large number of technical partners and amount of technologies to become a platform provider like RedHat – but 10 times larger. The problem of this strategy is that it implies a large amount of cooperative development, and thus a substantial downsizing of the company itself. The alternative could have been the use of an open-core like strategy, for example creating a scalable JVM designed to auto-partition code execution on network of computers. The basic JVM could have been dual licensed, with the enhanced one released on a proprietary basis; this could have leveraged the exceptional Sun expertise in grid and parallel computing, filesystems and introspection systems.
But Sun never managed to complete the path – it dwindled left and right, with lots of subprojects that were started and abandoned. The embracing of PostgreSQL, its later abandonment, the latter embrace of MySQL, that was then not integrated anywhere; the creation of substantial OSS projects from their proprietary offering, but then losing interest as soon as a project started to become a threat for the proprietary edition. There is no surprise that despite the incredible potential, Sun never recouped much of their OSS investment (despite the great growth in their latest quarters, the OSS services remained a small portion of their revenues). Now that Oracle has taken control, I believe that Sun “openness” will quickly fade towards small, utilitarian projects – so, even if now everyone looks at Oracle with anger, noone at Oracle could care less.
Why oracle sued? The blogosphere is exploding with possible answers; my own two hypothesis are:
- Oracle found a substantial technology it acquired (Java) losing value in what is the hottest tech market today, namely mobile systems. Sun had no credible plan to update JavaME, no credible alternative, and thus Android (that is loosely java based) is at the same time a threat to an acquired asset and (from their point of view) a stolen technology. Since anyone can follow the same path, Oracle wants to make sure that noone else would try to leverage Java to create an unlicensed (and uncontrolled) copy.
- Oracle wants a piece of the mobile enterprise market, and the alternatives are unavailable (Apple does not want anything to do with Java, Blackberry is a JavaME licensee, Windows Mobile is backed by arch-rival Microsoft). Android is working well, grows incredibly fast, and Oracle wants a piece of it; Google probably rebuffed initial contacts, and now Oracle is showing the guns to make Google obey. I am skeptical, however, that Google would back down on what is becoming its most important growth path. The lawsuit itself is quite weak, and Google would risk too much by licensing the TCK from Oracle; they would basically destroy their opportunity for independent development. It is never a good idea to corner someone – if you leave no alternative, fight is the only answer.
I believe that the first one is the most probable one; Larry Ellison should know that cornering Google would not be sufficient to make them capitulate – they have too much to lose. But this will not be sufficient to create an opportunity for Oracle; I believe that the lawsuit will actually bring nothing to Oracle, and lots of advantages to Google. But only time will tell; the only thing that I can predict for sure right now is that Solaris will quickly fade from sight (as it will be unable to grow at the same rate of Linux) exactly like AIX and HP-UX: a mature and backroom tech, but nothing that you can base a growth strategy upon.
Oracle/Google: the patents and the implications
Posted by cdaffara in blog, divertissements on August 13th, 2010
Just as LinuxCon ended, Oracle announced that it has filed suit for patent and copyright infringement against Google for its implementation of Android; as an Oracle spokesperson said, “In developing Android, Google knowingly, directly and repeatedly infringed Oracle’s Java-related intellectual property. This lawsuit seeks appropriate remedies for their infringement … Android (including without limitation the Dalvik VM and the Android software development kit) and devices that operate Android infringe one or more claims of each of United States Patents Nos. 6,125,447; 6,192,476; 5,966,702; 7,426,720; RE38,104; 6,910,205; and 6,061,520.” (some more details in the copy of Oracle complaint). Apart from the slight cowardice of waiting after LinuxCon for announcing it, the use of the Boies Schiller legal team (the same of SCO) would be ironic on its own (someone already is calling the company SCOracle).
The patent claims are:
- Protection domains to provide security in a computer system
- Controlling access to a resource
- Method and apparatus for pre-processing and packaging class files
- System and method for dynamic preloading of classes through memory space cloning of a master runtime system process
- Method and apparatus for resolving data references in generated code
- Interpreting functions utilizing a hybrid of virtual and native machine
- Method and system for performing static initialization
Let’s skip the patent analysis for a moment, and let’s focus on the reasons behind this. Clearly, it is a move typical of mature industries: when a competitor is running past you, you try to put a wrench in its engine. That is a typical move, and one of the examples of why doing things by the book in this modern, collaborative world is wrong. Not only that, but I believe that previous actions by Sun made this threat clearly useless – even dangerous.
Let’s clear the table from the actual patent claims: the patent themselves are quite broad, and quite generic; a good example of what should not be patented (the security domain one is a good example; look at the sheet 5 and you will find the illuminating flowchart with the representation of: do you have the rights to do it? if yes, do it, if no, do nothing. How brilliant). Also, Dalvik implementation is quite different from the old JRE one, and I have strong suspicions that the actual Dalvik method is substantially different. But, that is not important. I believe that there are two main points that Oracle should have checked before filing the complaint (but, given the use of Schiller&Boies, I believe that they have still to learn from the SCO debacle): first of all, Dalvik is not Java and Google never claimed any form of Java compatibility. Second, there is a protection for patents as well, just hidden in recent history.
On the first point: in the complaint, Oracle claims that “The Android operating system software “stack” consists of Java applications running on a Java-based object-oriented application framework, and core libraries running on a “Dalvik” virtual machine (VM) that features just-in-time (JIT) compilation”. On copyrights, Oracle claims that “Without consent, authorization, approval, or license, Google knowingly, willingly, and unlawfully copied, prepared, published, and distributed Oracle America’s copyrighted work, portions thereof, or derivative works and continues to do so. Google’s Android infringes Oracle America’s copyrights in Java and Google is not licensed to do so … users of Android, including device manufacturers, must obtain and use copyrightable portions of the Java platform or works derived therefrom to manufacture and use functioning Android devices. Such use is not licensed. Google has thus induced, caused, and materially contributed to the infringing acts of others by encouraging, inducing, allowing and assisting others to use, copy, and distribute Oracle America’s copyrightable works, and works derived therefrom.”
Well, it is wrong. Wrong because Google did not copied Java – and actually never mention Java anywhere. In fact, the Android SDK produced Dalvik (not Java) bytecodes, and the decoding and execution pattern is quite different (and one of the reasons why older implementations of Dalvik were so slow – they were made to conserve memory bandwidth, that is quite limited in cell phone chipsets). The thing that Google did was to “copy” (or – for a better word – inspire) the Java language; but as the recent SAS-vs-WPS lawsuit found, “copyright in computer programs does not protect programming languages from being copied”. So, unless Oracle can find pieces of documentation that were verbatim lifted from the Sun one, I believe that the copyright part is quite weak.
As for patents, a little reminder: while copyright covers specific representations (a page of source code, an Harry Potter book, a music composition), software patents cover implementations of ideas, and if the patent is broad enough, all possible implementation of an algorithm (let’s skip for the moment the folly of giving monopoly protection on ideas. You already know how I think about it); so, if in any way Oracle had, now or in the past, given full access to those patents through a licensing that is transferable, Google is somehow protected there as well. And – guess what? That really happened! Sun released the entire Java JDK under the GPLv2+classpath exception; granting with that release full rights of use and redistribution of the IPR assigned on what was released. This is different from the TCK specification, that Google wisely never licensed; because the TCK license requires for the patents to be transferred to limit the development to enhancements or modifications to the basic JDK as released by Sun.
But, you would say, Dalvik is independent from OpenJDK, so patents are not transferred there. So, include the code that is touched by the patents from the OpenJDK within Dalvik – compile it, and make a connecting shim, include it in a way that is GPLv2 compatible. The idea (just an idea! and IANAL of course..) is that through the release of the GPL code Sun gave an implicit license to embedded patents that is connected with the code itself. So, if it is possible to create an aggregate entity of the Dalvik and OpenJDK code, the Dalvik one would become a derivative of the GPL license, and would obtain the same patent protection as well. That would be a good use of the GPL, don’t you think?
What will be the result of the lawsuit? First of all, the open source credibility of Oracle, already damaged by the OpenSolaris affair, is now destroyed. It is a pity – they have lots of good people there, both internal and through the Sun acquisition; after all, they are among the 10 largest contributors to the Linux kernel. That is something that will be very difficult to recover.
Second, Google now has a free, quite important gift: the attention has been moved from their recent net neutrality blunder, and they are again the David of the situation. I could not imagine a better gift.
Third, with this lawsuit Oracle basically announced the world that Java in mobile is dead. This was actually something that most people already knew – but seeing it in writing is always reassuring.
Update: Miguel de Icaza claims that “The Java specification patent grant patent grant seems to be only valid as long as you have a fully conformant implementation”, but that applies only to the Standard Implementation of Java, not OpenJDK. Sorry Miguel – nice try. More luck next time.
Update 2: cleaned the language on the phrase on patents, ideas and implementation that was badly worded.ù
Update 3: clarified the Dalvik+OpenJDK idea.
Estimating source-to-product costs for OSS: an experiment
Posted by cdaffara in OSS business models, OSS data on August 10th, 2010
One of my recurring themes in this blog is related to the advantages that OSS brings to the creation of new products; that is, the reduction in R&D costs through code reuse (some of my older posts: on reasons for company contribution, Why use OSS in product development, Estimating savings from OSS code reuse, or: where does the money comes from?, Another data point on OSS efficiency). I already mentioned the study by Erkko Anttila, “Open Source Software and Impact on Competitiveness: Case Study” from Helsinki University of Technology, where the author analysed the degree of reuse done by Nokia in the Maemo platform and by Apple in OSX. I have done a little experiment on my own, by asking IGEL (to which I would like to express my thanks for the courtesy and help) for the source code of their thin client line, and through inspecting the source code of the published Palm source code (available here). Of course it is not possible to inspect the code for the proprietary parts of both platforms; but through some unscientific drill-down in the binaries for IGEL, and some back of the envelope calculation for Palm I believe that the proprietary parts are less than 10% in both cases (for IGEL, less than 5% – there is a higher uncertainty for Palm).
The actual results are:
- Total published source code (without modifications) for IGEL: 1.9GB in 181 packages; total amount of patch code: 51MB in 167 files (the remaining files are not modified). Average patch size: 305KB, Patch percentage on total publisheed code: 2.68%
- Total published source code (without modifications) for Palm: 1.2GB in 106 packages; total amount of patch code: 55MB in 83 files (the remaining files are not modified). Average patch size: 664KB, Patch percentage on total published code: 4.58%
If we add the proprietary parts and the code modified we end up in the same approximate range found in the Maemo study, that is around 10% to 15% of code that is either proprietary or modified OSS directly developed by the company. IGEL reused more than 50 million lines of code, modified or developed around 1.3 million lines of code. Without OSS, that would have costed more than 2B$, required a full staffing of more than 700 people for an effort duration of more than 20 years. Through OSS, the estimated cost (using the more appropriate semidetached model) is around 90M$, with an average staffing of 150 people and an estimated project duration of 5 years. Palm has a similar cost (the amount of modified code is quite similar), but starting from a smaller amount of reused code (to recode everything would still require 12B$, 570 people and 18 years of work). We have to add some additional costs (for an explanation you can check my previous post on the proper use of COCOMO II and OSS, using the model by Abts, Boehm and Bailey) that would bring the total cost to a little less than 100M$ (still substantially less than the full cost of development from scratch).
Open Source allows to create a derived product (in both case of substantial complexity) reducing the cost of development to 1/20, the time to market to 1/4, the total staff necessary to more than 1/4, and in general reduce the cost of maintaining the product after delivery. I believe that it would be difficult, for anyone producing software today, to ignore this kind of results.
Addendum: I received some requests for specific parts of source code from people willing to check the kind of modifications performed. For Palm, the website provides both original source code and patches. For IGEL, I requested the access to the source code, and was kindly provided with a username and password to download it. Since the single most requested file seems to be the modified rdesktop, I have linked the GPL sources here.
About contributions, Canonical and adopters
Posted by cdaffara in blog, divertissements on July 30th, 2010
It is always strange to see the savage infighting that sometimes happens in the free and open source world – sometimes, like red in front of a bull, the net suddenly lights their flame-throwers and decides to roast someone. Today’s target is Canonical, makers of the Ubuntu distribution, accused of being leeches and “stealing” from the open source communities, giving little or nothing back, and profiting from that. The issue emerged from the publication of the Gnome census, where it emerged that Canonical As Sam Varghese writes, “Canonical derives the base for Ubuntu from the Debian project. It takes liberally from many free and open source software projects to produce a distribution. While this distribution is available for free download, Canonical is also basing a business on it, and developing ways and means of making money off Ubuntu.” (which is, probably, a crime). He wrote something similar before, and Greg DeKoenigsberg has an even more vitriolic argument in his post “Red Hat, 16%. Canonical, 1%”, that happily buries under the ground Canonical, Ubuntu and most Ubuntu fanboys.
Well, you’re all wrong.
Not because the percentages are wrong (but nearly useless, as Canonical is relatively recent and RedHat is not, because Gnome is only one of the projects and there are many others, etc.) but because they measure too little. I already wrote in the past about the enormous effort that goes to non-code contributions, and that no-one measures (as for OpenOffice, there are more contributors in non-code parts than in code); there is also a substantial effort in creating a product out of contributions. And Ubuntu certainly invested in product engineering, marketing, even engineering (less than Red Hat? So what? Large IT consulting companies are getting paid millions for open source-based systems, and I never saw a contribution at all). When Matt Asay claims that bringing Ubuntu to million of people is a contribution, he is claiming an absolute truth; every time Canonical manages to bring a press release out it is making a huge contribution. Maybe less code than others, but this is not a beauty contest – this is a cooperative effort for building a better future, not a race to see who is the nicest or worked harder. It is true that Canonical (I hope) profits from OSS: well, it is one of the most important thing for OSS, as it demonstrates that OSS is sustainable, that people can live off OSS services and products, all the while improving our world. I repeat: maybe someone at Red Hat is not happy of the visibility of Canonical, given all the contributions they do? I am sorry – and I am quite happy to show at all my talks that Red Hat is an incredibly good and well-managed company, that has open sourced all the proprietary products it acquired – and invests an incredible amount of effort in engineering in the open. I like them a lot (no, I don’t work for them, and never did use one of their services), but I like Canonical as well, because they are investing heavily in the desktop market, a market that is not the focus of Red Hat any more and that I believe is quite important.
This is not a contest. We should be happy for every, small, large, strange or different contributions that we receive. Should it be more? Maybe. But don’t overlook all those things that are being done, some of them outside of pure code. Because, as I wrote in the past, there is much more than code in an OSS project.
Recent Comments