Naughton, Android, the GPL and why I’m fuzzy minded.
Posted by cdaffara in divertissements on November 11th, 2011
Edward Naughton latest attack (pdf) on Android/Bionic and his claims that the GPL license has been violated are bordering on ridiculous. First of all, to simply claim that dissenters are “fuzzy minded” because we don’t supinely believe that Google is evil incarnate, that the GPL has been eviscerated, and that we are all going to die in a proprietary/parasitic world is, well, bogus. Brian Proffitt made an excellent response, that calmly provides a reasonable background and some doubts – may it be possible that the author has some motives? Say, like the suspicions previously raised around Florian Mueller? The real problem of the article is that… it’s lame, weak and takes innuendo and unrelated comments to weave them into a “proof”. I hate this kind of FUD. I hated it when Stallman did it, I hated it when Microsoft did it (“see? all those companies that licensed patents from us? It’s the proof Linux infringes!”) and now we have to endure another similar effort.
Let’s start with the biggest problem: “As I explained in detail in my first paper, Google’s approach works only if the cleaning process removes all of the copyrightable material from every one of the headers” and then goes on to show that in his opinion there are still parts that are not “pure headers”. He makes a quite simple logical error: to claim that macros are by default copyrightable. The problem is that some macros are implemented like that for technical reasons-in fact, there are no alternative, equally efficient ways to implement them in the same way. “The court explains that elements dictated by efficiency are removed from consideration based on the merger doctrine which states that a form of expression that is incidental to the idea can not be protected by copyright. In computer programs, concerns for efficiency may limit the possible ways to achieve a particular function, making a particular expression necessary to achieving the idea. In this case, the expression is not protected by copyright” (from: Computer Associates International, Inc. v. Altai, Inc.)
So, macros like those dangerously incriminating ones that Naughton believes it saw in Google indiscriminate attitude towards copyright – well, they are still unprotected, or at least (as Brian Proffitt cleary wrote in his piece) no judge expressed his views on this.
Just this point defuses most of the damning argumentation rised in the white paper – like the fact that “Google optimized the scripts for convenience and not copyright compliance”. Some other points: “Google’s decision to remove some functions and variables but to retain others depending on how it affected performance shows that they were playing fast and loose with copyright.” – no, it shows that you have an axe to grind.
“Some who criticized my analysis relied on cases in which an abstraction-filtration-comparison analysis was used, but, as Judge Alsup’s order recognized, that approach is used when the issue is the copying of non-literal elements. It doesn’t generally apply to instances of literal copying like this one. See Lotus Development Corp. v. Borland International Inc., 49 F.3d 807, 814-15 (1st Cir.
1995).”
First of all, Judge Alsup hadnot ordered something like “Google copied”. It just refused to grant a preliminary injunction on the copyrightability of APIs, and this is due largely to the problem of conflicting presentation of APIs from Oracle and Google (inclusive versus exclusive). And the Lotus v. Borland was not considering the AFC test because… it regarded USER INTERFACES. Not Application Programmer Interfaces. Naughton kindly sweeps the issue under the carpet, as it would remove the filtration test… and filter out much of his white paper.
In fact, all the rest is unnecessary drivel designed to demonstrate the strength of his analysis: “To be sure, the WordPress situation involved different technical details than the kernel headers, but…” (but what?)
“I have practical concerns as well: Google’s approach, if it works, provides a roadmap for bypassing the GPL, as well as a relatively simple set of customizable scripts that could allow easier exploitation of GPL components by proprietary programs. An easy bypass of GPL protections runs contrary to what FOSS advocates stand for, and I certainly would not have expected such an uncritical defense of Google.” Where, oh where, is this kind of thing possible? The author takes something that is possible for headers only, takes his own view of Google as a dastardly stealer of code, and takes it to the next level: “see! If we don’t stop them now, they will find a way to clean GPL code as well as headers! We’re doomed, like Tivo!”
I tried to write down a response that did not involve biological paraphrases, but I failed. Let’s say that the argument is not his strongest point.
(footnote: I don’t care particularly for Google, I have no financial interest for them, but I respect the contributions they made to OSS.)
Android free, non-free, and generic FUD (updated)
Posted by cdaffara in Uncategorized on September 20th, 2011
Updated 26/9/2011: It is clear that some of the points of my article were less clear than I hoped (my fault: it’s clear that my writing was less than perfect). So, as a clarification, I would like to point out a few things.
As a starting point, I am referring to the Android Open Source Project when talking about “Android”. It is clear that a proprietary, binary firmware released by a phone vendor is definitely not free, and I assume that Richard Stallman knows it as well, and in talking about Android he is referring to the open source project as well. So, when some of my polite commenters (I am blessed of having kind and nice people among my readers, it seems) mentioned that Android has proprietary pieces I actually have to point out that in the AOSP GIT there are no such proprietary pieces – even the imported kernel tree has no (optional) proprietary driver bits. So, if you want the Broadcom binary blob, or the Intel binary pieces, you have to download them externally. Also, as RMS points out in the article, it is possible to have a functioning phone using only the open parts; in fact, if you go and check what proprietary parts are usually needed in an Android build the primary culprits are the WiFi drivers and ancillary components like Camera, Video Out, and accelerated graphics like OpenVG) – nothing that stops you from creating a real phone out of it, albeit with lots of parts that require work. Lots of people is working on creating or porting fully open drivers-meaning that a fully open Android on all hardware devices is possible, just requires work.
Second, when talking about “free” there is always an uncertainty in discussing what “free” is without adding a definition. I am guilty of it as well, but here is my definition, which is by the way the same used by RMS:
“Free software is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.” Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. More precisely, it means that the program’s users have the four essential freedoms:
- The freedom to run the program, for any purpose (freedom 0).
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor (freedom 2).
- The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
A program is free software if users have all of these freedoms.” (Source: the Free Software Definition) Given this definition, I still have to object that under RMS definition Android (as the AOSP, released at this moment) IS free. It does not matter whether future versions are not (or will not be) as the definition does not talk about future versions but only the ones that we do have now; it does not cover whether the organization doing the development is an evil overlord or a public consortium, or anything else. It has a short list of 4 points, and to be free you must satisfy them all, and to satisfy them you must have software released under a license that is recognized as free. If you read the article again, you will find out that RMS is not addressing one or more of these points, but lots of external bits that are not related to the definition itself. The fact that binary Android may contain non-free parts (that happens with Linux as well, but is clearly not sufficient to say that Linux is non-free), the fact that it is not GNU/Linux (again, not relevant), the fact that it is not GPLv3 (as only the latest version of the license would grant a “freer than free” status), the fact that software patents exist (which is a curse, but again not relevant), the fact that part of the phone may be upgraded with non-free components that may listen to you (and again, not specific to Android). In essence, the entire article glides away from the point that may really be relevant to Android freedom, and draw a set of lines that are implying that Android is bad in some way. That is why the article is poorly written – because it ignores the real points, and would be equally applicable to other platforms as well – Symbian, Maemo, whatever. If RMS wants to make a statement, then you should point out that creating free drivers is possible and provides advantages for the user and the manufacturer (something that Broadcom, Intel, ATI already discovered); that a totally free alternative is possible with a coordinated effort, that alternatives to services may be created and can be a really competitive factor (OpenStreetMap, Firefox Sync) if properly directed. All of this was missing. A better effort would be to add a page at the FSF site listing hardware for which drivers are not available or in a partial stage, and request assistance. Much better than going at another project (75% of which comes from other free projects, by the way) and shouting “fire!”.
Original:
I hate FUD (Fear, Uncertainty, Doubt) whether it is spelled from proponents of proprietary software or free software loyalist. I hate it because it uses half-truths, innuendo and emotional traps to prevent readers to form their own opinion using rational means.
Having said that, I have been already skeptical of the previous attempt of the FSF to declare that the GPLv2 is “dangerous” because it has no explicit reinstatement clause, piggybacking on posts by popular Android doomsayers that (wrongly) claimed that Android tablet vendors “lost their rights to the Linux kernel”. Now, RMS clearly aimed with bigger guns at Android, that is clearly irking to his freedom-loving personality and probably seen as a plague barely better than Windows. In doing so, he unfortunately reached the same level of his hated proprietary vendors, using a barrage of arguments that show little attention to the reality.
Given the fact that RMS cares nothing of me (I still remember the disdain when I suggested that “Libre” may have been a better word than “Free”) and I am tired of being hated only by academics, I would like to dissect a few of the points raised by our beloved Richard.
“The version of Linux included in Android is not entirely free software, since it contains non-free “binary blobs” (just like Torvalds’ version of Linux), some of which are really used in some Android devices.” Ah, the heresy. Android uses binary blobs – but, behold! That’s because it uses Linux inside. So, really, this is an attack on the lax idea of freedom of Torvalds, that begrudgingly allows some vendors to add binary components inside of the user-space drivers.
I would like to point out as a first problem the phrase “some of which are really used in some Android devices”. So, it’s not all of Android that is bad – especially since those binary blobs are really part of Linux, it would have been much better aimed for RMS to claim that Linux is non-free. That, of course, would have raised the ire of quite a lot of developers and some condescending smiles from the general population, limiting the desired effect. Big, bad Google with its privacy problems is a much better target. It is also clear that not all of Android is non-free; something that is better rephrased as “basically all devices are non-free; some are, but we don’t talk of them as it would ruin the effect”.
So, first count is: “Android is non-free” is true only as “Linux is non-free” is true. Not a good start.
“Android platforms use other non-free firmware, too, and non-free libraries. Aside from those, the source code of Android versions 1 and 2, as released by Google, is free software – but this code is insufficient to run the device. Some of the applications that generally come with Android are non-free, too.” RMS here mixes a generic and undefined “Android platform” with the real Android – AOSP, the Android Open Source Project. That has no non-free libraries I was capable to find. If RMS talks about the binary versions that some vendors add, well, that’s no Android; it is the superposition of Android+other binary components. Not different from Linux used to run Oracle, for example; or Linux plus any other proprietary piece.
I also contend with the idea that the code is insufficient to run the device as well. MIUI and Cyanogen are but two of the source forks that are totally based only on the free code, and if you accept the lack of some functionality like camera or video out you may use your device without any proprietary blob. Again, saying so would have ruined the effect; also, it would point out that the Linux approach successfully made large companies like BroadCom or Intel to release fully free versions of their drivers.
“Android is very different from the GNU/Linux operating system because it contains very little of GNU. Indeed, just about the only component in common between Android and GNU/Linux is Linux, the kernel. People who erroneously think “Linux” refers to the entire GNU/Linux combination get tied in knots by these facts, and make paradoxical statements such as “Android contains Linux, but it isn’t Linux”. If we avoid starting from the confusion, the situation is simple: Android contains Linux, but not GNU; thus, Android and GNU/Linux are mostly different.” Leave it to RMS to beat to death the “GNU/Linux” mantra. RMS mixes the popular idea of Linux distribution with “Linux” redistribution in general. I found very little difference between Android and most embedded distro, or with set-top box systems. Here RMS uses the opportunity to rehash the idea that those using Linux should really be grateful to the FSF more than any other component maker; something that I found not correct – not that I am not grateful RMS and the FSF for their important contributions (the GPL on top) but because it is disingenuous to all the other contributors, like RedHat, Cygnus, Xorg, Sun, and the countless other groups that have a percentage of code comparable to the GCC, LibC, GNU utils and the other contribution by FSF.
By downplaying what others have done, RMS downplays other free software people and efforts – only because they are under the banner of open source, or not in line with his view. But this is only the entree, preparing for the real point:
“If the authors of Linux allowed its use under GPL version 3, then that code could be combined with Apache-licensed code, and the combination could be released under GPL version 3. But Linux has not been released that way.” Ahh, here comes the culprit. Bad, bad Torvalds! You decided not to trust us with a “GPL2 and later”, because you may not like what we write in the next license, and so one of the most successful free/open code is not in line with out current view. Bad boy! This should be seen as a continuation of the first FSF post, maybe – “if it was GPL3 it would be spotless and beautiful”. Note the totally unrelated intermission; there is really no logical connection with the binary blobs mentioned as a reason for being “non-free” (where the non-free parts are not really part of Android but bolt-ons, and the real non-free is Linux for its tolerance of binary blobs in user space). This lack of logical flow is the indication that this was the real reason for the article, and why I call it FUD. But it would have been much less effective this way.
“Google has said it will never publish the source code of Android 3.0 (aside from Linux), even though executables have been released to the public. Android 3.1 source code is also being withheld. Thus, Android 3, apart from Linux, is non-free software, pure and simple.” Actually, Google said that they plan to release the ASL part of it: “We’re committed to providing Android as an open platform across many device types and will publish the source as soon as it’s ready.” so actually the wording is not correct either (unless they have a different statement from the one that I heard recently from Chris DiBona of Google in one of his public appearances). In fact, it is also not correct for the GPL parts, that were published publicly in the AOSP Git as early as January 2011.
“The non-release of two versions’ source code raises concern that Google might intend to turn Android proprietary permanently; that the release of some Android versions as free software may have been a temporary ploy to get community assistance in improving a proprietary software product. Let us hope does not happen.” Read: “Google is probably driven by Darth Vader and doing a DeathStar-like ploy to destroy the rebels”. RMS is forgetting the fact that is true that Android may turn proprietary, exactly like any software project for which one entity has all the copyrights. But the previous versions remain free – something that Nokia should have learned when they released the Symbian code under the EPL, trying later to rewrap them under a proprietary license (good thing that I kept a copy of the originals). This means that someone (several, actually) will go and fork it. Good riddance to Google – they will never be able to stay afloat without the constant flow of patches from external projects, that constitute 75% of the Android source code.
“In any case, most of the source code of some versions of Android has been released as free software. Does that mean that products using those Android versions respect users’ freedom? No, for several reasons. First of all, most of them contain non-free Google applications for talking to services such as YouTube and Google Maps. These are officially not part of Android, but that doesn’t make the product OK. There are also non-free libraries; whether they are part of Android is a moot point. What matters is that various functionalities need them.” So, let me be clear here: RMS claims that he is aware that Android, per se, is released as free software. But he changes the definition of what is Android to artificially extend it to reach non-free parts, so that he can show that all of it is non-free. Well, I use a free software rom (MIUI) that is free and beautiful; I have decided to add the Google non-free apps not because I am forced to, but because I decided that I can trade functionality for freedom in this specific case. If you don’t want to, there are replacements – or you can decide you don’t want Google Maps and walk instead or use a paper map. I can decide – thus I am free.
“Replicant, a free version of Android that supports just a few phone models, has replaced many of these libraries, and you can do without the non-free apps. But there are other problems.” So, actually, it is possible to run a totally free Android – but you still are not in the clear. Why? Oh, Why?
“Some device models are designed to stop users from installing and using modified software. In that situation, the executables are not free even if they were made from sources that are free and available to you. However, some Android devices can be “rooted” so users can install different software.” Ahh, here it is again! If Linux (and, thus, Android) was GPL3 this could not have been done! Good thing that RMS recognizes that only some vendors are doing so (Samsung happily allows for custom roms, like the one I am using-and several others do as well).
“Important firmware or drivers are generally proprietary also. These handle the phone network radio, Wi-Fi, bluetooth, GPS, 3D graphics, the camera, the speaker, and in some cases the microphone too. On some models, a few of these drivers are free, and there are some that you can do without – but you can’t do without the microphone or the phone network radio.” Same point as before – proprietary drivers in Linux. Please, if this is all you have, go back and write “Is Linux really free software?” And again, if this is a problem boycott vendors that have no source for their drivers.
“On most Android phones, this firmware has so much control that it could turn the product into a listening device. On some, it controls the microphone. On some, it can take full control of the main computer, through shared memory, and can thus override or replace whatever free software you have installed. With some models it is possible to exercise remote control of this firmware, and thus of the phone’s computer, through the phone radio network.” The GSM part of modern cell phones is independent from the main phone controls, and is usually connected through a separate bus. This is due to the certification process for being able to connect to the GSM networks, that make it very difficult to be certified if the code is modifiable by the user. So, everyone masks this under a binary part for the RIL (Radio Interface Layer). Some vendors have a purely binary RIL, others publish the source code. So, dear RMS, instead of banging against the fact that a binary RIL is possible (and is possible even in the GPL3) go and praise those that publish it.
“Putting these points together, we can tolerate non-free phone network firmware provided new versions of it won’t be loaded, it can’t take control of the main computer, and it can only communicate when and as the free operating system chooses to let it communicate. In other words, it has to be equivalent to circuitry, and that circuitry must not be malicious. There is no obstacle to building an Android phone which has these characteristics, but we don’t know of any.” The point is not Android, but any Linux phone (actually, any phone in general, since all of them have upgradeable radio firmware). Go and claim that we should not be using a phone, or a mobile phone. Again, blaming this to Android makes for a better target.
“Software patents could force elimination of features from Android, or even make it unavailable.” Go there! Claim that Android is a patent target, and conveniently ignore the Microsoft Linux patent threats, and the many patent attacks on free software that companies like RedHat are trying to defend. Just don’t point out Android as a single culprit.
“However, the patent attacks, and Google’s responses, are not directly relevant to the topic of this article: how Android products approach an ethically system of distribution and how they fall short. This issue merits the attention of the press too.” So, why write it? Because it is like a cherry on top – it finish the dish.
“Android is a major step towards an ethical, user-controlled, free-software portable phone, but there is a long way to go.” Don’t be too harsh, or people may think that you have an agenda. So, after badmouthing Android, say something nice – like the fact that you can redeem, if you move to the GPL3.
Article summary: “Android is non-free” (actually Linux is, but I can’t say it), “is driven by greedy gollums” (maybe), “Android phones may spy on you” (like all modern phones), “it may be destroyed by patents” (like Linux), and in general if you switch to the GPL3 we forgive you.
Look: there are many negative points in Android, like the fact that having it as a separately managed project under an Eclipse-like consortium would be much better (I wrote my thoughts on it here) or that the fact that the Honeycomb code is still not released, or that governance is centrally hold by Google. This is however not a good reason for using Android as a scapegoat, only because it is widely used and successful. This is FUD – and it only helps those that despise free software.
(Disclaimer: I don’t care what Google thinks, I don’t have an interest in Google financial performance, my only point of contact is in having an Android phone and a passion for free/open/libre source).
“FOSS isn’t always the answer”. And you asked the wrong question.
Posted by cdaffara in Uncategorized on July 22nd, 2011
There is an interesting post from James Turner on O’Reilly Radar, that starting with the charming title of “FOSS isn’t always the answer” and ends up with, among other interesting comment, something like “But [the FLOSS proponent] need to accept the ground rules that most of us live in a capitalist society”. At that point, I was snickering and torn between laugh it off or respond – and of course, my desire to find good excuses for not work today had finally won me over.
from the always, always perfect Xkcd
Reading this post made me think of one of my first conferences, where an economics professor kindly told me “good work, kid. Now, economic theory tells us that this little, nice communist dream will fail in one or two years. In the meanwhile, enjoy your gift economy ideal”. I have been called a “communist” for quite some time, and still chuckle at the idea: that someone still thinks that FLOSS is inherently “anti-capitalistic”. This is something that curiously is commonly repeated by people working for a very large, Redmond-based company, that constantly presents slides like these:
See? The GPL is, magically, “anti commercial” (despite the fact that OSS provide cost reduction and increases in efficiency of at least 116B€, 31% of the software and services market). And the author makes the example of TCP/IP or NSA linux as projects that made no commercial impact… Let’s all revel in the idea that TCP/IP had no commercial impact for a moment, including the irony of doing it on a TCP/IP network like the Internet, and let’s continue.
Let’s comment on the individual points that Turner raises:
“No one uses a closed source compiler anymore, Eclipse is one of the leading IDEs for many languages, and Linux is a dominant player in embedded operating systems. All these cases succeeded because, largely, the software is secondary to the main business of the companies using it (the major exception being Linux vendors who contribute to the kernel, but they have a fairly unique business model.)” That’s an interesting comment, for more than a reason. First of all, because it fails to grasp one of the most important economic points of software: with the exception of software producers, software is always secondary – it is a supporting technology. You would consider electric power as secondary as well, despite the fact that it is essential; software has a similar property – it is secondary and essential at the same time. The second interesting comment is related to Linux vendors: for some curious reasons they were able to profit from something that is distributed for free, but Turner dismisses them as an “exception” because… they don’t fit his model of the market.
“Where FOSS breaks down pretty quickly is when the software is not a widely desired tool used by the developer community.” The underlying assumption is that open source is developed for free by developers, because that’s what they do normally, and they want to donate time to the community. This assumption is wrong. The majority of open source developers are paid for work on open source; also, the idea that they do it for free is some nice communist-like idea that is unfortunately totally distant from reality.
“The typical line of thought runs like this: Let’s say we’re talking about some truly boring, intricate, detail-laden piece of software, such as something to transmit dental billing records to insurers … So, if all software should be free and open source, who is going to write this code? One argument is that the dentist, or a group of dentists, should underwrite the production of the code. But dentistry, like most things in western society, tends to be a for-profit competitive enterprise. If everyone gets the benefit of the software (since it’s FOSS), but a smaller group pays for it, the rest of the dentists get a competitive advantage. So there is no incentive for a subset of the group to fund the effort.” There goes the main argument: since software is given for free, and someone else is getting advantages for free, free riding will quickly destroy any incentive. This is based on many wrong assumptions, the first of which is that the market is always capable to provide a good product that matches the needs of its users. This is easily found out to be wrong, as the example of SAKAI and Kuali demonstrate: both products were developed because the proprietary tools used by the initial group of universities were unable to meet the requirements, and the costs were so high that developing reusing open source was a better alternative. And consider that Kuali is exactly the kind of software that Turner identifies as “non-sexy”, that is a financial management system (if you want more examples of the medical nature, go to VISTA, OpenClinica, or to meet Turner article, OpenDental). The reality is that some kind of software is essential, most of the software is non-differentiating, and maintaining that software as open source has the potential to reduce costs and investment substantially – for the actual data, check this post).
“Another variant is to propose that the software will be developed and given away, and the developers will make their living by charging for support. Leaving alone the cynical idea that this would be a powerful incentive to write hard-to-use software, it also suffers from a couple of major problems. To begin with, software this complex might take a team of 10 people one or more years to produce. Unless they are independently wealthy, or already have a pipeline of supported projects, there’s no way they will be able to pay for food (and college!) while they create the initial product.” Great! Turner now discovered one of the possible open source-based business models we classified in FLOSSMETRICS. Of course, he conveniently forgot that by reusing open source, this hapless group of starved developers can create their product for one tenth of the cost and the time. So, the same property that Turner thinks can doom this poor group of misguided developers can actually provide them with the solution as well.
“And once they do, the source is free and available to everyone, including people who live in areas of the world with much lower costs (and standards) of living. What is going to stop someone in the developing world from stepping in and undercutting support prices? It strikes me as an almost automatic race to the bottom.” That’s called competition. Never heard of it? Despite the “race to the bottom” (that, in economic terms, is applicable only to commodities) service companies seem to do quite well nowadays.
“But I have spent most of my adult life writing proprietary software — most of it so specialized and complicated that no open source project would ever want to take it on — and I find the implication that the work I do is in some way cheap or degrading to be a direct insult.” Here we see two different concept: the first, that open source is unable to reach the level of complexity of proprietary software. This is contradicted by some of the examples mentioned by Turner himself (unless he considers a compiler to be too simple), or by academic research: “The growing rate, or the number of functions added, was greater in the open source projects than in the closed source projects. This indicates that the open source approach may be able to provide more features over time than by using the closed source approach. In terms of defects, our analysis finds that the changing rate or the functions modified as a percentage of the total functions is higher in open source projects than in closed source projects. This supports the hypothesis that defects may be found and fixed more quickly in open source projects than in closed source projects, and may be an added benefit for using the open source development model.” (Paulson, Succi, Eberlein “An Empirical Study of Open Source and Closed Source Software Products”).
More important is the second part of the phrase: “the implication that the work I do is in some way cheap .. is a direct insult”. There you are: unless I am paid directly for my software, I consider it to be too cheap. This means only one thing: that Turner knows only one potential model, that is the “I sell a box to you, and you pay it for that”, and all the others are an “insult”. Well, RedHat does it differently, and is reaching 1B$ in revenues; my brief contacts with RHT people never gave me the indication that they feel insulted. Or OpenNMS, where Tarus is proud of its openness. Or Eclipse (the ultimate communist dream! Friends and Foes all together!)
“But they need to accept the ground rules that most of us live in a capitalist society, we have the right to raise and provide for a family, and that until we all wake up in a FOSS developer’s paradise, we have to live and work inside of that context. I’d love to hear how a proprietary-free software world could work.” Here we return to the assumption that open source is inherently non-capitalist, which is simply not true; the ending is also telling: “a proprietary-free software world” assumes that there should be only one solution. Exactly like Turner, I believe in freedom of choice – anyone is free (when is not forced by his government to use a proprietary office suite or operating system, of course) to choose for the best. I would not, however, bet against FLOSS.
It could have been different: Android, Google and all that
Posted by cdaffara in divertissements on July 12th, 2011
If there’s one thing that is totally clear, is that Android is ravaging the smartphone market, and all those that are feeling the heat are trying to use the most innovative and transparent approach to stop it: sue Google and its partners out in the oblivion. Software patents, design patents, copyrights, plain trolling- anything goes if it can help in stop the Droid juggernaut. At the same time, Google is under attack for its delay in publishing the Honeycomb source code, attacked for the half-backed results that can be witnessed in some tablet products, all of this in an environment where Android phone makers are obtaining extraordinary revenues, in large part thanks to those contested products (Samsung comes to mind).
Of course, hindsight is 20/20 as they say, and it’s easy to “predict” that the extraordinary success of Android would have generated such a defensive attack. It is however at least predictable, given the extreme litigation of software companies, that patents would have been used as a blunt instrument to fend off competitors. Could things have been different? I believe so, and I also believe that Google made some errors in its decision, especially in trying to create a control point (the “Google experience”) instead of favoring a more long-term vision.
Let’s start from the beginning. Android is two things at once; from one side it is a collection of many, many different open source projects, some external, some Google-created, some heavily modified and adapted specifically for the purpose. There is a separate, private tree (at the moment the 3.x branch) that is also based on open source projects, but is at the moment internal to Google and the partners that decided to join its Open Handset Alliance. Some projects are clearly behind their open counterparts, especially WebKit, while at the same time maintaining substantial external off-tree patches that are extremely difficult to integrate like in the Linux Kernel. There is an additional layer of totally proprietary apps, that are installable only for those partners (and phones) that subjugate themselves to an additional set of requirements and licensing rules, something that for example caused lots of problems for Motorola and Google in the SkyHook lawsuit. This will probably continue, and will be the real battleground, given the fact that Android and iOS are clearly emerging as the leading platforms.
Could it have been different? I think so. And by releasing some degree of control, Google could have created a much safer and open environment, while sacrificing very little. Let’s start with the point that what Google really, really wants is an unencumbered rich internet-enabled platform, that is not constrained by third parties, and that it uses Google services. The reality is that Google lives off advertising (at the moment, at last) and is trying to expand it to other services, like enterprise mail, documents, and so on; there are two roads to do that: the first is to create a platform that is strongly tied to Google services, so that it is nearly impossible to escape its control. In doing so, however, you face the tension of the OEM and vendors that may want to switch services, or that want to push internally developed offerings. In this case, they will have nothing left to do but to go with the competition, or create their own variant (something that already happened) increasing the adoption costs.
The alternative is the “A rising tide lifts all boats” – make it a purely open source project, where there is a real distributed control, like Eclipse. Turn it to the Apache foundation. Make all the interested partners a part of the foundation or consortium, make the code public (with limited exceptions, like for prerelease hardware drivers) and try to track as much as possible the projects where you take things from. Apply a strict code contribution regime to strengthen your position against IP claims, and especially don’t turn it into a product. Yes, you read it properly- the code should be a strict open source project. This way, it would be extremely difficult for an external party to sue the “origin”, given the difficulties in identifying a directly derived infringing device; Google could have then (using this more sanitized and cleaner base) provided insurance through a third party for IP infringement claims, if the code base adopter would want to use such an opportunity (some may decide to fight on their own, of course). This implies that an Android OEM can substitute the Google services and use something else (that, by the way, is possible even now) but would have easily prevented most antitrust-based attacks. The purely open code base and the increased external participation would have further shortened the time-to-market for providing a new board to the marketplace, reduced adoption costs, and facilitated an external ecosystem of providers for Android based services.
Google could have at least avoided some of the worst blows, increased its credibility with the various OS communities, and reduced the cost of adopting Android for an OEM, pushing more and more the platform. This, in exchange for some of the tight control that currently Google exercise on the platform. Unfortunately, I think it’s too late for that; and we will still have to face the sad situation that the life of a mobile platform is dictated purely by judges.
Open Source as a differentiator?
Posted by cdaffara in OSS adoption, OSS business models on July 4th, 2011
What is an “open source company”? What is the real differentiation element introduced by Open Source? These and more questions were introduced by a great post by Matthew Aslett (if you don’t follow him, go and follow now. I’ll wait. Yes, do it. You will thank me later.), called “The decline of open source as an identifying differentiator“. It is an excellent analysis of how companies mostly stopped using the term “open source” in their marketing materials, and has a follow up (here) that provides a summary of the main responses by other analysts and observers.
The post raises several interesting points, and in my opinion provides a great basis for a more general discussion: what is the difference introduced by open source? Is there a difference at all?
Let’s start with an observation of the obvious: the use of open source to build software is now so widespread that it is not a differentiating element anymore. There goes the various “built on open source components” of some companies – practically all companies are using open source inside. It’s simply not a difference. So, let’s start with what is the real differential between OSS and proprietary:
The licensing. An open license may introduce a difference for the adopter. This means that if such a differential is used by the company, it must provide a value that derives from the intrinsic property of open source as a legal framework. For example, independence from supplier (at least, theoretically…) both in case of provider change, and independence in terms of adding or integrating additional components, even if the company is in disagreement.
The development model. The collaborative development model is not a certainty – it arises only when there is a clear infrastructure for participation. When it does happen, it is comparatively much faster and more efficient than the proprietary and closed model. For this to be a real differentiator, the company must engage in an open development model, and this is actually happening only in a very small number of cases.
In general, the majority of companies that we surveyed in FLOSSMETRICS have now a limited degree of differentiation when compared to their peers, and even as a “signaling” open source is now no more interesting than other IT terms that entered the mainstream (we can discuss further whether “cloud” will disappear in the background as well..) Of the companies we surveyed, I would say that those that we marked originally as “specialists” are the ones more apt to still use “open source” as a differentiating term, with “open core” ones the least (since they don’t reap the advantages of a distributed development model, neither the adopter reaps the advantages of the open source licensing). A potential difference may arise for development tools or infrastructures, where open source is a near necessity; in this case, the natural expectation will be for the platform to be open – thus not a differentiating element any more.
The economic value of Open Source software
Posted by cdaffara in OSS business models, OSS data on June 22nd, 2011
(Warning: looong, and extremely boring.)
What is the real value that Open Source has brought to the economy? This is not a peregrine question. Since most of the current evaluation methods are based on assessing “sales”, that is direct monetization of OSS, we are currently missing from this view the large, mostly under-reported and underestimated aspect of open source use that is not “sold”, but for example is directly introduced through an internal work force, or in services, or embedded inside an infrastructure. Summary: OSS provide cost reduction and increases in efficiency of at least 116B€, 31% of the software and services market.
Getting this data is, however, not easy. There is an easy approach, called “substitution principle”, that basically tries to measure how much a collection of hard-to-measure assets is valued by counting the sum of the money necessary to substitute them; for example, counting the value of all the Apache web servers by adding the cost of changing them all with an average, marketed substitute. This approach does not work, for two reasons: first of all it introduces a whole world of uncertainty, given the fact that software is never perfectly exchangeable with an alternative. The second is related to the fact that users may be unwilling to pay for an alternative, so from that point of view the real value is much lower. This is, by the way, the (erroneous) way that RIAA and other rights organizations measure piracy losses: by counting how many times the copy of a film is downloaded, and assuming that all the people that downloaded it would have paid for a full cinema ticket if piracy did not exist. It is obviously wrong – and would be equally wrong if we applied the same principle.
Another approach is to measure the revenues of companies that are adopting an OSS-based business model, something that we have extensively studied in the context of the FLOSSMETRICS project. The problem with this approach is that it totally ignores the work that is performed without a monetary compensation, and it under-reports the software that is distributed widely from a single source (for example, the open source code that is embedded in phones or routers). A purely monetary measurement also ignores inherent improvements in value that can derive from an improved technology. Let’s make an example: let’s imagine that in the world, all television sets are black and white only, and only recently a new and improved television set can provide color. The new TV sets costs quite a lot more than the old B&W ones, so if we imagine that all the current TV viewers want to move to color the TV set provider can obtain a total amount of money that is the product of the cost of the new TV set multiplied by the number of viewers. The company is happy 
Now, let’s imagine that a magic signal allows the old TV sets to show color images. The company that produces the color TV sets is clearly unhappy, since its value dropped instantly to zero, but on the other hand all the people with B&W TV sets is happy, even if there is no monetary transaction; the user value increased substantially. We need to capture this value as well, since a substantial amount of this economic value is hidden in the user balance sheets. This means that we need to find a different, alternative way to measure OSS value: enter macroeconomics!
We can start from the overall economic value of IT in general. There is one thing that we know for sure: the total economic value of a country or a region like Europe – 12.3T€ (trillion of Euro). We also know the average IT expenditure of companies and Public Administrations, that is 4% (source: Gartner IT key metrics data, EU eBusiness-Watch) with wide variations (small companies: around 7%, going up with size up to the average for Fortune 500: 3%). This means that the average IT spending, including services, employees, hardware, software, whatever. This means that the overall IT spending in Europe is approximately 492B€, of which 24% is hardware (source: Assinform, Gartner, IDC) – which means that software and services market is valued at 374B€. (Estimates from Forrester are in the same range, so we are at least consistent with the big analyst firms)
Still with me? Good! Now, the next step is estimating the savings that are directly imputable to open source. We have two sources: an internal source (code replaced by OSS) and external (savings reported by IT personnel through use of OSS). Let’s start with savings from OSS adoption, that can be estimated (using data from Infoworld and our data from COSPA) at 15% for “light” adopters (less than 25 OSS products used) to 29% for “heavy” adopters (more than 25 OSS products), up to the 75% of specific cases (reported by Gartner for maintenance and licensing). Taking into account the share of use of OSS in general and the variation in use of OSS among different sizes, we can estimate that the savings directly introduced by OSS amount to 41B€ – those do not appear anywhere but in the adopters balance sheets, that is in a reduction of IT expenses, or a better result for the same IT expenditure (think about the TV set example outlined before).
And now, software development. It may sound strange, but only a small part of software is ever developed for the market – what is called “shrinkwrapped”. The majority of software is developed (internally or through external companies) for a specific internal need, and is never turned into an external product. In fact, when we consider the “service” part of the non-hardware IT market, we discover that nearly half of that value is actually sponsored software development, and the remaining 35% is non-software services (support, training, ancillary activities). This means that in Europe, 244B€ are software spending in a form or the other (for example, employee wages).
What can we say about this software? We know that a part of it is Open Source, because the majority of developers (69%, according to Evans Data) is using open source components within their code. We also know, thanks to Veracode, that “sampling … find that between 30 and 70% of code submitted as Internally Developed is identifiably from third-parties, most often in the form of Open Source components and Commercial shared libraries and components”. In our own database, we found out that the role of commercial shared libraries is hugely dependent on application type and vertical sector, and it falls consistently between 15% and 30% of the code not developed from scratch. Using a very conservative model, we can thus estimate that 35% of the code that is developed overall is based on Open Source, and this means that there is both a saving (software that is reused without having to redevelop it) and a cost, introduced by the need for adaptation and the “volatility cost”- that is, the risk introduced by using something developed outside. Thankfully, we already have quite a lot of information about these costs, thanks to the effort of the software engineering community; some details can be found here for those that really, really want to be put to sleep.
Applying the software engineering costs detailed in my previous article (volatility, increased cost for code re-factoring, glue code development) we can estimate that the savings introduced by OSS are, in a very conservative way, 31% of the software-related part of the IT ecosystem, that is 75B€. The real value is higher, mainly because reused OSS code tends to be of higher quality when compared with equivalent proprietary code (data and academic references available here) but I will leave this kind of evaluation for a future article. We can however say, with quite a good level of certainty, that the lower bound of savings that OSS does bring to the European economy is at least 116B€ - the majority of which does not appear in the “market” and only in a minimal part in the balance sheets of OSS companies (consider that only Red Hat is now approaching 1B$ in revenues). It is savings and increased efficiency of companies and Administrations that use OSS, something that was already discovered: “Finally, comparing the individual data on firms with turnover of less than 500,000 euros with the variable on size classes of customers (by number of employees), one can hipotesize a correlation between the use of software Open Source and the ability to attract customers of relatively larger scale. At the same turnover, in other words, companies “Open Source only” seem to have more chances to obtain work orders from companies with more than 50 employees (ie medium – large compared to our universe of reference).” (source: Venice study on Open Source) or the fact that revenue-per-employee ratio is higher in companies that adopt open source software (on average by industry, OSS-using companies have a revenue-per-employee that is 221% of the non-OSS controls). It is also important to recognize that this is only a measure of the direct impact of OSS. The reality is that software has a substantial impact on revenues; an example I found out is Siemens, that with 70B€ in revenues spends 5% in software drives 50% of its revenues. A similar impact can be expected of the savings introduced by OSS – something that we will talk about in a future post.
The upcoming cloud storm, or ChromeOS revisited
Posted by cdaffara in OSS adoption, blog on May 25th, 2011
The latest IO2011 conference from Google marked the first real marketable appearance of several noteworthy additions: Angry Birds for the web, a new Android release and the latest netbooks based on ChromeOS. The most common reaction was of basic lack of interest from analysts and journalists, with the prevalent mood being “we already saw what netbooks are, and we don’t like them” or “you can do the same with Windows, just remove everything and leave Chrome on it”.
Well, I believe that they are wrong. ChromeOS netbooks may be a failure, but the basic model is sound and there are strong economic reasons behind Google push in the enterprise. Yes- I said enterprise, because ChromeOS is a pure enterprise play, something that I already wrote about here. I would like to point out a few specific reasons I believe that ChromeOS, in some form or the other, will probably appear as a strong enterprise contender:
- It is *not* a thin client. Several commentators argued that a ChromeOS netbook is essentially a rehash of some old thin client of sort, with most people presenting a parallel between ChromeOS and Sun Ray clients. But ChromeOS is designed to execute web applications, where the computational cost of the presentation and interaction layer is on the client; this means that the cost per user for providing the service is one order of magnitude lower than bitmap-based remotization approaches. How many servers would be necessary to support half a billion Facebook users if their app was not web based, but accessed through an ICA or RDP layer? The advantages are so overwhelming that nowadays most new enterprise apps are exclusively web-based (even if hosted on local premises).
- It is designed to reduce maintenance costs. The use of the Google synchronization features and identity services allows for management-as-a-service to be introduced fairly easily; most thin clients infrastructures require a local server to act as a master for the individual client groups, and this adds costs and complexities. The extremely simple approach used to provide replication and management is also easy to grasp and extremely scalable; provisioning (from opening the box to begin useful work) is fast and requires no external support – only an internet connection and a login. This form of self-service provisioning, despite brochure claims, is still unavailable for most thin client infrastructures, and when available it is extremely costly in terms of licensing.
- Updates are really failsafe. Ed Bott commented that “Automatic updates are a nightmare”, and it’s clear that he has quite a deep experience with the approach used by Microsoft. It is true that automatic updates are not a new thing – but the approach used by ChromeOS is totally different from the one used by MS, Apple or most Linux distributions. ChromeOS updates are distributed like satellite set-top box updates – whole, integrated new images sent through a central management service. The build process ensures that things work, because if something happens during the build the image will simply not be built – and distributed. Companies scared by the latest service pack roulette (will it run? will it stop in the middle, making half of the machines left broken in the rain?) should be happy to embrace a model where only working updates are distributed. And, just as a comment, this model is possible only because the components (with the exception of Flas) are all open source, and thus rebuildable. To those that still doubt that such a model can work, I suggest a simple experiment: go to the chromiumos developer wiki, download the source and try a full build. It is quite an instructive process.
- The Citrix receiver thing is a temporary stopgap. If there is a thing that confused the waters in the past, it was the presentation done by Citrix of the integrated Receiver for the ICA protocol. It helped to create the misconception that ChromeOS is a thin-client operating system, and framed in a wrong way the expectations of users. The reality is that Google is pushing for a totally in-browser, HTML5 app world; ICA, RDP and other remotization features are there only to support those “legacy” app that are not HTML5 enabled. Only when the absolute majority of apps are web based the economics of ChromeOS makes sense.
On the other hand, it is clear that there are still substantial hurdles- actually, Google approach with the Chromebooks may even fail. In fact, I am not a big fan of the notebook format for enterprise computing, where a substantial percentage of users are still on the desk, and not nomadic. I believe that having a small, very low cost device is more interesting than leasing notebooks, especially if it is possible to lower the cost of the individual box to something like 100$ (yes – believe me, it is actually possible). Also, Google must make it easier to try ChromeOS on traditional PCs, something that at the moment is totally impossible; a more generic image, executed from a USB key, would go a long way towards demonstrating the usefulness of the approach.
Composing the Open Cloud puzzle
“When it rains, it pours”: This was my first thought while reading the RedHat announcement of yet another cloud project, OpenShift (a new PaaS) and Cloudforms (IaaS). The excellent Stephen O’Grady of RedMonk provided a very complete Q&A covering the announcement and the implications quite well. This is just the last of many, many announcements in the same line, that makes the Open Source cloud environment a very active and crowded one.
What exactly was announced? RedHat leveraged its acquisition of Makara, a PaaS vendor with a quite interesting technical solution, and its own Jboss/DeltaCloud platform to create a combination of PaaS and IaaS, designed to facilitate deployment and management of Java, PHP, Python and Ruby applications. It falls in a market that recently saw VMWare’s entry in the market with CloudFoundry, previous entrants like Eucalyptus, OpenNebula, Nimbus, OpenStack and the still unreleased Yahoo IaaS.
It would seem that there is really too much to choose from-but the reality is that each piece does have a place, and the biggest problem in finding this place is that we forget to look at the big picture that is on the puzzle box. The first point is that there is no single market for cloud/IaaS/PaaS/whatever. There are several distinct areas, and for every one there is a potentially different combination:
- the software (SaaS) producer, that for small scales may be interested in hosting its own small IaaS+PaaS, with the opportunity to move it or dynamically expand outside (on Amazon, for example) when bursts come in. People still think that every company has a full swing of consumption, from very little to galactic scale, while the majority of SaaS producers tend to have a very static set of customers, and acquisitions are slow (compared to procurement time) and easily managed. With a full cloud you pay an extra for scalability – the capability to grow dynamically leap and bounds, and that extra may not be economically justified. Also, many companies already invested in hardware and networking for their own in-house small datacenter, and until the amortment period is ended those companies (for financial and fiscal reasons) would not turn to a full external cloud. So, the next best thing is to create their own little IaaS (for single customer instances), PaaS (for shared customers) on the hardware they already have. The economics here is related to the reduction in management costs, and the opportunity to simplify code deployment.
- The Telcos: my own sources indicate that lots of telcos are working feverishly to create their own cloud offering, now that there is a potential solution that has no license costs. They could have built it earlier with VMWare or Citrix, but the licensing alone would have placed them out of the market; with the new open source stacks, with a relatively limited investment it is possible to reuse the massive hardware cache already in house to consolidate and offer a IaaS to individual customers, usually mid-to-large companies willing to outsource their varying computational loads outside, or directly dematerialize their server farm. It is mostly a transitional market, that will however be important for at least 5 years from now.
- The System Integrators: large scale INT and consultancies are pushing a set of integrated offerings that cover everything – technical, management, legal and procurement aspects for companies that are willing to move their IT completely off their backs. It is not a new model – Accenture, Atos Origin et al are doing it since the beginning of time – but thanks to the availability of open source components it does provide a more compelling economics.
- The small VARs: there is a large number of very small companies, that targets the very low end of the market, and that provide a sort of staircase to the cloud for small and mostly static workloads. It is a market of small consultants, system administrators, and consultancies that cover that part of the market that is largely invisible for larger entities, and that is starting to move towards web apps, hosted email and so on – but still need to manage some legacy system that is currently in-house.
- The service provider: it just started as a movement, but in my opinion will become quite big: the specialized and cloud-based service (an example is the freshly released Sencha.io). I believe that those specialized providers will be among the most important contributors to the individual OSS components, that are internally used to deliver a service, and will provide a backbone of updates for most of the ancillary parts like storage, DB, identity and so on.
And the obvious question is: who will win? In my view, if every actor works properly, there will be more than a dominant actor. The reason is related to the two main factors of adoption, that is packaging and acceleration. Packaging is the ease of installation, deployment, management and in general user and developer-friendliness of the whole. So, taking for granted that RedHat will open source it (as it did with all the previous acquisitions) the main advantage for OpenShift and CloudForms will be ease of installation for RedHat and clone users – that are still the majority of enterprise Linux deployments. It will be natural for a RHEL user to start converting some servers into a RedHat IaaS and PaaS, given the fact that systems will also fall under a simplified management through RHT Satellites; the main interest in this case will be for system integrators and developers that already standardized under RedHat. A potential future enhancement could be the push towards a better identity management (a sore point for most IaaS, with the exception of the Grid-inspired Nimbus): RedHat does have a good Java-based provisioning and identity server in-house, that can probably be expanded with external tools like ForgeRock’s OpenIM/OpenIDM. The first one that will solve the “cloud identity” problem will actually have a gold mine in its hands.
OpenStack is more relevant for bare-metal installs, and will probably get the majority of new, unbranded installs thanks to its massive acceleration – the incredible rate of change that is clearly visible by the amount of new features delivered in any release. The combination of OpenStack and CloudFoundry is probably of interest mainly for large companies that want to create an internal development environment (reducing developer friction) – in this sense, I believe that the market for secondary services will be probably limited, but with a substantial contribution from “independents” that improve the platform to facilitate their own internal jobs.
The end result is that we will still see several competing platforms, each evolving to occupy a niche and taking (and giving) pieces of code to the others. The obvious result will be the pressure on proprietary vendors, that in my opinion will have a very hard time to keep the same development pace of these collaboratively developed solutions.
Nokia is one of the most active Android contributors, and other surprises
Posted by cdaffara in blog, divertissements on April 22nd, 2011
Updated: added other examples from WebKit, IGEL and RIM
Yes, it may be a surprise, but that’s the beauty of Open Source – you never know where your contributions will be found. In this regard, I received a gentle mention from my friend Felipe Ortega of the Libresoft group of a nice snippet of research from Luis Canas Diaz, “Brief study of the Android community“. Luis studied the contributions to the Android code base, and splitted the contributions using the email of the originator, assigning those with “google.com” or “android.com” as internal, and classifying the others. Here is a sample of the results:
| # Commits | Domain |
|---|---|
| 69297 | google.com |
| 22786 | android.com |
| 8815 | (NULL) |
| 1000 | gmail.com |
| 762 | nokia.com |
| 576 | motorola.com |
| 485 | myriadgroup.com |
| 470 | sekiwake.mtv.corp.google.com |
| 422 | holtmann.org |
| 335 | src.gnome.org |
| 298 | openbossa.org |
| 243 | sonyericsson.com |
| 152 | intel.com |
Luis added: “Having a look at the name of the domains, it is very surprising that Nokia is one of the most active contributors. This is a real paradox, the company that states that Android is its main competition helps it!. One of the effects of using libre software licenses for your work is that even your competition can use your code, currently there are Nokia commits in the following repositories:
git://android.git.kernel.org/platform/external/dbus
git://android.git.kernel.org/platform/external/bluetooth/bluez”
In fact, it was Nokia participation in Maemo (and later Meego) and its funding of the dbus and bluez extensions that were later taken up by Google for Android. Intrigued by this result, I made a little experiment: I cloned the full Android gingerbread GIT repo (2.3), separated the parts that are coming from preexisting projects like the Linux kernel and the various external dependencies (many tens of project – included, to my surprise, a full Quake source code…) leaving for example Chromium but removing WebKit. I then took apart the external projects, and counted Google contributions there in an approximate way, and folded back everything. You get a rough size of 1.1GB of source code directly developed or contributed by Google, which means that around 75% of the source code of Android comes from external projects. Not bad, in terms of savings.
Update: many people commented on the strangeness of having fierce competitors working together in ways that are somehow “friendly” towards a common goal. Some of my twitter followers also found the percentage of 75% of non-Google contributions to be high, and this update is meant to be an answer for both. First of all, there is quite a long history of competitors working together in open source communities; the following sample of Eclipse contributors provide an intial demonstration of that:
But there are many other examples as well. WebKit, theweb rendering component used in basically all the mobile platforms (except Windows Mobile) and on the desktop within Chrome and Safari was originally developed by the KDE free software community, taken by Apple and more recently co-developed by Nokia, Samsung, RIM and Google:
And on WebKit page, it is possible to find the following list:
“KDE: KDE is an open source desktop environment and application development framework. The project to develop this software is an informal association. WebKit was originally created based on code from KDE’s KHTML and KJS libraries. Although the code has been extensively reworked since then, this provided the basic groundwork and seed code for the project. Many KDE contributors have also contributed to WebKit since it became an independent project, with plans that it would be used in KDE as well. This has included work on initially developing the Qt port, as well as developing the original code (KSVG2) that provides WebKit’s SVG support, and subsequent maintenance of that code.
Apple: Apple employees have contributed the majority of work on WebKit since it became an independent project. Apple uses WebKit for Safari on Mac OS X, iPhone and Windows; on the former two it is also a system framework and used by many other applications. Apple’s contribution has included extensive work on standards compliance, Web compatibility, performance, security, robustness, testing infrastructure and development of major new features.
Collabora: Collabora has worked on several improvements to the Qt and GTK+ ports since 2007, including NPAPI plugins support, and general API design and implementation. Collabora currently supports the development of the GTK+ port, its adoption by GNOME projects such as Empathy, and promotes its usage in several client projects.
Nokia: Nokia’s involvement with the WebKit project started with a port to the S60 platform for mobile devices. The S60 port exists in a branch of the public WebKit repository along with various changes to better support mobile devices. To date it has not been merged to the mainline. However, a few changes did make it in, including support for CSS queries. In 2008, Nokia acquired Trolltech. Trolltech has an extensive history of WebKit contributions, most notably the Qt port.
Google: Google employees have contributed code to WebKit as part of work on Chrome and Android, both originally secret projects. This has included work on portability, bug fixes, security improvements, and various other contributions.
Torch Mobile: Torch Mobile uses WebKit in the Iris Browser, and has contributed significantly to WebKit along the way. This has included portability work, bug fixes, and improvements to better support mobile devices. Torch Mobile has ported WebKit to Windows CE/Mobile, other undisclosed platforms, and maintains the QtWebKit git repository. Several long-time KHTML and WebKit contributors are employed by Torch Mobile.
Nuanti: Nuanti engineers contribute to WebCore, JavaScriptCore and in particular develop the WebKit GTK+ port. This work includes porting to new mobile and embedded platforms, addition of features and integration with mobile and desktop technologies in the GNOME stack. Nuanti believes that working within the framework of the webkit.org version control and bug tracking services is the best way of moving the project forward as a whole.
Igalia: Igalia is a free software consultancy company employing several core developers of the GTK+ port, with contributions including bugfixing, performance, accessibility, API design and many major features. It also provides various parts of the needed infrastructure for its day to day functioning, and is involved in the spread of WebKit among its clients and in the GNOME ecosystem, for example leading the transition of the Epiphany web browser to WebKit.
Company 100: Company 100 has contributed code to WebKit as part of work on Dorothy Browser since 2009. This work includes portability, performance, bug fixes, improvements to support mobile and embedded devices. Company 100 has ported WebKit to BREW MP and other mobile platforms.
University of Szeged: The Department of Software Engineering at the University of Szeged, Hungary started to work on WebKit in mid 2008. The first major contribution was the ARMv5 port of the JavaScript JIT engine. Since then, several other areas of WebKit have been tackled: memory allocation, parsers, regular expressions, SVG. Currently, the Department is maintaining the official Qt build bots and the Qt early warning system.
Samsung: Samsung has contributed code to WebKit EFL (Enlightenment Foundation Libraries) especially in the area of bug fixes, HTML5, EFL WebView, etc. Samsung is maintaining the official Efl build bots and the EFL early warning system.”
So, we see fierce competitors (Apple, Nokia, Google, Samsung) co-operating in a project that is clearly of interest for all of them. In a previous post I made a similar analysis for IGEL (popular developers of thin clients) and HP/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. …. 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.”
This is the real end result: it would be extremely difficult for companies to compete without the added advantage of Open Source. It is simply anti-economic to try to do everything from scratch, while competing companies work together on non-differentiating elements; for this reason it should not be considered a strange fact that Nokia is an important contributor to Google Android.
A small WebP test
Posted by cdaffara in blog, divertissements on April 21st, 2011
I was quite intrigued by the WebP image encoding scheme created by Google, and based on the idea of a single-frame WebM movie. I performed some initial tests during initial release, and found it to be good but probably not groundbreaking. But I recently had the opportunity to read a blog post by Charles Bloom with some extensive tests, that showed that WebP was clearly on a par with a good Jpeg implementation on medium and high bitrates, but substantially better for small bitrates or constrained encodings. Another well executed test is linked there, and provide a good comparison between WebP, Jpeg and Jpeg2000, that again shows that WebP shines – really – in low bitrate condition. So, I decided to see if it was true, took some photos out of my trusted Nokia N97 and tried to convert them in a sensible way. Before flaming me about the fact that the images were not in raw format: I know it, thank you. My objective is not to perform a perfect test, but to verify Google assumptions that WebP can be used to reduce the bandwidth consumed by traditional, already encoded images while preserving most of the visual quality. This is not a quality comparison, but a “field test” to see if the technology works as described. The process I used is simple: I took some photos (I know, I am not a photographer…) selected for a mix of detail and low gradient areas; compressed them to 5% using GIMP with all Jpeg optimization enabled, took notice of size, then encoded the same source image with the WebP cwebp encoder without any parameter twiddling using the “-size” command line to match the size of the compressed Jpeg file. The WebP image was then decoded as PNG. The full set was uploaded to Flickr here, and here are some of the results:
Photo: Congress Centre, Berlin. Top: original Jpeg. middle: 5% Jpeg. Bottom: WebP at same Jpeg size.
Photo: LinuxNacht Berlin. Top: original Jpeg. middle: 5% Jpeg. Bottom: WebP at same Jpeg size.
Saltzburg castle. Top: original Jpeg. middle: 5% Jpeg. Bottom: WebP at same Jpeg size.
Venice. Top: original Jpeg. middle: 5% Jpeg. Bottom: WebP at same Jpeg size.
There is an obvious conclusion: at small file sizes, WebP handily beats Jpeg (and a good Jpeg encoder, the libjpeg-based one used by GIMP) by a large margin. Using a jpeg recompressor and repacker it is possible to even a little bit the results, but only marginally. With some test materials, like cartoons and anime, the advantage increases substantially. I can safely say that, given these results, WebP is a quite effective low-bitrate encoder, with substantial size advantages over Jpeg.
Recent Comments