LWN.net Weekly Edition for March 5, 2009

How (not) to run a developer program

The Android developer phone (ADP1) is a nice piece of hardware which allows freedoms that the T-Mobile standard-issue G1 does not allow. As the name might imply, it is targeted at developers so that they can more easily develop applications for the Android Market, but also so that they can hack on the Android platform itself. So far, though, the Android development community has been less-than-satisfied with the development support provided by Google. In fact, the recent decision to disallow access to copy-protected applications in the Android Market has a lot of ADP1 purchasers up in arms. But that isn't the only thing that has annoyed—or worse—Android hackers.

The idea behind a developer program is, or should be, that developers get early access to the code that customers will soon be running, so that they can test their applications—finding and fixing bugs before the general public ever sees them. For whatever reason—manpower is the oft-stated problem—Google has turned this on its head. Customers who purchase the consumer version (i.e. G1), will get the RC33 version (in the US, European version numbering is different) of the firmware. The G1 phones ship with an earlier version, but an over-the-air upgrade will eventually bring them up to that version. For developers who purchased an ADP1, however, there is no equivalent upgrade, at least officially.

There has been a fair amount of complaining about the lack of an ADP1 upgrade on the android-developers mailing list. Jean-Baptiste Queru, who seems to be the Android engineer who was selected or volunteered to answer questions on the list, is unhappy about the delay—and lack of information—as well:

The 1.1 firmware release for the ADP1 is supposed to have more-or-less equivalent functionality to the RC33 release for the G1. But what, exactly, that release will contain is still a closely-held secret. That seems to be one of the biggest complaints about how Google is treating Android developers: lack of information. The problem with copy-protected applications for the ADP1 is just another example.

Android offers application developers two restrictions that they can apply to their programs in the Android Market: for-sale and copy-protection. It is believed that most for-sale applications will also carry the copy-protection restriction, but that is not required. Gratis applications can also be copy-protected if the developer wishes to do so.

The ADP 1.0 code does not allow access to either kind of application in the Market. ADP 1.1 is believed to relax that restriction to only those that specify copy-protection, though that may not be much different in practice. The reasoning, according to Queru, is that "copy-protected apps aren't offered on devices where the copy-protection is known to be ineffective." Because the ADP1 phones are unlocked, there are various ways that the copy protection could be overridden.

The fear seems to be that developers might pay for an application, then squirrel it away and apply for a refund. Developers could restore the deleted application after receiving the refund or copy it to other phones. While that is a possibility, it leaves some feeling like developers are being singled out as pirates. One of the problems is that folks who have gotten root access on their G1 phones can access copy-protected applications. In the end, folks who want to pirate applications—be they developers or consumers—will find a way to do it.

It is a time-honored tradition amongst software developers to check out the competition. Many of the hobbyist developers hoping to strike it rich with Android Market applications purchased the ADP1 in the belief that it would have the same functionality that the consumer version does. Now they have found out that they can't purchase competitor's applications (at least in the likely case that they are copy-protected), on top of the realization that they can't get a blessed version of the latest code. Other ADP1 purchasers were looking to get around the geographic and/or cellular carrier restrictions of the G1, but now have a phone with fewer capabilities.

There are alternative firmware loads for the ADP1, but it doesn't sit well that Google has yet to provide one. A somewhat popular alternative is to use the so-called "holiday" version—the version that shipped on the ADP1s that Google gave its employees as a holiday bonus. Interestingly, that code does not allow accessing copy-protected Market applications either, which makes it likely that the restriction is simply an attempt to be consistent about copy protection, as Queru stated, rather than a real belief that developers are more likely to be pirates.

Google could have avoided much of the outcry by being more transparent—something the company seems to have a general problem with—and by paying more attention to its developer program. The official developers blog does not seem to cover many of the areas that are of concern to the community. One must wander through the mailing list or third-party sites to find information about the restriction on copy-protected applications, for example.

There are alternative mechanisms for handling copy protection, of course. Several were bandied about on the mailing list as the "forward locking" scheme—essentially signing the application in such a way that it won't run on other phones—is seen as suboptimal. The alternatives are other forms of DRM, however, as Queru points out:

