The App Store: I Get It, but...hmmmmm...

Apple's "post-PC," "new media" iDevices are selling quite nicely, thank you. Millions of people have become enthusiastic, loyal, even evangelistic customers without ever clicking a mouse on an Apple desktop or laptop computer. Given that Apple's profit from a laptop or desktop computer is several times what it is for an iDevice, it's almost imperative for them to find ways to make the Mac desktop/laptop user experience support the traits that have been most successful on iDevices. This includes, especially, the App Store.

Fans of the App Store, either on the iDevices or the Mac, point to the fact that you can have several different devices (iPad/iPhone, iMac/MacBook) using the same Apple ID, and thus can install "content" that you "purchase" on several devices; all you need to do is register them under the same ID.

But the Mac, historically, has had a rather different model. You would (and still can, fortunately; at least for now) either purchase a disk with software on it, or download a "disk image;" a file which appeared to Mac OS to be a disk. As soon as you did that, a window would open with the program icon in it and an icon for your Applications folder, and you'd drag the icon over onto the folder. The software would be copied to your hard disk, and you'd be able to then run it like any other program. Want to uninstall the program? Drag its icon to the trash.

Another benefit of that latter model is that you have actual media — either physical or virtual — which you can use to reinstall the program on your computer or, license permitting, on other computers you personally or corporately own. You're very aware during the "normal" installation process that you're working with some sort of artefact which contains the program you're installing. That artefact either is or tries reasonably successful to simulate a physical object.

We've built up certain expectations about physical objects. They exist; though they can be destroyed, they don't generally disappear without direct action by you or another person. With very few exceptions, they can be used more than once. These and other expected traits give the object some value — economic, sentimental or otherwise.

The App Store for the Mac does away with the artefact; it replaces it with an abstraction that's not "real" in any sense you can point to afterwards. To a degree that some find disturbing, it turns the product with which you previously dealt into a service. That service can become unavailable for any number of reasons, not all of which are necessarily a result of your actions or intent.

Put another way, it turns the old "software as a product" notion, and in particular the notion of free software, on their heads. Most free software licenses (try to) make clear that the user is In Charge of his or her own system, including use of the software being licensed. The copyright holder retains certain rights, but yields the remainder to the user under conditions designed to make sure that the software remains "free" in the sense that it was originally licensed. The user may examine the software, redistribute it as he got it, (under most FSF-approved licenses) can create modified or derivative works so long as they are licensed compatibly to the original, and so on. Above all else, the user has the unquestioned right to make as many backup copies of the software as desired in case the original installation becomes unavailable (hard disk crash, extreme weather event, etc.) The user has rights, and has the means to safeguard those rights by virtue of the fact that he has a physical copy of the software in its original, usable form.

The App Store says "Mr User, you don't have to worry your pretty little head with any of that. You just point-and-click your way through the store, and when you check out, the software will be installed automatically on your system." That's great — so far as it goes. But there's no option, at least none that I have yet found, to retain a copy of the disk-image file(s) for the software you just licensed. If your drive goes south for the winter and doesn't come back, you "just" replace the drive, reinstall Mac OS X and install all your apps from the App Store.

That's fine for small programs, especially if you have a high-speed Internet connection using a properly managed ISP. But, unlike the App Store for iDevices, several programs licensed through the App Store for the Mac are in the hundreds-of-megabytes-to-gigabytes range. Try downloading Xcode 4 on a 128K ISDN line. And iLife. And iWork. And... you see the problem. Wouldn't it be much better if you at least had the option to manage all that locally, yourself, the way it's traditionally been for the Mac? And that doesn't even take into account Apple's well-documented "control-freakery," where software available one day — or even already installed on your system — may not be available the next. Even if we give Apple the benefit of all doubt, ascribing to them motives as pure as the driven snow, there's still a real problem here.

The iTunes Music Store has now moved away from "protected" DRM-encumbered music, because customers made it clear that they wouldn't stand for the inconvenience and loss of control over product that they had paid for. I can back up my iTunes library however I wish, and be reasonably confident that should anything happen to my Mac, I'll be able to restore the library on my new replacement Mac without downloading it all again from the ITMS.

Why can't I have that same confidence with the software products I license through the App Store? Apple aren't the only ones who think they should have a fair amount of control over "their" "stuff."

