Neil Mix

Prior to this past week, I’ve had several theories about the fabled Apple Tablet computer (in order from least cynical to most cynical):

• A brilliant new product with a revolutionary keyboard input mechanism
• An interesting product idea waiting patiently to become technologically feasible
• A really cool-sounding bad product idea whose keyboard input sucks
• A long-since failed product idea that just won’t die
• A series of individual, disorganized hoaxes with a common theme
• An active disinformation campaign designed by Apple to foil competitors and/or root out leaks

After the past week, just in case the rumors turn out to be yet another mirage, I’m adding one more to the end of the list:

• A conspiracy by tech blogs to drive traffic and increase ad revenues

I’ve heard the iPhone described as a computer that just happens to be a phone, and this is true from a hardware/software perspective. But how about from a consumer’s perspective? While most developers undoubtedly see the iPhone’s computing capability, I’d wager that “mass market” consumers see the iPhone as an entertainment device that just happens to be a phone.

It’s a question with important repercussions. We’ll get to that in a bit.

First, consider the attributes of entertainment media and compare to computer applications:
Media: pleasure-based, ages quickly, must be relevant, low margin, large audience.
App: task-based, ages slowly, must be useful, high margin, small audience.

So when you write an “app” for the iPhone, are you developing software or producing media? It’s a strange crossover hybrid, because the most successful apps are…both, really. The iPhone makes media more useful. Or does it make productivity fun? The lines are blurred.

But when it comes to how apps are sold, the answer is pretty clear. Fire up iTunes and observe how apps are seamlessly placed along-side music, TV, and movies. Notice too that app prices have dropped to accommodate larger audiences. As every iPhone developer knows, getting on the top 20 list is the key to sales. But there’s a lot of churn in that top 20, few apps stay there for long. So top apps are very current — here today, gone tomorrow. And the audience is fickle, which means predicting (or causing) popularity is, well, awfully hard.

This can have a tremendous effect on product development. If you’re building something productive, usefulness is no longer enough to be successfull — it needs to be fun, too. And you have to think in terms of a recurring product line rather than a single flagship product, or you’re unlikely recover your development costs.

But even more important is Apple’s relationship with you as a developer, and what it means to be an entertainer. They are the distributor, and you are now the starving artist. Imagine a long line of performers on a blustery morning waiting to audition for a major Broadway production. Now put yourself in that line.

A few developers will hit big and eventually earn esteemed status with Apple. But most will simply live in the crowd, creating products for fun or dreaming of stumbling across the-next-big-thing.

Developers are not used to being treated as a commodity, and accepting this reality means swallowing a lot of pride. But that is the reality right now — iPhone developers are a commodity, and Apple has plenty of room to err before it loses significant dev capital.

It’s amazing how much the Internet has changed the software development process. There’s now an entire generation of techies (including me) who were indoctrinated into the art of building software with a casual release process. Back in the old days, releasing software was anything but casual, because you’d put the bits in a box and put them on shelves to sit and wait for someone to buy them. But the web brings the customer to the software every time they use it, which makes traditional software release go all topsy-turvy.

It all starts with cost structure: in the ancient world when there was no Internet, how did you fix a product defect after it was released? Well, you put the fix on floppy disks and mail it out to customers. As you can imagine, that’s pretty costly. So if you release a product with a serious bug, you’re going to chew up a ton of money paying for what turns out to be a product recall. You know, like when a car has a safety defect and you take it into the dealer to get fixed. It doesn’t take much mental effort to realize that in this world shipping defects results in an unprofitable business. And thus software companies (the ones that succeeded, anyway) learned to be very careful when releasing product. This is where the term “GM release” comes from — the “Gold Master” CD on which the software was written to be mass-duplicated. Once the bits are written, they don’t get unwritten.

Along comes the Internet and its new-fangled web-apps, and suddenly it costs almost nothing to release a bug fix. That one little variable changes, and now the software development process is entirely different. The strict no-risk release process now loosens up a little, becomes more casual. Pretty soon, the “throw it against the wall” mantra becomes popular, and people start intentionally releasing unfinished software just to gauge market interest. Release-early release-often becomes an entirely new way of doing business.

For seasoned software developers, this change had a varied effect. Some got it right away, some didn’t. More interesting was the effect on corporate cultures. I remember from my time at Microsoft (early Internet era) how the entire corporate culture was built around the concept of bits-in-a-box. This new Internet craze had arrived, but many teams were applying old ways of thinking to the new problems. It’s not too surprising that they don’t fare well on the Internet to this day.