Developers just want a phone that can do what they need it to, so some are starting to feel like they made a bad decision by purchasing the ADP1. That has led to suggestions that folks should just sell their ADP1 and use the emulator or a G1 phone to do their development. That may be a bit of an extreme reaction, but there are probably some who have done that or are considering it. A bigger worry for Google might be that they decide to ditch the Android platform entirely for something more developer-friendly.

Some have portrayed Android as the future of the Linux desktop—on phones and netbooks at least—but the problems that are currently being experienced on phones could well spill over. DRM and locking devices to particular vendors are not "features" that people normally associate with Linux and free software, but they are being demanded by some vendors. Those kinds of restrictions are really meant to keep consumers from reaping the benefits of freedom. While folks may be used to that treatment from mobile phones, one hopes they don't have to get used to it from their computers as well.

Comments (22 posted)

Third time is the charm?

Almost two years ago, your editor sat on an Open Source Business Conference panel with Microsoft's Sam Ramji, who made the point that Microsoft had only launched patent infringement lawsuits twice in its existence. Given that, worries about the Microsoft/Novell patent deal were, in his opinion, misplaced. Last week, it was revealed that the count has gone up to three: Microsoft has filed a lawsuit against TomTom, a maker of Linux-based navigation devices. There is much speculation and uncertainty on the net as to just what this action means. Your editor means to add to it by saying that Microsoft's intentions would appear to be relatively clear.

The patents which TomTom is alleged to be infringing are:

• 6,175,789 (Vehicle computer system with open platform). This patent, filed in 1999, covers the innovative concept of mounting a computer in a vehicle dashboard. Literally, that is all there is to it.

• 6,202,008 (Vehicle computer system with wireless internet, 1999). This one extends the previous patent by adding an Internet connection to the dashboard-mounted computer.

• 7,054,745 (Method and system for generating driving directions, 2003), appears to cover the basic turn-by-turn instructions provided by just about any navigation unit on the market.

• 6,704,032 (Methods and Arrangements for Interacting with Controllable Objects within a Graphical User Interface Environment Using Various Input Mechanisms, 2000). This patent is relatively impenetrable, but appears to cover a framework for binding responses to user interface events.

• 7,117,286 (Portable computing device-integrated appliance, 2005). The deep concept here appears to be recognizing a docking station and causing the user interface to configure itself accordingly.

• 5,579,517 (Common name space for long and short filenames, 1995) and 5,758,352 (Common name space for long and short filenames, 1996). These are the infamous patents on the long filename hacks embedded in the VFAT filesystem.

• 6,256,642 (Method and System for File System Management Using a Flash-Erasable, Programmable, Read-only Memory, 1992). This one covers a fairly straightforward mechanism for managing flash memory by dividing large erase blocks into filesystem-sized blocks and allocating them independently.

The first two patents in this list appear to be laughable indeed; it is hard to see how they can pass the obviousness test. This is especially true in light of the KSR v. Teleflex ruling, wherein it was decided (also in the automotive setting) that the idea of connecting a floor pedal to an electronic throttle control was too obvious to patent. The navigation patent would appear to be infringed by anybody who sits in the passenger seat and helps the driver find a destination. The docking station and GUI patents seem less clear, but it doesn't seem like it should be all that hard to find suitable prior art.

That leaves the final three patents, all of which are relevant to the Linux platform. Like almost every other system on the planet, Linux supports the VFAT filesystem, and, thus, could be argued to infringe upon the relevant patents. The flash patent looks much like the technique used by any system which manages flash memory in anything but the stupidest of ways. It would appear that Microsoft has finally decided to follow through on its longstanding patent threats against Linux.

Of course, not all agree. The 451 Group posted this fairly impressive apology for Microsoft, claiming:

Your editor wishes to politely dismiss this talk as dangerous nonsense. There is nothing special about TomTom's kernel with regard to these patents. One would think that it would make little sense for TomTom to go into the kernel source and create its own special version of VFAT which infringes on Microsoft's patents. Of course, embedded systems developers have been known to do some very strange things, so one cannot take TomTom's good sense for granted in this situation. So, for the definitive word, we will refer to Harald Welte's take on TomTom's kernel:

If TomTom is infringing Microsoft's patents, then everybody who is running Linux is infringing those patents. This is an attack against Linux; TomTom has just been given the honor of being the first defendant.

