Until recently, if you bought an iPhone (which I did) or a Pre, your only officially-permitted mechanism for getting applications onto your phones was the iTunes App Store or the Palm App Catalog, respectively. This is strange: most modern software platforms have open executable formats that allow developers to distribute their software directly to end-users. So, for example, you don’t need to get Apple’s approval to release a new application for Mac OS X. But iPhone and Pre users don’t enjoy that freedom. And the result, I think, is a great illustration of the problems that top-down systems can create.
An app store sounds like a good idea in principle. Users want applications, and app stores give them a convenient way to get them. And Apple and Palm are understandably concerned about quality control. But the problems start when the app store is made the sole distribution channel for applications. One developer recently recounted his months-long ordeal seeking approval for a Pre application. This was an application he developed by himself, in his free time, and was seeking to give away for free. Three months and dozens of emails later, the application in question still isn’t available to Palm users. Apple’s approval process is plagued by the same kind of problems: rejections for trivial or non-sensical reasons and long delays in the review process have become a staple of the tech blogosphere.
The striking thing about these incidents is that they don’t seem to be the behavior of a rational, profit-maximizing firm. Some of the rejections could be plausibly described as strategic business decisions, and others may be legitimate quality control, but we’ve seen a number of examples that can only be described as pure stupidity. It seems unlikely that the management of Apple or Palm deliberately set out to make the review process slow, unpredictable, and frustrating for developers. The value of a platform is greatly enhanced by third-party applications. These companies should be bending over backwards to make the review process as simple and painless as possible.
I think the problems with the Pre and iPhone approval processes reflects the inevitable inefficiencies of top-down filtering. Reviewing applications is a complex, labor-intensive process. As these platforms have grown, the number of people required to perform the necessary review has grown as well. And as the number of reviewers grows, it gets harder and harder to make the process both fair and efficient. Different applications will be given to different reviewers, who will interpret the rules (which may not be particularly clear to start with) differently. The overhead required to keep all reviewers on the same page grows faster than the number of reviewers, so as the platform gets more popular the review process itself becomes a major bottleneck for the platform’s continued growth.
This is an old story in the technology industry. In the 1990s, for example, we saw a competition between the open Internet and a variety of closed online services like AOL and CompuServe. The open Internet won because it scaled better. Because no one had to ask permission to offer a new Internet service, the quantity of interesting content and applications on the open Internet grew at a rate no one firm could hope to compete with. Top-down systems scale poorly, and so making a top-down system a bottleneck for your platform is a long-term recipe for stagnation.
This week Palm announced some changes to its approval process that sound like steps in the right direction. Although the details are still sketchy, it appears that application developers will soon have the option to release their software directly to the general public, bypassing Palm’s approval process. If you want to get your application into Palm’s app catalog, you still have to submit to Palm’s review process, but review won’t be a pre-condition for distribution.
Making review optional nicely addresses the scalability problems with the app store concept. Mandatory review of every app means that Palm wastes resources reviewing applications whose developers may not need it or may lack the time and resources to fully participate. In contrast, optional inclusion in the app catalog allows developers to self-select into the program if they think they will benefit. And this, in turn, allows Palm to focus its resources on reviewing and approving the cream of the crop. Most important, it removes the review process as a bottleneck for platform growth. The option to route around the app catalog acts as a sort of safety valve, ensuring that the inadequacies of the review process won’t bring down the whole platform.
The more fundamental point here is that people tend to underestimate the extent to which scalability problems limit the effectiveness of top-down social systems. I’m sure that the app catalog looked like a great idea on some Palm executive’s powerpoint slide. In the abstract, it’s easy to imagine that a review process can be made quick and painless. On a real-world platform with thousands of developers, the practical realities of bureaucratic management become binding constraints. Policies that seem reasonable on paper may turn out to be unworkable in practice because they require too much coordination between different parts of the bureaucracy. But the specific difficulties are hard to predict in advance, since they are precisely the kind of implementation details that an executive’s powerpoint slide is designed to ignore. And so decision-makers are prone to systematically underestimate the difficulties of top-down management.
This is why in many cases, including this one, the right solution is to avoid creating bottlenecks in the first place. Firms should recognize that successful technology platforms are too complex to be controlled effectively by any one firm. If they want their platforms to flourish, they need to decentralize decision-making, giving their users ultimate authority over which applications they use. “App stores” can be a useful way to help users find the best applications, but when app store approval becomes mandatory, it becomes a major impediment to the success of high-tech platforms.
Tim… What I don’t hear you articulating here is your vision of what a “bottom-up” app store would look like and why it would really produce vastly superior results. Nor do I hear you saying anything about the legitimate concerns that the handset makers might have about the security or stability factors associated with certain applications. I’m not saying those problems are extensive, but at the margins they could be real depending on the nature of the program and how it interacts with the handset and/or network.
Second, there needs to be some sense of proportionality here, at least about the iPhone (I can’t speak for the Palm experience). In just a little over a year, there’s been 2 billion downloads of over 85,000 apps from over 125,000 developers.
So, when you talk about Apple’s approval process being “plagued by.. problems” and “rejections for trivial or non-sensical reasons” and “long delays in the review process have become a staple of the tech blogosphere” I think you are giving the impression that this is somehow the norm when it is very much the exception to the rule. Perhaps you would be willing to itemize the examples for us. Once you do, I’d appreciate you doing the math on what that looks like as a percentage of the total 85,000 apps that are out there today. I am willing to be the result is something like 0.000001%.
Again, a sense of proportionality is really key here. While I am not an Apple fan and agree they have a bit too much of a control streak for my tastes, it’s hard to argue with results. In this case, a closed, top-down system has produced some fairly spectacular results.
Adam,
A bottom-up market for iPhone applications would be one in which developers were free to distribute their applications directly to users. If that were the case, then it wouldn’t matter too much what policies Apple had in the official app store, because customers would be free to bypass it if it didn’t suit their purposes.
As for Apple’s success in attracting developers, I my sense is that this is despite, rather than because of, the way they treat developers. The fact that 85,000 developers have gotten their applications into the app store doesn’t tell us anything about how much frustration they experienced in the process, or how many more applications Apple would have if they didn’t jerk their developers around so much. I’m not an iPhone developer, so I don’t have first-hand experience, but stories like this one suggest that there’s a lot of dissatisfaction.
As for the number of complaints, it would be surprising if a significant fraction of disaffected iPhone developers went public given that Apple has them by the balls. If you start bad-mouthing Apple, will they hold up your next iPhone app? Probably not, but why take the chance? So I suspect there are a dozen privately disaffected developers for everyone who’s gone public.
As for the security and bandwidth concerns, I don’t really have a strong opinion about that. Maybe some restrictions are justified by these concerns, although I’m skeptical. My point is simply that top-down management imposes significant costs, and platform builders need to take those costs into account. If they can find a way to build an open platform, that platform is going to do better than the same technology as a closed platform.
Great post Tim!
Adam, I don’t know that the numbers you’ve given are useful metrics in this context. I’m willing to concede that the iPhone is a wildly successful product and that the percentage of applications being rejected for spurious reasons is tiny, even taking into account the points Tim made about developers having a strong incentive to remain silent. The problem is that these numbers don’t prove that the iPhone wouldn’t be an even better platform if it were more open; it only proves that it is a very successful product as it is.
You also mentioned security and stability as important factors to consider. There’s a concept in security called “security through obscurity.” The point of it is simple: just being a closed or obscure platform doesn’t give you perfect, complete security. Security is all about risk, and ‘obscurity’ is just one element of risk management. All we can generally say about switching from a closed to an open platform is that the risks (and therefore the security considerations) will change, sometimes dramatically.
In this case, it makes sense to me from a security and stability standpoint to open up the iPhone platform because the iPhone’s OS is basically a port of Mac OS X, which was originally designed to be an open platform. Apple clearly wants engineers to be able to easily build applications for both platforms moving forward. It’s hard enough to design secure software when you are only dealing with either an open platform or a closed platform, so why put your engineers in the position of building secure software for both situations at the same time?
Apple could try to get (some of) the best of both the open and the closed worlds by having different classifications for applications. I’m thinking of something similar to the “components” system that Ubuntu uses. This means they could have a set of applications that are approved in whatever process they want to use and as many sets of ‘unapproved’ or ‘experimental’ applications.
Apple could even set it up so that users wanting to use unapproved applications would have to disclaim liability for the security of their data or the stability of their system. This seems reasonable to me. If you give users the power to approve of and install their own applications, then they should take personal responsibility for the consequences, if any.
Those are just a couple suggestions. I don’t have a problem with Apple doing whatever they want — it’s their product, but then, it doesn’t look like Tim has a problem with that either. He’s just arguing that the top-down approach to the App Store is not as good as a bottom-up approach would be.