Coyote Tracks

Geekwire has charmingly titled an article on Swype, the third-party software keyboard system for Android and other mobile OSes, “Exclusive: Fast-growing Swype scores cash from Ignition, hints at Apple iOS integration.” The “hint” in question?

[Swype CEO Mike] McSherry laughed when asked specificially about whether we might see Swype on Apple devices such as the iPad and iPhone (a question he’s accustomed to hearing from me). “We are having discussions with almost every OEM that you could imagine,” he said.

Author John Cook apparently didn’t pick up on the nuance here. Let me help translate that for you, John:

“God, I wish you’d stop asking me stupid-ass questions,” McSherry said. “Are you thick?”

The Federal Trade Commission:

Google Inc. has agreed to settle Federal Trade Commission charges that it used deceptive tactics and violated its own privacy promises to consumers when it launched its social network, Google Buzz, in 2010. The agency alleges the practices violate the FTC Act. The proposed settlement bars the company from future privacy misrepresentations, requires it to implement a comprehensive privacy program, and calls for regular, independent privacy audits for the next 20 years. This is the first time an FTC settlement order has required a company to implement a comprehensive privacy program to protect the privacy of consumers’ information. In addition, this is the first time the FTC has alleged violations of the substantive privacy requirements of the U.S.-EU Safe Harbor Framework, which provides a method for U.S. companies to transfer personal data lawfully from the European Union to the United States.

While it’s fun to make smug “don’t be evil” jokes (expect a lot of them), that’s missing the forest for the trees here. On balance, markets do an adequate job of being self-regulating when we’re talking about transactions between informed buyers and sellers. One of the best rationales for government regulation rests on the word informed: it’s always in the buyer’s best interest to be as informed as possible, but it’s not always in the seller’s interest to have well-informed buyers. A transaction where the seller can hide crucial information from the buyer is not an efficient transaction. In theory, at least, regulations which compel the seller to reveal information make the transaction more efficient. This is essentially what this case is about.

But here’s where it gets interesting. Even though Google’s users weren’t buyers in this case, they were still parties to a transaction. But when your user data is collected by Google or any other company and that data itself—in aggregate form or even individually-identifable form—becomes a product, you aren’t a party to the transaction. To the degree a market can be self-regulating, it’s through mechanisms which apply to the buyer and the seller. If you’re not either one, how are you protected? If there’s a way to do that without government regulation that’s better than “trust the companies to do the right thing,” I don’t see it. You may not trust the government, either—but you still have to address the problem.

Meanwhile, obligatory smug joke: “We’re amending our motto to ‘don’t be evil as Facebook,’ and we’re confident we can meet that for the foreseeable future.”

I’m increasingly irritated by the way Google uses the word open. When I think of open I think of Linux and FreeBSD, but that’s just one sense of open—the open source, or if you prefer, “free software” sense.

There are also open standards, like TCP/IP, ASCII and USB: published, openly available specs that aren’t controlled by a single company. Unlike free software, open standards aren’t necessarily royalty-free; the open refers to the lack of central control and the idea that anyone can license it as long as they meet the basic requirements—nobody can keep a competitive advantage over you by blocking you from using an open standard.

And there’s open platforms. I’ve seen other people call this “open experience”; basically, it means that the platform isn’t designed to limit you to approved uses and applications. It’s the difference between a laptop and a console. And the difference between an Android phone and an iPhone. Sort of.

Clearly Android has always been more open—in both source and platform senses—than iOS. Other than the bits that exist as part of Apple’s open source projects, you can’t get iOS source code at all. As an individual consumer you can’t load software onto an iOS device other than through the App Store. It’s impossible to replace or even hook into iOS system components without “jailbreaking” the device.

But Android isn’t Linux Open. It’s Google Open. Let me explain.

We all really know that for the vast majority of computer users, the important part of “free software” is the “free as in beer” part, because they can’t use the source code. Whether they’re using Microsoft Word or OpenOffice, they rely on the development team to fix bugs and add new features. In theory every Android user has the freedom to rewrite their mobile phone’s operating system. Well, in theory every car owner has the freedom to forge his own piston block, but in practice, not so much.

