⇥ A little bit of Apple, a little bit of Adobe

There seems to be a distinct lack of perspective in the whole Apple vs. Adobe war—perhaps it was inevitable that something like the by now infamous Clause 3.3.1 of the iPhone OS SDK agreement would polarize people so much.

First of all, because I suspect that my readers will make a big deal out of it, I stand by my previous post on the whole Apple thing. Feel free to disagree, but even the introduction of the new clause, which limits “sanctioned” iPhone OS apps to those that are written in a handful of official Apple languages, doesn’t limit your ability to tinker with the OS. It does, of course, limit your ability to deploy, which, depending on what your ultimate goals are, may be a significant problem—but it doesn’t prevent you from writing apps for the platform, including those you develop using one of the “forbidden” tools.

A little bit of Apple

Some of the arguments that the Apple camp uses to justify the existence of the new clause seem a little specious to me. Gruber’s analysis on why the clause exists¹ is probably spot on, but his conclusions are a little disingenuous. Section 3.3.1 was clearly introduced to developer lock-in and protect Apple’s significant profit margins on the sale of iPhone OS devices—after all, cross-platform development tools like Flash or Titanium are about levelling the field by deploying across multiple devices with a single codebase; if apps look and behave the same way on multiple platforms, the argument in favour of spending your money on Apple devices loses much of its value.

What I haven’t seen mentioned is that §3.3.1 also ensures hardware lock-in, because now there truly is no way to develop software for iPhone OS unless you’re on a Mac. This was true before, as well, but only to a certain extent. Prior to the new agreement being introduced, if you chose a cross-platform development tool, you could conceivably run a team on Windows or Linux and then buy a single Mac—even an entry-level Mini would have done—for building, testing and deployment. Your only choice is now to be an all-Mac shop.

The leap that Gruber—and Jean-Louis Gassé, in a piece that just came out this morning—make from realizing the §3.3.1 is about lock-in to claiming that cross-developed applications are inferior, either in terms of performance or quality, is laughable. There are plenty of hideous apps in the App Store—most of which have been built with the native tools. Tools don’t make developers—they are just tools. Twenty years of experience in the IT industry tell me that poor programming skills will show no matter what platform software is written on.

Besides, if ensuring quality were really Apple’s ultimate goal, they have all the tools—legal and otherwise—to do so today, without the need for any new clauses. They could, for example, start enforcing their own human interface guideline policies; there are plenty of apps that blatantly violate them² in the store even though they have been built using sanctioned tools. Ditto for performance—Apple’s own mail client struggles, at times, when selecting multiple messages even on the iPad, which is probably the fastest of all iPhone OS devices. If these are the things that matter to Apple, §3.3.1 is not the answer to them.

As for the topic of this being Adobe’s comeuppance for snubbing the Mac when that platform was struggling, I have no comment to offer—mostly because I wasn’t either a Mac or Adobe user at that particular point in time. But it seems to me that Steve Jobs has shown himself to be a much-too-focused executive in the last ten years to embark on personal vendettas. Even his spate with Michael Eisner over Pixar was, in my opinion, much more about shrewd negotiations than personal antipathy³. Alas, the vengeance, if it exists, is only in Steve’s brain—a place I respectfully want to stay out of.

A little bit of Adobe

The bitterness on the Adobe side of things is a little disproportionate to the events, I think.

Claiming that Apple is out to damage the launch of CS5 is just plain silly. Sure, the iPhone OS 4 event might have been a little suspiciously timed, but Flash’s ability to cross-compile to iPhone OS is a relatively minor feature of CS5. As a developer, Flash does little for me—it’s a designer’s tool. My interest lies more with tools like Flash Builder or AIR2, which make a heck of a lot more sense to me than Flash itself. As far as CS5 goes, I’m much more fascinated (and not a little freaked out) by Photoshop’s new content-aware fill than what Flash does.

What’s more, I wouldn’t rule out Flash as an iPhone OS development platform altogether. True, you can’t sell the software you write with it on the App Store, but that ignores a huge segment of the market for which Flex and Flash are ideal platforms: internal-use applications. I have, in the past, mentioned that I believe this to be AIR’s best market: scenarios in which an IT department needs to deploy tools to a heterogeneous, but captive, environment. If I were building a management console for a company of any size, I would not hesitate to recommend that they use Flex and AIR for it, even for iPhone OS deployment. Bypassing the App Store in these cases is not just easy—Apple gives you all the sanctioned tools you need—but also desired, and the ability to build a single codebase could signify major savings for any company without necessarily compromising the unique per-device experience⁴.

By the same token, stating that Adobe should simply stop making products for Apple platforms is just plain stupid. Never mind that Mac users are likely a large source of revenue for the company—screwing customers over hardly seems to be the way to solve this issue. You’d think the whole Kindle-vs.-iBooks spate would have taught these people something.