Of course the reverse happens as well. Having started my career building web applications, I remember the tough transition I had when I joined a company doing long-release-cycle software. I hadn’t yet learned the design skills, testing skills, and patience required to truly finish things off before releasing. I kept approaching implementation with a sense of urgency framed by the Internet, and my approach didn’t fit in with the rest of the team.

Any time you begin development on a new platform, one of the first things you need to understand is the release cycle. This is something that has tripped up many iPhone developers. The App Store doesn’t work the same way as releasing software on the Internet. Imagine a curmudgeonly long-time Apple veteran whose been through more OS builds than you have web sites. To him, waiting 4 weeks to get a bug fix out the door is pretty decent. And that perspective undoubtedly influences Apple’s approach to the App Store. Yes, Apple’s perspective on this is wrong, and it will eventually pose a serious problem for them. But for now, it’s sadly the app developer’s problem to solve. Design carefully, test for a long-time, and ramp-down quickly on changes prior to release. It’s not as fun and agile, but it’s doable if you plan for it.

Andrew Woolridge proposes an App Store for the web. Honestly, ever since Apple opened the iPhone App Store I’ve wondered why every platform didn’t already have its own version of the same. Trying to find software is generally a time-sucking, awful activity akin to mixing dough with a spatula. A web-based App Store would be awesome. The catch: how do you prevent it from ending up like download.com?

Imagine you’re the developer of a complex application with many moving parts. It’s been released, and by all metrics it’s a homerun: customer satisfaction is through the roof, new customers are flocking to it in droves, and the product is efficient and scaling well.

But there’s a bug in the system. It’s breaking things, but in a very small way. It’s not effecting the business bottom-line at all (although it could in the future). It’s easy enough to fix in isolation, but you’re not sure how your fix will influence other dependent components. And if this bug begins effecting the business, you’ll have plenty of time to fix it before it registers a serious impact.

What do you do? Wait, of course. You wait until either the bug presents a risk, or until you devise a way to fix it that presents no risk. When things are going well — beyond all expectations — the last thing you want to do is introduce risk where it’s not needed. Just sit on it.

Ok, now imagine you’re an executive at a large public company with millions of customers and tens of thousands of business partners. You have a products for which customer satisfaction is through the roof, and new customers are buying it in droves. You are decimating the market. Profits are through the roof and shareholders couldn’t be happier.

But, some of your business partners are telling you that there’s a problem. This problem isn’t really effecting your business, and fixing it carries the risk of impacting other parts of the product and business in undesirable ways. And, despite the fact that your partners aren’t fully satisfied, they’re continuing to work with you and tons of new partners are scrambling to set up partnerships.

You see where I’m going with this, don’t you?

When I say “please stop whining about App Store review”, what I’m really trying to say is: focus your effort on something more productive. Apple hears you, they’re just not going to do anything about it. (Or at least not what you want them to do about it.)

The classic argument for loosening App Store review is that Apple is harming their product more than they’re helping. By hand-cuffing developers they’re preventing bug fixes from going live, they’re making developers unhappy, etc — you know the story. And then, the argument continues, that hurts developers and customers both indirectly and directly.

Here’s the problem: the numbers disagree. There is no metric or indicator I’ve seen that demonstrates that the App Store review process is hurting Apple in any way. So from a business perspective why should Apple make any dramatic changes to its review process? All that does is add risk they can’t quantify. There’s a risk they know about, and it’s not yet harming the business. They’d be crazy to act on that risk in the name of adding an unknown (and potentially much larger) risk.

So if you want Apple to change its ways, you can do the following: 1) demonstrate that there is actual risk to the business, or 2) suggest ways to fix the problems that don’t introduce risk.

Opening the iPhone for unrestricted access isn’t going to happen. Consider the history of the PC with spyware, viruses, and worms. Or consider phishing and lack of recourse on the web. Yes, Apple is the sole gatekeeper. In some cases, they’ve abused that power. In the vast majority of cases they’ve benefited customers, as demonstrated by the fact that the iPhone’s App Store isn’t a vast wasteland. They have zero incentive to open up.

To fix the App Store, you have to answer this question: how does one open access for legitimate, quality developers while keeping the scummy or incompetent developers at bay? There are answers, and I’d wager that Apple is already working hard on new and innovative solutions. But the house isn’t burning down, so there’s no rush those solutions to market. They may never arrive, depending on how things go.

So until the App Store is fixed, discontent developers are best-served doing something productive with their angry energy. Go develop apps for other platforms. Or write up enhancement requests with inventive solutions. While it may not seem like Apple listens, they do. The just don’t always respond.