Microsoft's motivation would seem to be clear. The company has tried for years to sell versions of Windows into the embedded systems market, with success best described as "modest." Linux is hard to compete against in these systems; it is highly portable, can be customized to an arbitrary degree, offers support from multiple vendors, and can be shipped with no royalty charges. Microsoft would like to take away some of those advantages by imposing a patent tax on embedded Linux deployments. Embedded systems vendors cannot miss this message: they can pay licensing fees, or they can pay legal fees.

The obvious question at this point is: what now? The VFAT patents may appear to fail the obviousness test; they could also run into difficulties stemming from the Bilski decision. These patents are problematic, though: the Public Patent Foundation tried hard to invalidate these patents in 2004, only to have them reinstated by the US patent office in 2006. As a result, there will be a certain presumption of validity which could prove hard to overcome in court. It has often been said that attempts to invalidate patents carry risks; what doesn't kill a patent may well make it stronger.

Your editor would certainly not advise anybody to give up on efforts to defeat these patents, but the possibility that they could stand must be considered. The loss of the VFAT filesystem would be painful. It is a poor filesystem, but it has become a sort of de facto interchange format for storage-oriented devices. Without VFAT, Linux users would encounter difficulties working with their digital cameras, cellular telephones, and music players. Sharing storage devices with Windows systems would become harder. VFAT would become a technology like MP3: unavailable on many Linux systems until installed from some third-party repository on the net.

Avoiding this outcome seems desirable. One way would be to defeat these patents in court. To that end, one can only hope that TomTom will stand up to this attack and defend its rights. The rest of the industry would be well advised to consider helping TomTom in this fight. This case, if fought to its conclusion, will certainly be expensive. But the cost of not fighting it seems certain to be much higher.

Another way to deal with the VFAT patents would be to start a serious look for workarounds - a technique which the free software community does not, yet, make enough use of. Patents tend to be tightly written, meaning that workarounds are often possible with relatively small changes. It may well be possible to make changes to the VFAT filesystem which pass the patent-lawyer test while maintaining interoperability with other systems.

Indeed, a suitably clever lawyer might be able to argue that Linux already operates outside the patent; the claims require that the long filename include "more than the maximum number of characters that is permissible by the operating system," something which is clearly not the case on Linux. Your editor, however, is neither a lawyer nor suitably clever; this kind of determination will need to be made by others.

At the upcoming Linux Foundation Collaboration Summit, your editor will be running a panel on kernel development. Sam Ramji, alas, will be in the other room at that time, sitting on a panel entitled "Why Can't We All Just Get Along: Linux, Microsoft & Sun." One can imagine the course this discussion is going to take; Sun is likely to get off easy. Parts of Microsoft (especially those represented by Mr. Ramji) have been making friendly noises toward open source for some time. But actions speak louder than friendly noises, and this particular action speaks loudly indeed. Parts of Microsoft are almost certainly sincere about wanting to get along with the Linux community, but the stronger forces within the company, it seems, are not.

Comments (62 posted)

Ubuntu debates usability changes

Ever since last July, when Mark Shuttleworth called on Ubuntu to surpass Mac OS X in desktop design within two years, Ubuntu mailing lists and blogs have become one of the main places to go for detailed discussions about GNU/Linux usability. However, the discussions can become convoluted and acrimonious, as developers argue the logic of design principles. A case in point is the discussion of Ubuntu's new notification guidelines on the ubuntu-devel list over the past two weeks, which quickly turned into a discussion of whether notifications should be used at all.

The discussion centers around the new guidelines for notification messages, which typically appear by the notification tray in GNOME. These guidelines were announced in Mark Shuttleworth's blog entry for February 21. Both the blog and the guidelines include screen shots to illustrate what they are describing.

The problem is that the now-standard notification bubbles (so-called for their shape) are easily missed because they disappear after a few seconds, and they often point to icons in the system tray, which users may find hard to click. For these reasons, the guidelines call for a reduction in their use, although acknowledging the possibility that they might still be useful in unspecified circumstances.

