Posts Tagged android

Naughton, Android, the GPL and why I’m fuzzy minded.

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 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.)

, ,

No Comments

It could have been different: Android, Google and all that

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.

, , ,

2 Comments

Nokia is one of the most active Android contributors, and other surprises

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:

(Since October 2008)
# 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:

eclipse

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:

Screenshot-Chromium Notes: Who develops WebKit? - Mozilla Firefox

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.

,

29 Comments

The neverending quest to prove Google evilness. Why?

Ah, my favorite online nemesis (in a good sense, as we have always a respectful and fun way of having a disagreement) Florian Mueller is working full-time to demonstrate, in his own words, “a clear pattern of extensive GPL laundering by Google, which should worry any manufacturer or developer who cares about the IP integrity of Android and its effect on their proprietary extensions or applications. It should also be of significant concern to those who advocate software freedom.” Wow. Harsh words, at that, despite the fact that Linus Torvalds himself dismissed the whole thing with “It seems totally bogus. We’ve always made it very clear that the kernel system call interfaces do not in any way result in a derived work as per the GPL, and the kernel details are exported through the kernel headers to all the normal glibc interfaces too” (he also, amusingly, suggested that “If it’s some desperate cry for attention by somebody, I just wish those people would release their own sex tapes or something, rather than drag the Linux kernel into their sordid world”. Ah, I love him.)

In fact, I expressed the same point to Florian directly (both in email and in a few tweets), but it seems very clear that the man is on a crusade, given how he describes Google actions: “the very suspect copying of Linux headers and now these most recent discoveries, it’s hard not to see an attitude. There’s more to this than just nonchalance. Is it hubris? Or recklessness? A lack of managerial diligence?” or “It reduces the GPL to a farce — like a piece of fence in front of which only fools will stop, while “smart” people simply walk around it.”

Well, there is no such thing, and I am not saying this because I am a Google fanboy (heck, I even have a Nokia phone :-) ) but because this full-blown tempest is actually useless, and potentially damaging for the OSS debate.

I will start with the core of Florian arguments:

  • Google took GPL code headers;
  • they “sanitized” it with a script to remove copyrighted information,
  • what is left is not GPL anymore (in particular, is not copyrighted).

Which Florian sees as a way to “work around” the GPL. Well, it’s not, and there are sensible reasons for saying this. Let’s look at one of the incriminated files:

#ifndef __HCI_LIB_H
#define __HCI_LIB_H

#ifdef __cplusplus
#endif
#ifdef __cplusplus
#endif
static inline int hci_test_bit(int nr, void *addr)
{
	return *((uint32_t *) addr + (nr >> 5)) & (1 << (nr & 31));
}
#endif

or, for something longer:

#ifndef __RFCOMM_H
#define __RFCOMM_H

#ifdef __cplusplus
#endif
#include <sys/socket.h>
#define RFCOMM_DEFAULT_MTU 127
#define RFCOMM_PSM 3
#define RFCOMM_CONN_TIMEOUT (HZ * 30)
#define RFCOMM_DISC_TIMEOUT (HZ * 20)
#define RFCOMM_CONNINFO 0x02
#define RFCOMM_LM 0x03
#define RFCOMM_LM_MASTER 0x0001
#define RFCOMM_LM_AUTH 0x0002
#define RFCOMM_LM_ENCRYPT 0x0004
#define RFCOMM_LM_TRUSTED 0x0008
#define RFCOMM_LM_RELIABLE 0x0010
#define RFCOMM_LM_SECURE 0x0020
#define RFCOMM_MAX_DEV 256
#define RFCOMMCREATEDEV _IOW('R', 200, int)
#define RFCOMMRELEASEDEV _IOW('R', 201, int)
#define RFCOMMGETDEVLIST _IOR('R', 210, int)
#define RFCOMMGETDEVINFO _IOR('R', 211, int)
#define RFCOMM_REUSE_DLC 0
#define RFCOMM_RELEASE_ONHUP 1
#define RFCOMM_HANGUP_NOW 2
#define RFCOMM_TTY_ATTACHED 3
#ifdef __cplusplus
#endif
struct sockaddr_rc {
	sa_family_t	rc_family;
	bdaddr_t	rc_bdaddr;
	uint8_t		rc_channel;
};
#endif

What can we say of that? They contain interfaces, definitions, constants that are imposed by compatibility or efficiency reasons. For this reason, they are not copyrightable, or more properly would be excluded in the standard test for copyright infringement, in the abstraction-filtration test. In fact, it would not be possible to guarantee compatibility without such an expression.

But – Florian guesses – the authors put a copyright notice on top! That means that it must be copyrighted! In fact, he claims “The fact that such notices are added to header files shows that the authors of the programs in question consider the headers copyrightable. Also, without copyright, there’s no way to put material under a license such as the GPL.”