Kevin Lynch, Adobe’s CTO, has offered a fairly measured response to the §3.3.1 issue—but I must admit that I, for one, was disappointed that he should be the company’s spokesperson on what seems to me like a business, rather than a technical, issue. He should have focused on the technology aspects of CS5 and leave the CEO to address Apple’s perceived shenanigans.

Some of the responses from the company’s evangelists were regrettable, but, in my opinion, understandable. It must be difficult to be so focused on a product launch only to see your thunder seemingly taken away by a company that has no immediate reason to. Still, I prefer Ryan Stewart’s approach of looking at this as what it is—an opportunity to improve the Flash tooling.

By way of disclosure, Adobe is a client of Blue Parabola. I also write iPhone OS software. Take your pick of biases.

¹ I am probably overreacting, but I can’t help thinking that Gruber’s analysis is a little too spot on. I absolutely don’t want to accuse him of anything, but the fact that he was able to hone in on that one clause of the agreement as the 4.0 beta had barely become available raises substantial questions.

² I don’t mean here that all apps need to look exactly the same, but that they should offer a consistent interface across the entire platform. Human interface guidelines are about user experience—not colour and pictures. They are what gives “good” OS X applications that distinctive “Mac” feel.

³ Say what you will about Eisner, but he was exactly the kind of person that Disney needed at a point in time when its management spent most of its day attempting to wonder what Walt would do. He was brash and abrasive—and managed to bring order to what had become a chaotic company. And, when he was finally done with what must have been one of history’s best turnarounds, he was shredded to pieces by the Disneys with little regard for his accomplishment. Luckily, he’s been replaced by Bob Iger, who seems to be just as capable without grating people the wrong way.

⁴ Of course, nothing prevents stupidity from making people write a single app that looks bad on all platforms—but that has, again, nothing to do with the tools and everything to do with incompetence.

⇥ Why iPhone OS is not as closed as you think

I come back from the dead just so that I can write a few thoughts about this post by Cory Doctorow, which has culminated a week of words from people who seem to be stuck in 1980 and not willing to move—but all too willing to nag the rest of us about it.

Let me, first of all, say that this is not about DRM. I hate DRM, and I have made damn sure that it’s out of every product that we sell. I don’t want you copying my work, but I have no illusions that DRM is going to prevent you from doing that. DRM is absolutely, completely, positively useless.

What this is about is the concept of openness. Be warned—this is a long post, but, I hope, worth it.

I will take mine with a bonnet, please

Fifty, or even thirty years ago, you had every opportunity to open up your car and change it to your heart’s desire. In fact, you had to, in a way—the cars were so unreliable that a basic knowledge of automotive mechanics was as commonplace as today’s ability to type an SMS message at the speed of light. Tinkering was natural and expected—which is why you’d get a fairly detailed set of schematics with each car. For example, I remember my dad’s Fiat 127′s manual as coming with a complete electrical diagram and a cutaway drawing of the gearbox.

The fact that you could tinker with an automobile, however, has not created a generation of mechanics or mechanical engineers. Instead, the car has evolved, and today’s vehicles come with manuals that spend a considerable amount of time explaining how to tune your radio rather than how to change your oil. Engine blocks are now more likely to be exactly what their name implies: compact, all-in-one blocks with no user-serviceable parts.

That fact is pretty indisputable. But the question is: does that mean that today’s cars are less open?

By the standards of 1950, the answer is absolutely yes. But, and follow me closely now, because this seems to be something that the Apple bashers don’t quite seem to get: we don’t live in 1950.

If we could magically transport a person who lived at the height of the Cold War across time and present them with one of today’s cars, they’d probably complain endlessly about how they wouldn’t even be able to change their own oil.

On the other hand, interest in automotive “tinkering” is alive and well. Even as cars have moved on to electronic engine management, there are plenty of people who are interested in playing with their insides to their heart’s content. Perhaps the most obvious example of this are Adam Savage and Jamie Hyneman, the hosts of Mythbusters: one has a high school diploma, and the other a degree in Russian literature, and they yet they are the ultimate tinkerers in everything mechanical and electronic.

Meanwhile, the rest of us can go from point A to point B knowing that the likelihood of the car breaking down on us is minimal—and that, if it does, someone who is reasonably qualified will be able to help us. We are, in other words, users and we can use a car even if we have absolutely no intention of learning how it works.

This is called progress.

The atomic chip

It’s easy enough to see a parallel between the car and the computer, so I don’t see much value into going into it from a general perspective.

I do, however, want to ask you to consider this: where does openness end?

