I had the great pleasure to converse on twitter along with the exceptional Simon Wardley, a longtime expert and researcher on company innovation, evolution and.. cloud computing. Among the limit of 140 characters, it was quite difficult to convey any sensible concept in such a short space. One of the interesting thing is that it is difficult to provide a sensible comparison between private and public clouds in absence of real numbers. So, since we just finished a research report for a major UK public authority, I will just add my own 2 eurocents and present a summary table of some examples of private, public and dedicated cluster costs:
System $/Core-hour Hopper  $0.018 Montero-Llorente  $0.04 Magellan (overall)  $0.04 Class 1 server/workstation  $0.046 Cornell RedCloud  $0.058 Our estimate $0.06 Amazon cc1.4xl, resv. instance $0.062 Amazon cc1.4xl $0.093 CINN  $0.1
This is of course just a snippet of more than 40 pages; cost includes management and amortization over 3 years for hardware, 5 years for infrastructure. Our own estimate is for a self-managed, self-assembled system with no best practices, while Magellan is a realistic estimate of a median cost for a well-managed and well-procured infrastructure. Hopper is a custom cluster out of commodity hardware and can be considered the best approachable price point for 2011 in terms of cost/core for a private cloud as well. In the paper (that I hope will be published soon) there will be additional details on the actual model, the estimates and the sources for the data. Hope it may be useful for someone.
(this is a repost of the original article with some corrections. Includes the Oxford TransferSummit 2011 presentation based on this data)
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.
We were particularly happy about out work on EveryDesk – a portable, fully working live Linux installation on a USB disk. But we found out that more and more people were looking for more space, a more modern environment, and in general to refresh things. We have been busy with out other pet project – CloudWeavers, a private cloud toolkit, and we redesigned EveryDesk to be the ideal client environment for companies and administrations that are moving totally or partially to a private or public cloud. We took several ideas from ChromeOS, but frankly speaking the hardware support was extremely limited, and even with exceptional ports like Hexxeh’s “Lime” the user experience is still less than optimal. We have basically redesigned everything – the base operating system is now derived from OpenSuse (mainly thanks to the excellent package management tool, that drastically increases the probability that the system would continue to work after an update – a welcome change from Ubuntu), we integrate Gnome 3, the latest Firefox and Chromium on a BTRFS install that supports compression and error concealment, so it works properly even on low-cost USB devices. On an 8Gb USB key, you get 4Gb free, and all the apps at your disposal, ready to go.
The only major change in hardware support is the fact that EveryDesk is now a 64-bit only operating system, but we believe that despite the limitation it can still be useful at large. It integrates some components that are maybe less interesting for individual use – for example the XtreemFS file system, that can be used to turn individual PCs into scale-out storage servers in a totally transparent way, and with great performance, or many virtualization enhancements. On the user side, we already installed some of our favorite additions among fonts, software, and tools; Firefox uses by default the exceptional Pdf.js embedded viewer, that uses no separate plugins and is faster than Adobe Acrobat, and there is the usual assortment of media codecs and ancillary little things.
We love every moment that we work on this project, and I would like to thank the many people that helped us, sent criticisms and praises. One wrote “I can’t believe how well it works, without time lags I normally associate with running on a CD or a thumb” and I can’t thank our users enough – they are our real value. As usual, you can download EveryDesk from Sourceforge.
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.
First of all, Judge Alsup had not 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.)
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!”.
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).
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.
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.
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.
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 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.
“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.