Actually it’s simply not true. I can take something, add in the beginning a claim of copyright, but that does not imply that I have a real copyright on that. Let’s imagine that I write a file containing one number, and put a (c) notice on top. Do I have a copyright on that number? No, because the number is not copyrightable itself. The same for the headers included before: to test for copyright infringement, you must first remove all material that is forced for standard compatibility, then Scenes a Faire (a principle in copyright law that says that certain elements of a creative work are not protected when they are mandated by or customary for an environment), then code that cannot be alternatively expressed for performance reasons. What is left is potential copyright infringement. Now, let’s apply the test to the code I have pasted. What is left? Nothing. Which is why, up to now, most of the commentators (that are working on the kernel) mentioned that this was also just a big, large, interesting but ultimately useless debate.

In fact, in the BlueZ group the same view was presented:

“#include <bluetooth/bluetooth.h> is only an interface contract. It contains only constants and two trivial macros. Therefore there is no obligation for files that include bluetooth.h to abide by the terms of the GPL license.  We will soon replace bluetooth.h with an alternate declaration of the interface contract that does not have the GPL header, so that this confusion does not arise again.” (Nick Pelly)

It is interesting that this comes, in and out, in many projects and several times; it happened in Wine (in importing vs. recoding Windows header definitions) and I am sure in countless others. The real value of this debate would be not to claim that Google nearly certainly is an horrible, profiteering parasite that steals GPL code, but to verify that the headers used do not contain copyrighted material, because that would be an extremely negative thing. Has this happened? Up to now, I am still unable to find a single example. Another, totally different thing is asking if this is impolite – taking without explicitly asking permission on a mailing list, for example. But we are not looking at headlines like “Google is impolite”, we are looking at “Google’s Android faces a serious Linux copyright issue”, or “More evidence of Google’s habit of GPL laundering in Android”.

That’s not constructive – that’s attention seeking. I would really love to see a debate about copyrightability of header files (I am not claiming that *all* header files are not copyrightable, of course) or copyrightability of assembly work (the “Yellow Book” problem). But such a debate is not happening, or it is drowned under a deluge of “Google is evil” half proofs.

Of course, that’s my opinion.

, , , , ,

1 Comment

Windows phone 7, Android, and market relevance

Updated: despite the Business Insider claims, the list of motives is actually a perfect copy of those mentioned by Steve Ballmer in a CNN interview, and I also found that the list of motives for the claimed inferiority of Android is actually from 2008, as can be found here. I found quite funny that basically the same motivations apply two years later for a different OS (in 2008 it was Windows Mobile 6.5, a totally different operating system), and are quite similar to the list of motivations from MS to avoid open source – namely, inferior user experience, hidden costs and IPR risks. Maybe Microsoft has not changed so much as it would like to claim.

A recent Business Insider post provided, other than a nice retouched photo of Google’s Schmidt with menacing red eyes, a snippet of conversation with an anonymous MS employee that claimed that Android “free” OS is not free at all, and its costs are much higher than the $15 asked by Microsoft as licensing fees. Having had my stint on mobile economics, I would like to contribute some of my thoughts on what is actually implied by the MS employee, and why I believe that some parts of it are not accurate. Before flaming me as a Google fanboy, I would like to point out that I am not affiliated with Google, MS, anyone else (apart my own company, of course), and my cellphone is a Nokia. Enough said.

OEMs are not using the stock Android build. All Android OEMs are bearing costs beyond “free.” That goes with the definition of OEM – it is hardly a surprising idea. My gripe with the phrase is that the author had, conveniently, conflated the concept of “free” as “freely available operating system” with “free as in I have nothing to do, everything is done for me for free”. The second concept is actually quite uncommon, and I had never met an OEM product manager that believed in something like that. It reminds me a lot of the old taglines used in the infamous MS “comparisons”, that were – with blessings from all – sacked from Microsoft web site. So, in conclusion: yes, you will bear costs other than downloading Android from GIT. And – surprise – I am sure MS will ask for engineering costs for adapting WinPhone7 for any adaptation outside the stock image.

Lawsuits over disputed Android IP have been costly for Android OEMs. (See Apple/HTC, as just one example.) Microsoft indemnifies OEMs who license Windows Phone 7 against IP issues with the product. That is, legal disputes over the IP in Windows Phone 7 directed at OEMs will be handled by Microsoft. This goes a long way toward controlling legal costs at the OEM level. Ah, please, Microsoft – you are so friend of OSS, and you still drum the “IPR violation” song? Anyway, I am quite sure that indemnification can be quite easily acquired, probably from Google or from a third party. It depends on the kind of IPR that the OEM itself does have; in some cases such a patent safety scheme is uneconomical. It is, in any case, a business decision – Symbian did not had indemnification either (or only as an additional product) but that did not stopped Symbian from becoming the most widely used mobile OS.