Even so, with desktop Linux—or a mobile Linux derivative like MeeGo—if you really want to forge your own piston block, you can. Dell and HP and Nokia aren’t going to go out of their way to make it difficult for you. But Android isn’t Linux Open. It’s Google Open. Android’s openness is primarily aimed at the manufacturers and carriers. Unless you have a Nexus phone, you aren’t getting stock Android. You’re getting a customized build, and more often than not it’s a customized build that’s locked down to some degree. Android uses the Apache License, under which it’s perfectly permissible to make closed-source proprietary enhancements and derivatives.

So far, the response from Android fans has been, more or less, so what? Fair enough but let’s be honest. “Rooting” sounds much friendlier and more—hmm—open than “jailbreaking,” but it’s essentially the same thing. If you’re rooting your Android phone, you are doing so because you want to do something that your phone manufacturer has deliberately tried to make difficult. You’re running an external program that hacks it, just like an iPhone jailbreak. And you’re voiding your warranty, just like an iPhone jailbreak.

While this may not be an elephant in the room, it’s at least a hippo, isn’t it? Why do you need to run an unofficial hack to do this in the first place? Why isn’t there an “enable root user” download on an official Google web site?* I’m not asking this facetiously. If you want to put your own custom build of MeeGo on a compatible device, it’s very easy to do it, and at no point are you required to trust your device’s security to someone who spells his name with zeros. If the first step of taking advantage of your phone’s “openness” is “run this unofficial hack to open it up,” then we might as well slap the iPhone’s butt and call it open, too.

But wait, that’s not fair! A jailbroken iPhone still doesn’t have the source for the operating system! You still can’t forge your own engine block! Mmm hmm. You know where this is going, of course—right to Google’s announcement that they’re not going to open the doors to the Honeycomb Hideout yet, and the source code for Android 3.0 will remain theirs for the time being. Because if they released it, people would try to put it on phones, and the experience would be bad. They don’t want people to have bad experiences.

This is a perfectly defensible rationale—but it’s way out of whack with what open source normally means. I follow a few open source projects, including Django and Ubuntu Linux. They don’t want people to have bad experiences, either. That’s why these projects have what we on our planet call “official releases” and a “development trunk.” And again, look at MeeGo: not just stable “official” releases but daily binary builds available, along with the source code repository.

While I’m seeing some discontent in the Android Army’s ranks, I’m seeing more than a few partisans rise to the defense: Yes, they say, it’s great that Google is going to keep the source private for a while. Look, that doesn’t mean it’s not open. Okay. Going by the letter of the license, you win: it’s open! Sure, you’ll either have to hope your manufacturer eventually releases an official update for your “old” hardware—just the way us closed phone users do things—or you’ll have to wait for Google to release the source and a hacker to package it up in an unofficial build that will hopefully work on the phone you rooted to get around the manufacturer’s lockdown. But otherwise, really open!

So, y’know, just one more question. Do the umbrellas the true believers keep putting up when this stuff keeps being rained on them actually open, or do they only Google open?

(* Update, 3/29: I am told in comments that the Nexus phones do have an official root-unlock tool, and that interestingly, Sony Ericsson—remember them?—will have an official way to do this as well. This only fractionally alleviates my grump, but it’s good information.)

Like a lot of blogging nerds I’m a huge fan of John Gruber’s Markdown. If you’re reading this you’re likely familiar with it, but if you’re not, it’s basically a way to write content for the web as plain text, including links and basic formatting like these italics, and have it converted to nice (X)HTML. The last paragraph looked like this in its original Markdown:

Like a lot of blogging nerds I'm a huge fan of John Gruber's
[Markdown][md]. If you're reading this you're likely familiar with it, but
if you're not, it's basically a way to write content for the web as plain
text, including links and _basic formatting like these italics,_ and have
it converted to nice (X)HTML. The last paragraph looked like this in its
original Markdown:

[md]: http://daringfireball.net/projects/markdown/

Some blogging services—like Tumblr—support Markdown directly, and there are some editors like TextMate which come bundled with Gruber’s Markdown script. Once you get used to Markdown, though, you find yourself wanting to use it everywhere. That’s where OS X’s Automator actions come in. I’ve set up services for three different things: Markdown to HTML, HTML back to Markdown, and copying Markdown to the clipboard as formatted text.

(If you are not an OS X user, or you are not interested in this level of nerdity, I will not be offended if you stop reading now.)

To do this, you’re going to need to get three Unix scripts:

• Markdown
• SmartyPants
• Aaron Swartz’s html2text

You’ll want to save Gruber’s scripts somewhere on your local file system; I have them in /usr/local/bin (the canonical “Unix stuff I’ve added to my system” directory). You can save Swartz’s script there, too, although I actually have it saved as part of the service.

In Automator, create a new service. At the top of the service’s action list, set “Service receives selected text in any application” and check the box for “Replaces selected text.”

The service has only one action: “Run Shell Script”. You can leave the default shell selected (for me that’s /bin/zsh but for you it may be /bin/bash or /bin/sh), and set “Pass input:” to “to stdin.”

In the box for the shell script, type:

/usr/local/bin/markdown | /usr/local/bin/smartypants

Save this as Markdown to HTML. This should look something like this when you’re finished:

Now create a new service and follow exactly the same steps as above, but uncheck “Replaces selected text” and in the box for the shell script type

/usr/local/bin/markdown | /usr/local/bin/smartypants |
/usr/bin/textutil -stdin -stdout -convert rtf -format html |
/usr/bin/pbcopy

(That’s all one big command, so don’t type it with line breaks.)

Save that as Copy Markdown as RTF.

Now, create one more service, and follow the same instructions as the first one, but this time, select /usr/bin/python as the shell in the Run Shell Script service. “Replaces selected text” should be checked again for this one). This time, paste the whole html2text.py script right into the box for the shell script. Save that as (yes) HTML to Markdown.

To use these services, select the text you want to convert and then select the appropriate command from the Services menu. The Markdown to HTML and HTML to Markdown services replace the selected text. The Copy Markdown as RTF service converts the text and then puts it on the clipboard, so you can then go to your favorite word processor (or whatever) and paste the formatted text in.

Horace Dediu writes:

Many observers may say that both print and music businesses were “foolish” and that they ignored the new medium of web. That somehow management dithered and missed the new wave blaming failure on incompetence. Putting aside the fact that all industry participants seem to have conspired to be foolish at the same time, this is not supported by the data.

While it isn’t Dediu’s specific point, this touches something I’ve been musing on for a while: we, the Internet-using public, have been exceptionally good at rationalizing why we avoid paying publishers, creators and/or distributors of digital content. It’s so common for people to talk about The Music Industry™ as one big monolithic unit that Just Doesn’t Get It™ that if you suggest otherwise, it’s assumed that you’re either a paid shill or a Martian.

But take a look at what The Music Industry™ has actually done in the digital era. 15 years ago if you wanted a new album you would walk into your local music store and probably pay about $12.99 for the CD (the equivalent of about $18 today). You wouldn’t be able to get individual tracks for less (unless they were singles, sold at ridiculously inflated prices), and of course you’d have to hope the store had the CD you wanted in stock.

Now, you’d go to the Amazon MP3 store or iTunes and buy the album for $12.99, or maybe $10.99, or maybe even $8.99. Most of the tracks would be available for $1.29 or 99¢ if those are all you wanted. And while the selection isn’t quite “everything in print,” it’s vastly improved over any brick-and-mortar store. And, lest we forget, both of those stores sell DRM-free tracks. Digital music is now unprotected, unbundled, widely available, and cheaper than it ever has been. So why aren’t we paying for it? Those inclined to quip that music just isn’t worth paying for these days are duly informed that they, in fact, sound like their parents.

Dediu argues that the reason these old models aren’t working is because “what we have here is a disruption”; he goes on to say, “consumption of news and music is increasing that the way that it is valued is changing.” Clearly—but changing to what?

(Preface: at my last job, I took over lead development on a web application based on the PHP framework Symfony, so I have a fair amount of experience with the project.)

Oh, hey! They’ve just redesigned the Symfony web site and introduced a new “standard distribution” for version 2. I’ll give this a run through and download it. The place I’m doing consulting work with has a homebrew PHP application that I think needs to be moved to an industrial-strength framework, and while Symfony was somewhat a little unduly verbose, it seemed solid.

Okay, the “Quick Tour” that the “Get Started” page takes you to gives you a broken link to download. Guess it’s for an older version of Symfony 2. Okay then. I’ll just go to “Download.” Hmm. The fine print says:

If you have Git installed on your machine, download the version without the vendors.

Okay, check. I have git so I’m good. The README file in the archive I’ve downloaded begins:

If you have downloaded an archive without the vendors, run the bin/vendors.sh script.

Okay, ch… uh, there’s no bin directory. A quick search of the entire archive shows no script called “vendors.sh” anywhere.

All right, let’s get the one with the vendors after all. I hope one of the vendors has liquor.

A web-based configuration system now. A little superfluous, but cool. I’ll ignore the useless “Quick Tour” and go to the new documentation on “Creating Pages in Symfony 2.” This seems right, looking at this callout:

The tutorial assumes that you’ve already downloaded Symfony2 and configured your webserver. The above URL assumes that localhost points to the web directory of your new Symfony2 project. For detailed information on this process, see the Installing Symfony2.

If you’ve downloaded the Symfony Standard Edition, delete the src/Acme/DemoBundle directory, as you’ll recreate it in this chapter.

Okay, deleted. (Actually renamed and moved elsewhere.) Onward!

Before you begin, you’ll need to create a bundle. […] To create a bundle called AcmeDemoBundle run the following command:

php app/console init:bundle "Acme\DemoBundle" src

Whoops:

PHP Fatal error: Class 'Acme\DemoBundle\AcmeDemoBundle' not found in /Users/watts/src/Symfony/app/AppKernel.php on line 23

Hmm. Well, next in the documentation it tells me I have to add the Acme namespace to app/autoload.php and the bundle by adding it to the registerBundles method in app/AppKernel.php. Okay. I guess I have to delete those, too. This gets me to:

PHP Fatal error: Uncaught exception 'InvalidArgumentException' with message 'Bundle "AcmeDemoBundle" does not exist or it is not enabled.' in /Users/watts/src/Symfony/vendor/symfony/src/Symfony/Bundle/ DoctrineAbstractBundle/DependencyInjection/AbstractDoctrineExtension.php:95'

So I’m pretty sure at this point the documentation says:

You know, you like Python, and you’ve been wanting to play more with Flask. Wouldn’t this be an excellent time to start?

Yes. Yes, Symfony 2 documentation, it would!

Symfony’s defenders/developers may rush in to point out that they just pushed out a major redesign of the web site. I get that. Bugs are a fact of life. The problem is that this is brand new documentation for the brand new distribution, and from all appearances nobody has actually tested the directions they’re giving new users. As it turns out, I had to comment lines out in five files to delete this. This could be solved by just telling new users to build a bundle with a different name—and that could have been caught with a fairly small bit of effort. (I question the wisdom of putting a demo app in the “standard distribution” to start with, but never mind.)

While Symfony is the system I’m picking on for demonstration purposes, they’re not unique. Try to find a good tutorial for server-side Javascript darling node.js out there—I’m giving up on it until the O’Reilly book comes out. And back when I was working with CakePHP it was just assumed you read the framework’s source code to figure out how to do stuff.

It’s hard not to notice that these are all open source projects, and I doubt that’s just happenstance. A common stereotype of developers is that they hate writing documentation, and judging by the quality of documentation that many developers write it’s clear this stereotype holds a lot of truth.

Meanwhile, I’m going to go back to working with the undocumented PHP code I’m currently in charge of.

(Will I go back to look at Symfony 2? Probably. While it looks like it’s taking over-engineering to new heights, it’s doing some interesting stuff. I’d still like to get out of working with PHP as much as I do, but that’s a rant for another day.)

Paul Hontz wrote an article whose point is summed up in its title: “If iPads are “post-PC devices” why must I sync with iTunes before I can use one?

Ben Brooks takes some exception to Hontz’s argument:

If you walk into an Apple Store and buy an iPad you can have them do the initial sync to get your iPad up and going, thus you never have to have synced the iPad with your iTunes. All of this depends on what your definition of “post-PC device” really is. I would define a post-PC device as a device that moves the user beyond the computer—a device that could/does replace a computer for the general consumer.

My definition of “post-PC” is “marketing buzzword.”

I agree with Brooks that Hontz’s title is “link-baity,” but I think Hontz brings up an important point that’s often lost in the rhapsodic talk about our glorious tablet-based future. And while we tend to treat “iPad” and “tablet” as synonymous because for practical purposes the iPad is the tablet market right now, this is a problem that may be specific to the iPad. Yes, it’s possible to do what Brooks describes above—just sync it once at the store. But the user who doesn’t have an iTunes-runnin’ PC or Mac at home has no way to back up, no (easy) way to get their own media into the built-in media players, and perhaps most significantly, no way to upgrade the system software.

