Pay As You Go
Volume Number: 10
Issue Number: 8
Column Tag: Inside Information
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 e specially
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).
Referenced by (2):