Android’s laissez faire hardware landscape is a fragmented mess for device drivers. (For background, just like PCs, mobile devices need drivers for their various components—screen, GPS, WiFi, Bluetooth, 3G radio, accelerometer, etc.) Android OEMs have to put engineering resources into developing these drivers to get their devices working. The Windows Phone 7 “chassis strategy” allows devices to be created faster, saving significant engineering cost. It’s essentially plug and play, with device drivers authored by Microsoft. This (apart from the use of the clearly pejorative mention of “fragmented mess” is naturally true. It is also – another surprise – the reason of Windows success, namely the external ecosystem of hardware devices, mostly unpredictable, that were basically developed and managed outside of Microsoft control. After much bashing of Apple’s “walled garden”, now Microsoft seem to imply that the same model that brought them success is now useless, and that to win in mobile you have to adopt Apple centrally managed hardware experience. It may be true, or not – but I suspect that hardware manufacturers will be more happy to create many permutation and device models, designed for different price points and different users, in a way that would be incompatible with MS central control and central device driver development. What happens if I need to push on the market a device that deviates from the MS chassis? Will MS write the driver for me, for free? What if it doesn’t want to write it? The chassis model is nice if you are Apple, and are selling basically a single (or a few) models; if you are going to market with many hardware vendors, you are forcing the same, undifferentiated hardware on all OEM – and this is a great no-no. How are you going to go against competitors that do employ exactly the same model, bill of material, same procurement channel?

Also, this phrase is a clear indication that someone inside of MS still don’t understand what (real) open source is about. The amount of engineering necessary for creating a complex product out of OSS is substantially lower than proprietary alternatives, as I demonstrated here and here; the driver development effort can easily be shared among many different projects that use the same component, lowering the development costs substantially.

Windows Phone 7 has a software update architecture designed to make it easy for OEMs to plug-in their custom code, independent of the OS code. We’ve seen the delays due to Android OEMs having to sink engineering resources into each and every Android update. Some Android OEMs skip updates or stop updating their less popular devices. Because of the unique update architecture, Windows Phone 7 OEMs don’t need to roll their own updates based on the stock build. Costs are reduced significantly. This is another part that is, until Phone 7 is out, difficult to judge. It is a part that I believe stems from an underlying error: OEMs add code to differentiate and to push branded apps and services, not because they have to compensate for an OS missing functionality (especially now, with Android 2.2; Android 1.5 and 1.6 needed some addition from third parties because of lack of features). Carriers, once sold a device, are not that interested in providing updates – after all, you are already locked in a contract. I had seen no official documentation on why Phone7 can be so modular that no engineering is needed even for custom layers on top of the user interface – we will see.

Android OEMs need to pay for licenses for many must-have features that are standard in Windows Phone 7. For example, software to edit Office documents, audio/video codecs (see some costs here), or improved location services (for this, Moto licenses from Skyhook, just as Apple once did). Of course, all of these license fees add up. I like the concept of “must have” – it is widely different for every user and company. For example, I am sure that using Google Docs or Zoho (or Microsoft Web office, that is quite good on its own) would go against the “edit Office documents” part; as for the audio/video codecs, of course you have to license them… unless you use WebM or similar. Or, like many OEM, you are already a licensee for H264 and other covered standards-  in this case, you pay around 1$ per device. As for other services: I found no mention of location services from MS, at least not in the public presentations. If anyone has more details on them, I would welcome any addition.

Windows Phone 7 supports automated testing. Android doesn’t. When OEMs hit the QA phase of the development lifecycle, it’s faster and less expensive to QA a Windows Phone 7 device than an Android device. Again: if you have a single chassis, or a few of them, testing is certainly easier. However, there are quite a few testing suites that allow (through the emulator) to provide a very good automated testing facility.

Finally, Windows Phone 7 comes with great user experiences in the Metro UI, Zune, Xbox LIVE, Exchange, and Visual Studio for app development. Creating these experiences for Android is costly. They’re not baked into the stock build of Android. Well, there are quite a few tools for app development on Android as well. How, exactly, Exchange should be counted as a great user experience is something I am not understanding well, but that is probably a limit of mine.

In synthesis, the new MS concept is “we do it like Apple”. I am not sure that this can work for anyone that is not Apple, though; first of all, because up to now product engineering excellence was not among MS most touted virtues, and because this will in turn go against the differentiation trend that OEM and telcos are pushing to make sure that their brand lines remain unique and appealing enough. How many Phone7 devices can a telco carry? 1? 2? It is possible to imagine a custom Android device for every price point instead – some carriers like Motorola and HTC are already pushing 5,6 devices and more, and low cost handsets are adding even more to the segmentation mix.

, , ,

4 Comments