There are certain tasks the iPad is very good at. But for right now, the iPad has a practical dependency on iTunes, and that means that it has a practical dependency on being in a household with a Mac or a PC that it syncs to. It may be able to replace a second computer, but it can’t be your only computer. Yes, there are heartwarming tales of 85-year-old grandmas using iPads, but I can all but guarantee grandma’s iPad is being plugged into the grandkid’s computer every once in a while for an update.

Will this change? Of course. Unlike a lot of old-school Apple nerds, I am not quaking in fear over the notion that OS X is going to become “dumbed down” to be more like iOS. I expect the exact opposite: iOS will get more powerful and more capable with each iteration. When it becomes possible for the most studliest of power users to do their work with an iPad or other tablet of their choice, it won’t be because you can no longer run Microsoft Office and Photoshop on your desktop. It’ll be because you can run them or full-featured equivalents on the tablet.

And when you can run them better on the tablet—no compromises—then “post-PC” won’t be a marketing buzzword anymore.

It’s not a very dramatic upgrade, but it’s a pretty solid upgrade. It crosses off or at least blunts most of the features that competing devices have been counting on in the Bullet Point Wars: dual core CPU, much faster GPU, cameras, (optional) HDMI out.Other tablet and smartphone makers—and the extremely vocal set of Android fans¹—are still under the impression that Bullet Point Wars matter, even though there’s a decade of history with iThings that conclusively demonstrates they don’t. The Zune beats the iPod on bullet points and has some genuinely cool features that Apple spurns; MacBreak Weekly co-host Alex Lindsay has stated multiple times he prefers the Zune because of its subscription service. I have absolutely no doubt the other three dozen Zune owners worldwide love theirs, too.

It’s wryly amusing that the best ad I’ve seen for the Samsung Galaxy Tab is created by a user and is pretty consciously styled after Apple’s TV ads. Yesterday, though, Apple raised the bar by showing the iPad being used not only by Salesforce nerds everywhere but by educators, attending physicians and kids with autism. All of these things are clearly possible with competing products—there’s nothing magical about the iPad in that regard—but right now nobody besides Apple is there. Just showing up gives Apple a tremendous advantage.

The bottom line is simple—competitors have to explain why their product is better. “Because it has a micro-USB port” isn’t good enough for most people. (It’s my suspicion that people strongly underestimate how much the third-party ecosystem around those dock connectors sells iThings.) And “Because it’s based on an open source platform” is a winning point for even fewer. To convince people that Apple’s “walled garden” app approach is bad, you need to show compelling applications that don’t—or better yet, couldn’t—exist under it. This turns out to be pretty tough. Apps that could never officially exist on iOS tend sharply toward the nerd-centric. There are certainly customers for whom iOS’s inability to background an SSH connection for more than 10 minutes would be a deal-breaker, but that’s a relatively small group. (And those who are nerdy enough to need that are probably nerdy enough to set up the SSH client to automatically execute screen when it connects, anyway; if you don’t know what that means, you probably don’t want an SSH client.)

This isn’t to say that competitors can’t and won’t do pretty well. Android’s open licensing allows a lot of devices that are all nominally compatible with one another to be made, and dozens of manufacturers will sooner or later collectively hold a greater share of the market than just one manufacturer—by most accounts this has already happened in the smartphone world. But right now, the Android devices that are most competitive feature-wise with iThings are in the same price range for phones and higher-priced for tablets. The stuff that’s cheaper is just not in the same category. There are some off-topic comments on that linked article at androidguys.com above with people trying to debug a $180 “Herotab MID816” which are sadly hilarious. While I expect “$29.99 with contract” Android phones to be on the market by the end of this year and those phones to vastly increase Android’s market share, those phones will be directly targeting $29.99 feature phones, not $199.99 smart phones.

I’m not the first person to observe this, but it’s worth stating again and pausing it to let it sink in: currently, nobody in the tablet space is truly competitive with Apple on price.

Competitive with Apple.

On price.

1. It took Apple at least a decade to pump its flock up to the level of raving zealotry Android achieved in about two years. Behold, the power of open source!