Pay As You Go?

Will Apple continue to use your SDK dollars to figure out what to roll in?

By Chris Espinosa, Apple Computer, Inc., MacTech Magazine Regular

In the early days of PCs, the relationship between developers and platform vendors was pretty straightforward and consistent. The platform vendors tried to sell as many copies of the platform as possible, and application developers would write applications that used the features of that platform and sell them to the people who purchased them. It was pretty symbiotic: platform vendors needed a good set of applications in order to make the platform interesting, and developers needed an interesting, high-volume platform to make innovative and profitable applications.

In the early days, the platforms weren’t that complicated. Developers could get on a new platform for the price of a decent development environment and the technical manuals for the system, usually under a couple hundred bucks. All the functionality that they read about in the manuals and could access through the development environment was present in the platform on most everybody’s machine. The only times this wasn’t true were when the platform vendor had introduced a new version; but even then the hardware vendors bundled this new version for free, creating an instant installed base and demand for new applications, so developers could target the new platform with some degree of comfort.

In many ways all of this is still true, but time, complexity, and economics have intruded. As time goes by, the installed base gets larger and more fragmented, and it’s no longer possible to assume that everybody has the same version of a given system. The systems are getting more complex, and few applications touch every part of the underlying platform. And the costs of continuing to support and enhance the platforms keep going up, even as hardware, operating system, and application prices continue to drop. For example, when Apple was selling a Mac II for over $4000, we had a little over 75 engineers in the system software group; now we have several hundred, but a Power Macintosh sells for under $2000 with essentially the same manufacturing cost as that Macintosh II.

Developers are feeling the same effects. Your legacy code is harder to maintain as it ages. New code is harder to write as new APIs come into the system and you have to navigate Performa, Quadra, Powerbook, and Power Macintosh lines, not to mention cross-platform portability. And your revenues are falling with dropping software prices.

So it’s understandable that you’re angry when the platform vendor changes its policies and makes it even more costly to get applications to market. Though Apple has gotten a lot of flak for it, it’s not purely a Macintosh phenomenon: Microsoft, Novell, IBM, HP, Sun, and even NeXT see the developer as a source of revenue as well as a partner in promoting their platforms. Most often, this revenue comes from developer tools, and most developers don’t mind paying reasonable prices for tools that improve their productivity. It’s a little more controversial to charge for technical support, tech notes, etc. Good tech support is naturally labor-intensive; you want to talk to a live person who can understand your problem and find an answer. That costs money, and once again, those who see the value to their business don’t mind paying a reasonable price.

But let’s get to the core of it. Developers hate being charged for essentials, the things they need to get to the capabilities of the OS. Essentials like header files, system libraries, APIs and SDKs for new operating system capabilities. This is especially true on the Macintosh platform, where the low market share vs. Windows makes it seem sometimes like a burden, not a privilege, to support the Mac.

Is Apple clueless for charging for APIs? Perhaps. Between the Usenet discussions and the May developer conference, Apple heard loud and clear that developers are sick of being nickel and dimed to death for system essentials. I know that the people inside Apple are motivated to fix some of the problems that have happened in the last year with the proliferation of system versions, SDKs, and the costs of those SDKs compared to the value in them.

But some of the problems are inherent in the historical concept of the API, and how that is breaking up. Even with big “consolidation” releases of the Mac system like System 7.5, there will still be a lot of Mac APIs that are not universal across the product line. Sometimes this reflects hardware limitations (like PlainTalk), and sometimes it’s because the capability is narrowly desired (e.g. Data Access Manager, once part of System 7).