Whenever possible, notification bubbles will, in the next Ubuntu release, be replaced with a notification in an existing window; for instance, when a web browser has blocked up a popup, the notification could display in a dialog above the web page, using the browser's built-in notification system. More radically, when a notification needs user input, but doesn't need an immediate response — for instance, when a printer is detected, but the necessary driver is missing — it will be displayed in an alert box that opens beside the system tray without taking the focus away from the user's current window.

In cases such as a low battery reading, when a quick response is needed, the window or alert box will display the basic message, followed by, when the user clicks it, a dialog, possibly with a different color background. The guidelines refer to this arrangement as "morphing," and suggest that it will help prevent the accidental selection of a button when the cursor moves to the dialog. Why accidental selection is perceived as a problem, though, is unspecified.

The advantages of the proposed alert boxes is that, unlike notification bubbles, they remain on the desktop, and provide dialogs that are easier to click than a system tray icon.

Discussion of these new guidelines quickly followed Shuttleworth's blog entry, wandering across several threads in ubuntu-devel in February and March. Some of the discussion called for citations to support a usability assertion, as when Jordan Mantha told Mat Tomaszewski of the Canonical design team, the group responsible for the guidelines, that "'trust us, we have our reasons' is not going to very convincing to many people."

As discussion continued, it soon became apparent that at least some Ubuntu designers outside Canonical distrust those employed by the company. For instance, Scott Kitterman remarked:

Similarly, Martin Owens complained that "It's as if the people at Canonical had taken a politics course and decided to deliberately alienate those people who are not inside of Canonical."

To such comments, Mat Tomaszewski replied several times, with patience and enthusiasm for the tasks at hand, while Matthew Paul Thomas, another Canonical employee, explained in a similar tone that usability efforts were just getting started, and were expensive enough that "much of the time we will have to rely on common sense".

At one point, the language became so heated that Mark Shuttleworth intervened to call one developer's comments "not constructive" — a rare occurrence on Ubuntu lists compared to those of some projects, due to the code of conduct by which developers agree to abide.

However, for the most part, discussion remained civil. Matthew Paul Thomas defended the new guidelines, pointing out that:

Thomas also summarized potential problems with notice bubbles: either they disappear after a few seconds and can disappear before users notice them, or else they persist and distract users. In addition, alerts and windows are easier to use than small, often indistinguishable icons.

By contrast, Lars Wirzenius presented a case against all notifications, saying flatly that:

All Wirzenius wanted was essential notifications, suggesting that "All applications should, in my opinion, strive to interrupt the user as little as possible, especially by default."

Wirzenius' position was soon challenged by other developers in ways that show some of the considerations necessary in usability design. Chow Loong Jin questioned Wirzenius' assertion that default settings should be designed for those who use their computer as a "tool" rather than a "toy," arguing that the tool users would know how to change the defaults while the toy users would not.

Similarly, Ted Gould contended that, since toy users are probably a majority, the defaults should be settings that they want. In the same post, he also suggests that:

However, Tomaszewski indicated that some ability to change levels of notifications would be available via a "Do not disturb" mode that would block at least some standard notifications.

What made this discussion especially interesting was how it brought out both the general and specific issues that arise in usability. For instance, Mathew Paul Thomas responded to the suggestion that using an application at full-screen size should disable notifications by pointing out that:

Thomas also warned that:

In much the same way, Tomaszewski stated:

Yet another post, this time by Bruce Cowan, summarized the problems with any sort of dialog. The sudden appearance of windows and alerts, Cowan suggested, is confusing, and could make users worry that a piece of malware has started an application. In addition, too many dialogs could frustrate users, to the point that some disable them altogether, so that over-use of the system could defeat the entire purpose of providing timely warnings. As for the changes in the new guidelines, Cowan suggested that they may annoy experienced users who see little wrong with notification bubbles.

Whether these discussions will have any effect on the Ubuntu Design or Desktop Experience Team seems uncertain, since the guidelines are already being used in alpha versions of the upcoming Jaunty release. All the same, they are the sort of discussions that Ubuntu developers are likely to be having for the next eighteen months as they try to realize Shuttleworth's goal of increased usability, especially in the absence of hard data to show what designs are most usable. They are likely, too, to have them again, as they attempt to have their changes accepted upstream by projects like GNOME. However, for others, they show the punctilious but necessary considerations that usability generally involve — considerations that many free and open source software projects are only just starting to face.

Comments (42 posted)