Consider the Apple ][, which was the computer to which every other computer today owes its existence. Doctorow hails it as the ultimate open computer, since it came with schematics and all sorts of documentation.

But, now, how open is the platform really? Could you change the CPU and replace it, say, with a motherboard? Could you disassemble the CPU and make your own?

Of course not—the CPU was nothing more than a thin sliver of silicon embedded in a much bigger block of plastic. You would have been no more likely to “tinker” your own CPU into existence than Woz could.

The reason for this was not a giant conspiracy aimed at preventing us from learning electronic engineering—it was a simple matter of progress. Without the CPU, we'd still be stuck in the days of computers that filled rooms and required small power generation stations to run.

In the name of progress, we have instead foregone some of the tinkering freedom in exchange for more accessibility. People who are interested in microprocessor design still have plenty of options, many of which are relatively inexpensive and entirely open to all forms of experimentation.

Perhaps Doctorow refers to the fact that, with manual and schematics in hand, you could easily create new peripherals and extend the power of your computer. That is, of course, true—except that it's actually easier to do so today than it was twenty years ago, because almost every computer today uses a completely standardized set of interfaces for communicating to the outside (it's called USB, in case you're wondering). PCs have it, Macs have it, and so do all iPhone OS devices.

Nor is your ability to mess around with the ports hindered in any significant way: recent versions of iPhone OS, for example, support USB connectivity (with some significant exceptions—read below).

So, exactly, where is the lack of openness? Should we go back to 1980 and type all our programs from a magazine so that we can feel part of a special club? Should I pull out the 80-column extension card from my Apple ][ so that I can, um, not use it in another computer?

Doctorow says that even a battery requires specialized knowledge to change. I fail to see how that's a relevant point—you can open your iPod or your iPhone and replace the battery with tools that you can buy at any hardware store (I've done it). Of course, your average person will have neither the know-how nor the patience to do it, and Apple is banking on the fact that they will take it in for additional revenue. That, however, doesn't mean that we will run out of programmers, or hardware specialists. You can change your car's oil with nothing more than a wrench—which, of course, most people do not own because they take their car in to the shop.

It's the passion, stupid!

What makes a device “open” is not the number of screws on its back or the quantity of parts you can change by yourself. It's its accessibility. And what makes a person a tinkerer is not a screwdriver or a schematic in a manual, it's passion.

The people who decry the bygone era of the Apple ][ seem to have forgotten how much that machine cost. I haven't, and I am all to aware of the fact that I owe my entire career—all twenty years of it—to the fact that my father, by far one of the smartest men I know and a master tinkerer in his own right—found a broken Apple ][ in the street, took it home and, bless him, managed to make it work. Had he not been so good (and so lucky), I would probably be doing something else today because there was no way my family could afford to buy a computer that had a base cost of $4,500 in 1980.

By contrast, tomorrow I will buy an iPad—a device far more capable than an Apple ][—for $500 in today’s money. Forget the iPad—I can buy a laptop for the same amount, and have at my disposal all the tools I need to create as much software as I want. But let’s be clear that this is made possible by the very same process that Doctorow claim are destroying our ability to tinker: computers get cheaper because they are less “open.”

The same concept goes for the fact that one needs to pay $100 in order to write applications for the iPhone. First of all, that’s not true: you can get the entire Apple developer stack for free—including an iPhone emulator that will allow you to run your programs without even having one of their devices. Second, $100 is nothing. Nothing. It’s less than most people spend in meals every week. It’s less than you spend in coffee every month. It’s less, I bet, than your cell phone bill. It’s really the worst possible excuse that you can come up with—if you have the passion to program for iPhone OS, there is absolutely nothing stopping you from doing so.

The kernel in the kettle

In principle, I join Doctorow and many of my friends in disliking the fact that Apple has appointed itself gatekeeper of what gets to play on the iPhone. On the other hand, I see the App Store as integral to the kind of evolution that the iPhone represents. One only needs to look at the gargantuan (and largely pointless) effort that Microsoft has undertaken to try and keep viruses and malware off of a typical Windows machine to realize that the App Store has enormous advantages for your average user.

Note that nothing prevents you from exchanging code with other iPhone OS developers. There are tons of open-source code for the iPhone that you can download from a multitude of sites. In fact, many of the graphics, sounds and physics engine used by even the most popular iPhone OS games are entirely open source.

One thing that is interesting about the App Store is the fact that it is, in fact, much more open than the vast majority of distribution channels in existence. Sure, you can write an application for Windows without Microsoft telling you whether you can sell it or not, but… have you ever tried dealing with a distributor? Think that you, small developer, will get the same shelf space as Office at your local Best Buy? Will you still think that the 30% “Apple Tax” is prohibitive when you find out that your typical distribution deals start at 45%, and all sales are on consignment?

Of course, you can sell your product over the Internet and avoid paying anyone anything. There’s no disputing that—which is why I say that, in principle, I agree that the App Store is far from perfect, but that’s a far cry from saying that Apple is trying to turn us into an army of mindless drones. I’d say, rather, that Apple is trying to make sure that we don’t have to worry about what’s inside our computers unless we want to—in which case it provides us with the tools to happily shoot ourselves in the foot as long as we don’t point the gun at anyone else.

After putting my thoughts to virtual paper, it seems to me that tinkering is going nowhere. It’s just evolving alongside the rest of our world, so that applying old lessons to it makes absolutely no sense.