Originally Published: Tuesday, 2 May 2000 Author: Rob Yampolsky
Published to: featured_articles/Featured Articles Page: 1/1 - [Std View]

How Apple Could Help Linux on the Desktop

I just came from a large NYC Barnes and Noble, where I could not find a single book on Macintosh programming. Come to think of it, there were several on Linux, KDE and GTK programming, so Apple might not remain platform number 2 for long.

No, this is not another of those "Apple should base OSX on Linux" articles. This is about cross-platform APIs. This is about paradigm shifts and knowing when to go with the flow.

The company I work for builds vertical market applications. After a too lengthy alliance with Visual Basic (poor people believe they can win Lotto, bosses believe you can build complex applications with VB), management was finally able to be convinced that a thin client architecture could support our users better.

Part of my sell to them was that by implementing a universal front-end application, our server-based code could be deployed anywhere the front-end was implemented. Since we serve the advertising industry (one of the last corporate Macintosh holdouts), "anywhere" meant the Mac. Well, now they're calling my bluff.

My point: in your average software development shop, Windows is a given as platform number 1. Platform number 2 is still the Macintosh. We'll add Linux for extra credit. The problem: porting to the Mac is essentially a rewrite, and for that reason, many (most?) shops rarely get around to it. You want proof? I just came from a large NYC Barnes and Noble, where I could not find a single book on Macintosh programming. Come to think of it, there were several on Linux, KDE and GTK programming, so Apple might not remain platform number 2 for long.

That's Apple's problem as much as mine, and they're in the best position they've ever been in to solve it. Why? Because the industry is crying out for a cross-platform API. Java has whetted their appetites, but hasn't come through. So here's what you do Steve. Apple could embrace one of the emerging Open Source APIs, and port it to the Mac.

Why Open Source? Because the only other choice is to support somebody else's proprietary API and that won't work -- ask IBM.

Why would this be good for Apple? Because people want to support the Mac and can't. With Apple's mainstream credibility, commercial developers might actually come on board in a big way. Reach critical mass, and there will be no stopping it. Once it's just a re-compile, all kinds of applications will start showing up on the big 3 platforms. Other platform vendors will be forced to come on board to share those benefits.

Why would this not hurt Apple? Because it's not Windows, and it's not owned by any one player. It's not embracing the competition -- it's replacing it with a newly-competitive level playing field. People are already buying Macs knowing that they are limited to a few (mostly Microsoft) applications. There must be some reason for this, so I don't think that seeding the Linux marketplace will detract from Apple's ability to sell computers. It just further commodities the computer, and Apple does a pretty good job of selling that commodity.

The point is to consolidate the industry around an "officially supported" cross-platform API as soon as possible. Given enough time, the open sourcers would do it themselves, but the Mac's platform number 3 for them already, so Apple's going to have to do it themselves. There isn't enough time to wait. Microsoft lost the antitrust suit; they don't need Apple as monopoly insurance any more.

QT and (to some extent) GTK are already available for Linux and Windows. WxWindows already supports (to some extent) all three. But there's no commonly accepted standard, and the developers are not going to come in a big way until that standard emerges. Apple needs to work with them -- to work with the tool developers to build great cross-platform IDEs.

If you build it, they will come.

Rob Y. is trying to get the VC4 cross-dev edition to work. If you know how, drop him a line.

This article is provided under the OpenContent License, and was first shown at osOpinion.