Going from "open government" to "outsourcing" is a non sequitur meant to set up a straw man. It is outsourcing that results in private firms treating government data as proprietary, and it is this kind of outsourcing that open government initiatives seek to avoid.

It's a long piece. Tl;dr: Think tank wonk mistakes Tim O'Reilly for a technolibertarian and turgidly tilts at windmills of his own invention.

Android app compatibility is available for Linux in several forms: You can install an Android distro in a virtualization container, Canonical's "Ubuntu for Android," Open Mobile's ACL (disclosure, I used to be CTO there), and others.

My view of the best way to do this (and not surprising that this is how Open Mobile does it) is that Android can be integrated into "foreign" desktop environments as if it were a Java SE-like runtime environment.

As for how I would want to use Ubuntu on a tablet, I would put it on a powerful tablet such as those Windows 8 will be shipping on. Then I can have my Android development tools in a tablet form factor, and I can run an x86 Android build in a VM or QEMU for testing/debugging.

Learn Android programming. While this advice is well-founded in personal experience, it may also be slightly self serving.

Not compatible with ASUS T-300 running Jelly Bean. :-(

The right to a patent monopoly is not a fundamental human right.

The US Constitution is written with a specific sense regarding rights. It grants no rights because it takes the point of view that you have human rights, with, or without any government's say so. Instead, the Constitution grants powers to the government.

The right to a patent monopoly is not one of the rights the Constitution assumes you have. That's because, in the eyes of the authors of that document, it's not really a basic human right. Instead, the government is explicitly empowered to grant patent and copyright monopolies. And that power is conditional: "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."

If it isn't functioning as intended, is it still legitimate?

We've put on Mars a large machine that blasts the landscape with a heat ray. A heat ray. And we have set the example that such a machine can be robotic, and impervious to microbes. That's sure to end well.

Is this some kind of weird expression of the New England work ethic? Make the driver work just as hard as ever, but should he ever falter, a superior system kicks in and saves his ass?

If I have a computer that can handle emergencies more reliably than I can, surely it can handle the mundane more reliably, too.

The trend in Android has been, up to now, in the right direction.

For example, the Android Open Source Project originally did not have a development platform build target or reference hardware. Now it does. That means you can take the entire Android Open Source Project and built it and run it, instead of having to "root" a commercial device and port Android to that device before you can start playing with Android on real hardware.

It is in Google's interest to make Android progressively easier to port because Google wants faster and more-consistent updates to Android across all the OEMs using Android. A vibrant and useful AOSP is important to that goal.

Moreover, when faced with a competitor using the Android Open Source Project to build a competing platform and support a competing ecosystem, Google did nothing to thwart AOSP, or to make it harder for Amazon to use AOSP.

Android is partly-open because Google uses a suite of applications and services that are not open source to create commercial Android products with the Google Logo, and OEMs and carriers add their own software to products. There may be room in the market for a more-open mobile OS that isn't tied to big e-commerce ecosystems. Tizen might be one such system, and Jolla might bring Meego back. If those systems prove to be more open, and under less pressure to provide exclusivity to their sponsors, they could turn out to provide truly open, hackable communications devices.

Open communications devices, with open hardware and software, are important because they would enable communications privacy, among other qualities.

The article mistake's Google's lack of direct revenue from Android with revenue of all the different products Google delivers over Android and other mobile OSs. The money-making parts of Google deliver apps to Android, iOS, and other mobile platforms, and make money from those apps.

Facebook has a greater challenge, and is off to a later start, but you have to ask if that's really a worry, compared with getting the mobile launch right. Facebook faces very little competition. Other than Google+, there are no social networks that have an in-house phone OS. The mobile Google+ app is among the least well-executed mobile apps among all of Google's products.

Amazon has shown it's possible to have a successful product entry with a mobile device, even with Android and iOS as competitors. Facebook has a large ecosystem, like Amazon. There is no reason to think Facebook's mobile market window is closing. On the other hand, if Facebook were to ship a "Kin"-like flop, that would set them back substantially.

If a Facebook mobile device is coming, Facebook has every incentive to wait until it is done right.

I am one of the people Steve Jobs said would continue to need a fully general-purpose computer, which he compared to people who need to drive a truck. I make software for a living, and Linux is a great platform for software development. The point Jobs was making is that it isn't appropriate to try to make personal computers as simple to use as mobile devices. And while ease of use has many virtues for both the mainstream consumer and the "truck driver," ultimately, the way products are designed will diverge.

Android is the consumer's Linux. Android took the step of discarding much of the Linux userland and starting afresh, with a software platform that is both powerful, and designed for finger-friendly mobile devices. That turned out to be a very successful approach. Trying to evolve a desktop OS to do what Android and iOS do is very difficult, and there are no successful examples. Microsoft has repeatedly tried to make Windows work on tablets, and failed repeatedly. It's an open question if Windows 8, even though it contains a finger-friendly UI system, can straddle the two worlds without creating situations where the user is dumped into finger-hostile territory at inopportune times.

While making desktop Linux more user-friendly remains a worthy goal, it may turn out that Windows 8 is a cautionary example: When the world is dividing into PCs for people who really need them, and mobile devices that are a radical step forward in ease of use, trying to be both at once could result in being neither fish nor fowl.

Subscription services for books like Safari Books Online http://my.safaribooksonline.com/9781449309473 already "loans" books with a model like this. They pay out from a pool based on the number of times a book is selected from their library. Of course a single use isn't going to pay out as much as a purchase, but the alternative is for a Safari-like subscription library to buy a single copy, or as many copies as would be used simultaneously, and do license management. And that opens the whole DRM can of worms.

An open-ended revenue model can be advantageous to authors of frequently-read books.

Java is much complained about, on the one hand by people who think it is too hard, and on the other hand by people who think it is not sufficiently expressive. But the evidence is you can build a world-beating OS with a Java userland. And evidently it isn't urgent to augment or replace Java, either with more expressive JVM languages like Scala, or supposedly simpler languages available for the JVM like the BASIC-like Jabaco, even though this could be done for Android since the translation to Dalvik bytecode is downstream of compiling into Java bytecode.

Java has great static code analysis tooling and great refactoring. There are books like Thinking in Java and Effective Java that will make you fluent in the idioms that make Java understandable, debuggable, and maintainable. For a programming beginner I'd suggest Learning Android and Head First Java. Android's documentation, tutorials, and examples are enormously improved since Android first came out.

Every language has screws, but a good case can be made that Java has fewer of them than many other languages.

Think about the phrase "personal computer."

How many people do you know who really need a completely general-purpose computer that they own and control personally?

How many "PCs" are actually nodes in a centrally controlled system, and not "personal" at all?

Because of the economics of making "PCs," we have the illusion that hundreds of millions of people buy and use "personal computers" each year. In reality, a minority, possibly a small minority, of those people actually take advantage of anything those "PCs" do that would require personal control over a general-purpose computer.

This is the reason mobile devices that are not quite "personal computers" are rightly popular. They serve the actual need. Hopefully, it will be possible to use mobile devices as if they were personal computers, so that the potential of personal computers can be applied to a networked, mobile world.

This is a great proposal. I would no longer make mistakes about a meeting in another time zone changing to local time for an in-person versus a phone meeting. However, it can be improved. Decimal time would make calculating percentages of time spent on various activities much easier. Combine the two for Flawless Victory.

Nobody has ever moved an operating system from mouse to touch. There is a first time for everything, but the two winning tablet OSs were designed for touch. I believe there is a reason: Turning a non-touch OS into a touch OS is harder than anyone doing it thinks it is.

Secondarily, I think this is what is holding back Web operating systems on touch devices. The Web wasn't designed for touch and Web operating systems "leak" bad user experience in from the non-touch Web. On Android and iOS touch devices, the Web browser is an ancillary UI and application environment, not the central part of the user experience.