Comments?

A Blessing is ALWAYS A Curse (and Vice Versa)

I've recently started as Senior Architect at Savant Degrees, a Singapore-based Web consultancy. Quite often, I feel like my job is as much "Senior Curmudgeon" as anything. According to Wiktionary.org, a curmudgeon is "[a]n ill-tempered (and frequently old) person full of stubborn ideas or opinions." I'm undoubtedly the oldest person among any of my colleagues that I've met, and I was told fairly explicitly that I was being hired on the basis of the variety and depth of my experience — i.e., for my ideas and opinions. And, like most people, I think I'm only stubborn when I'm right.

Naturally enough, I'm doing a lot of learning, too. This is my first experience with Groovy, a nicely dynamic language which runs atop the Java VM. Like any language worth its weight, a rich ecosystem is growing around it. Like the ecosystems around most languages, there is at least one ultra-massive tool that takes new folk some time to wrap their minds around. With PHP, for instance, it's the Zend Framework, which arguably makes the C++ Standard Library look minimalistic. With Java, it's pretty much anything having to do with J2EE1 (to which Groovy itself is a reaction).

The biggest tool I've yet stubbed my toe on in the Groovy world is, unquestionably, Gradle2. In the grand Zend tradition, the PDF version of the user guide is nearly 300 pages long and, also like Zend, is considerably out-of-date. It's considerably easier to argue that Gradle justifies the bulk, however, since Gradle is a "let's build anything" build manager/dependency tracker/dessert topping/floor wax. The basics can be understood in half a day, even if you've only nodding familiarity with Groovy3. To truly master it, however, requires significant extra time — as much as you feel you derive benefit from.

And that (finally) brings me to the point of this post. The group I'm working with now has some very talented and moderately experienced developers in it; they're open to new ideas and new ways of doing things, more than is the local cultural norm. In our craft, that's not just a Good Thing™; it's necessary for continuing success4. But that enthusiasm is tempered by a keen consciousness of impending deadlines, particularly the "curse of success;" a month, later this year, when we will be spread extremely thin amongst several important projects. The ways we've done things have been successful, but we see the down-sides of success as well.

So, new ways of doing things, and the hope of new, increasing success. New things like continuous integration using automated builds and unit tests, among other such recently-popular tools and techniques. (They're popular because they generally work better than Ye Olde Ways.) I'm arguing for the team to use tools that will, at the click of a button or the tick of the clock, automatically check out, build, test and package the code and associated resources for our project. The team is new to this, having used "traditional" "waterfall" processes in the past. Knowing one is to be hanged, as Mark Twain said, tends to focus the mind wonderfully; a rational person (or team) will avoid being put in that position. My job, so to speak, is to make the tools that help us cut the hangman's rope, and teach their use. Presenting already-busy people with several hundred pages of documentation is probably not the most effective way to do that.

So, at the moment, the most pressing blessing is that we have such wonderful tools available, with more on the way. Most categories of tools have several at-least-usable alternatives available; it's very easy to go into information overload. When that happens, often you just choose to use what some exemplar, say a tool vendor, use themselves. It becomes tragically ironic when a development group pursuing a more agile process has their agility and effectiveness limited by their "agile" tools. (I don't mean to be commenting on any specific company or team here; I've seen this effect on numerous projects over the years.)

Choosing deliberately increases the odds that you will choose wisely, and those odds will increase along with your experience. Experience is perhaps the ultimate professional blessing-and-curse-combined; "you never learn anything from doing it right the first time." I prefer the Nietzsche:

That which does not kill you, makes you stronger.

We're not dead yet — so we must be strong, yes? Another "stubborn idea and opinion."

Comments?

Footnotes:

1. Now known as JEE, because "Java 2" (1.2) is so last decade; we're on 1.6 now. (Return)

2. No, I haven't looked at Grails yet. Being a close of Ruby on Rails, I expect that to be the proverbial "kitchen sink with subdivisions attached." Fortunately (?), we're a Tomcat shop. (Return)

3. But, of course, experience counts; Gradle rewards your groovy Groovy skills with more efficiently expressive power in your project automation. (Return)

4. There's another curmudgeonly opinion for you. (Return)