Rhapsody in Yellow

Disclaimer: This one is going to be fairly long, and if you've been in the Appleverse for quite a long while a lot is going to feel like review... we're going to have to hit the wayback machine™ several times when talking about certain technologies. While I'll talk a lot about them, I'm not writing a book so it's not going to be exhaustive. But it should be enough, and while we'll cover enough ground to get the gist across, google & linkage should be your friend. As it stands, this could probably have been broken up, but I feel I owe my 12 loyal readers something of length to make up my... erratic posting schedule.

So... I was having a chat recently with someone about the lack of a certain software title for the Mac, which really seemed to be cramping their style. This eventually meandered (alcohol was involved) into a much larger topic:

What the hell is going on with independent development & the Mac?

It's obvious there have been changes, as others have touched upon, such as a big influx of *nix users to their developer base. But as far as big, high-quality apps... there just aren't many, and those that are being released are from the usual suspects. Nothing much new. Isn't Cocoa a developer nirvana, and doesn't the "power of Cocoa" allow one guy to do the work of 5?

This was really cool, because I already had some stuff written up which meant I could tie it together & make a blog post with a minimum of effort... which is like finding a quarter in the cushions as far as I'm concerned. Blog gold.

Since Cocoa is inherently a developer technology (which I'll go into further later), it'd make sense to start with the developers themselves. It's virtually impossible to get accurate developer statistics for the mac at the moment, namely because Apple, for whatever reason, doesn't want you to. Sure, they'll release 'select' blurbs that have high numbers, but they're so impracticably vague that they might as well be claiming every mac user is a developer since a copy of the developer tools come with every Mac.

I wish I was kidding. I have a several damn pages of hashed out numbers where I tried to distill the available info into a decent guess via inference from available info with a developer pal several months ago. It became obvious my effort was a pretty complete failure, although it was a fun mental exercise. There were too many missing variables without making some phone calls to get anywhere close, and racking up long distance for a blog post would have been a bit silly.

For whatever reason (you can prolly infer), Apple just doesn't want people to have hard developer numbers. I will say that I'd be very, very surprised if there are more than 10,000 developers earning their bread coding for the mac, and if I was a betting man I'd peg the number even lower. Which isn't to say there is some dire shortage developers, more it's about recognizing the limitations of what we know, versus what Apple knows. If you know, tell me.

I'm not a developer by trade, but because of how I earn my bread I run in a lot of their circles, and even if I didn't I like to keep my fingers on a lot of different pulses so I'm able to form my own fuzzy picture of what's going on. Lately, when it comes to Apple's development base, that picture has gotten both clearer in some areas and fuzzier in others... and hence, interesting as hell.

But then again, it always has been. Apple historically hasn't had a good relationship with developers (which we'll touch upon later), and while I'd have to do more checking than its worth, I wouldn't be surprised if Apple has had the most cantankerous developer relation of any OS vender evar. Some of the current stuff is sour grapes, but lordy have they burned some bridges in the past, with one developer I encountered several years ago saying (paraphrasing):

Discontinuing my efforts on the product wasn't an easy decision, and there were several factors and taken as a whole lead to it:
  • 25% was due with the shrinking user base for my type of product
  • 25% had to with the current outmoded architecture for my type of product, and I really don't know when they will actually ship what was promised. I prefer using the mac, but NT has those features now
  • 50% is about never wanting to have to call Apple again. It is impossible to get anything out them even after paying exorbitant sums unless you are one of the big big apps. I have no illusions that Microsoft really cares about my company but they at least buy you dinner before asking you to drop your pants.

Why is that interesting? Because if the pulses I'm hearing are sound, they've made some serious inroads into changing that perception.

Apple guys are extremely helpful in a lot of the mailing lists, more responsive to bug feedbacks and giving workarounds, documentation has improved (it still has a long way to go, but you can tell it is a question of manpower now, not will)... for the most part, across the board, Apple is not only buying people dinner they're often leaving a little mint on the pillow for when you wake up.

Many a developer is taking a gander at MacOS X and liking what they're they're seeing:

  1. For free
    Every single copy of MacOSX, and every single Mac sold comes with Xcode, an IDE which which can hold its own against many of the commercial packages out there. Also included is Interface builder, an extremely elegant tool for rapid GUI development. For free. To compliment those development tools is a decent, cross-platform compiler for C/C++/Obj-C... free.

    GCC isn't the fastest on any platform and it has some severe speed problems on PPC (not going to rehash my old GCC rant), but it's there, and a known variable. And, again, free. Yes, the compiler is open source, and can be had for windows, but there is a mindset in including it with the computer that just isn't the same. This is, bar none, prolly one of the coolest things Apple has done in a long while.


  2. !#
    Just about any scripting language your heart desires is going to be available to you. Well, not just available to you, most are available in some form on Windows. But they are included, and integrate well. Python. Perl. PHP. Ruby. Installed by default. Slick.

  3. SELECT *
    Front-end guys are arguably getting kind of screwed with the mac at the moment, but back-end guys are happier than they've ever been, or ever could have been if Apple hadn't gone the *nix route with their OS. In addition to the scripting languages mentioned above, you're talking: MySQL, Apache, Tomcat, PostgreSQL... it's all there, and if it's not, it's prolly on the way. You can run everything I just mentioned on windows, but the shoe is suddenly on the other foot, and you feel as though you're running a port. The tech started on *nix, and that's where it swims.

    No, it's not perfect yet, and not everything is included by default, but getting up & running is much easier. This is something that is hard for a lot of windows users to relate to: you can just tell when something is a port, and not really in its environment but being shoehorned into another. It might be acceptable, but it doesn't make you go Ahhhhhhh. The backend guys are prolly second only to the video guys in the lack of drawbacks in paddling over to the mac end of the pool. Powerbooks instead of desktops are often a real option for these guys, and they do love that sexy kit.


  4. Java
    Java really doesn't suck. Honest. To most mac users it does, as they're generally used to something like Limewire, that starts slow as hell, runs slow as hell, and just doesn't feel right. Or having it embedded in a website that isn't just java applets, but ties those applets to activex/liveconnect controls that make it all but unusable on an alternative platfrom. Love it or hate it, Java is going to be around for awhile, and it's taught in a hell of a lot of curriculums. And Java doesn't really suck, but java apps with GUI's (egh, Swing) often can.

    In the case of a GUI-less back-end, it can be a really, really slick, and once everything is running, you don't really lose much speed. And it allows for enormous freedom: as long as the platform has a VM, you can move to it or add a box with your app on it. Linux, Apple, Microsoft, Solaris, anything. And Apple actually has a very nice VM.

    No, it's not as fast as Microsofts. And yes, the MHz problem hurts its usage. And yes, there have been issues with it being a bit behind in the versioning. Quite a few of them, to be honest... 1.2 especially really hurt Apple's mindshare. But the versioning problem has largely been ironed out, even if the releases still take a little too long, and there are some really nice technical advances Apple has contributed. Apple is a credible platform for java development, no matter what the target OS, and is a very sexy platform for mobile development.


  5. Mocha
    ...Or, Java + Cocoa. This is something that's of interest to me, and I've been trying to follow it for awhile. Java as a syntax really doesn't suck, and there are a hell of a lot more developers out there who know the Java syntax than are familiar with Obj-C. It isn't to say that Obj-C is some nightmare to learn, but rather that in allowing the use of Java syntax en leu of Obj-C for Cocoa development, a developer moving towards the mac is able to get up and running that much faster.

    They're already going to be spending most of their time learning the idiosyncrasies and nuances of the frameworks. Removing the hurdle of the syntax for developers who are interested in getting their feet wet with the mac is a really good thing™.


  6. Chai?
    Java isn't the only language being tied into the frameworks, and Apple seems to have taken a bit of the page from Microsoft's .NET here (or perhaps Apple did it first, I dunno). Basically with .NET, you have the CLR runtime of APIs, and for the most part can access them in an entire host of language syntax's. C#, VB.NET, etc. Apple has done some of the same, by bridging other languages to toe frameworks. There's a bridge for Perl, Python, and others... and they're being used. In some cases not by many, but they are, and you could well be using one of these apps and not realize it.

    As an example, fire up one of the newer BitTorrent clients and you'll see python running in the background. Syntax can be a pretty personal thing, and if you have a large Python knowledge base, the idea of being able to translate that outside of places you may have normally been able to apply it, well, very cool. I may sound as though I'm repeating the Java thing, but this is something I've heard come up many, many times when I'm chatting up developers: they like the fact that OSX, by bridging their weapon of choice to the frameworks, lets them capitalize on their knowledge base. This isn't to say that there aren't GUI Python (or other language) bindings & such for other platforms, there are.

    But there is where you come back to the Cocoa frameworks, and the value they add. It's nowhere near 100%, but not shoving Obj-C down their throats is really making these guys take a look. This also isn't to say it's perfect, it's not. It's not quite as pervasive as .NET. There are things you are going to have problems accessing via languages other than Obj-C, depending upon what your needs are. I've checked in without developers to be confident in the statement that while Obj-C is cool and all, and I certainly don't have a problem with it, the value is in the frameworks, not the language.


  7. Unix is expensive
    ...at least traditionally. Apple missed the first Unix gutting at the workstation-level by the bottom-up OSs, due to not having a technically competitive OS. WindowsNT pretty much sucked up that share, as companies like SGI found out the hard way. Linux has pretty much eroded the the server share, as its lack of a competitive GUI wasn't really a hinderance. Even now, the traditional Unix's are only generally used because if you need it, you need it, if off-the-shelf hardware couldn't do the job, or you needed things like 64-bit.

    But while a huge chunk of that shift has already passed, that shift is still going on, and Apple isn't above scavenging on the carrion left behind. The introduction of the 64-bit Opteron and the G5 have, hopefully, started a second but smaller wave, and apps that didnt migrate to NT but to Linux are ripe for porting to Mac OSX via Apple's implementation of X11 being very viable. Things like IBM's announced XLC compiler and Fortran compiler for PowerPC are removing more of the stumbling blocks to the scientific market.


  8. Protected memory
    This one seems kind of trite if you haven't been developing for a long time, or are new to the mac, or come from a background where it's just a given. It isn't something that people talk about much now, but paleo-macdevs still hurt from it. Developing for the Classic MacOS just sucked compared to what else was out there towards the end.

    If you aren't a developer, stop and think about how when Internet Explorer 5.0 used to crash in OS9, your entire fsck'ing computer would lock up, requiring you to reboot and having to run a disk repair program to make sure things were kosher, etc. You also either lost some of what you were working on, or had to get "back to where you were". Now imagine having to do this 50 times a day because, you know, you are debugging. If you've ever developed a web page, imagine having to reboot your computer every time you preview the code in the browser. Not fun times.


I'm sure I could go on, and I'm sure I'm missing things. There are of course other ways of developing for OSX, and a more exhaustive list can be found here. But you should be able to get the gist: Lots of developers are looking at Apple in a different light, and getting interested.

So everything is all rosy, right? Well, not quite, although all of the above is excellent. If you'll notice in the above, most of "successes" I've mentioned center heavily on the Unix side of the pie, or are related to Apple having an OS based upon a *nix.

What's missing? Few Windows developers are making the jump.

Now this doesn't mean none are, just that as a ratio, when you realize just how many developers MS has on their fence, and how many have come over... something is prolly askew here. Is this a problem? Depends on who you ask, I guess. But for the sake of my carpal tunnel I'm going to assume it is, and go from there. Since we've identified it as a problem, what's causing it?

Several things come to mind:

  1. Lack of an entry-level language
    There are few things I hate more than a $10-$19 shareware program that essentially does nothing but take a few arguments and appends them into a string as and passes them to another application via NSTask. Hell, I can do that, and I'm a retarded monkey when it comes to coding. But something I hate even more are RealBasic apps. Some of those apps make me want to cry like the baby jesus.

    I'm not going to start bashing Real Software or anything of the like, but it's a fair statement that if the app is made in RealBasic the chances of it sucking go up by several orders of magnitude. Much of that has to do with the vastly lowered barrier to entry, both in the language and in what Real handles for you. There's nothing inherently wrong with Basic, things like VisualBasic are good IDEs. Some of the programmers I've worked with (IMHO) and hold in the highest esteem use VB, although most of the good ones are hankering to move to C# post haste and they're using it because that's where the work is.

    There are probably hundreds of thousands if not millions of people out there using a form of Basic, whether RealBasic, VisualBasic, VB.NET or others. I wouldn't be surprised if RealBasic itself has a mac userbase of several thousand. There's a market there. You could say RealBasic fills that niche, but I'm not going to go there. It doesn't. A VB-style syntax accessing the frameworks through Xcode would. Keep reference counting for memory management if you have to. Whatever.


  2. Limited talent pool
    Everyone talks about how Cocoa will deliver your kids and all, and it really is some great tech. The problem is that very few people actually know how to develop for OSX well. Apple themselves isn't excluded from this. NeXT didn't exactly have a huge user or developer base, and it's no secret a pretty big chunk of Apple had to go for training. A lot of the earlier apps kinda reflect that. I'm tempted to say some of their apps still reflect that.

    You also have the problem that with the current OS, you're often not just talking Cocoa, you're talking Carbon. Big chunks of OSX functionality need to be hit through an alternate method, depending on what you're doing. Things like, oh, Quicktime. Moral of the story, even if you wanted to go out and hire 100 crack OSX developers tomorrow I'm not sure you'd be able to. This raises the barrier to entry to a company who decides they want to enter the mac market in a timely manner in more ways than one. Bit of a vicious circle here.


  3. Dev DDT
    Namely, the chicken & the egg problem. Developers want users to sell their software to, and users want software for a platform they choose. If there aren't enough target users to sell to, the opportunity cost for porting/creating their app for the mac is too high. If a user needs an app that a developer hasn't ported because there aren't enough users... nice circular dependancy there.

    One of the things mac users just love to point to when market-share figures come out is that yeah, will a billion PCs were sold in the last month, how many of those are actually viable desktops for developers to target? I.E., a ton of these will be blank boxen rolled out in corporations running Explorer & Office and that's about it.

    Ok, that's valid. But it works both ways. There are ~10 million macs around the world running OSX. How many of those are spread around K12/university labs or other like place? I wouldn't be surprised if you're talking 15-30%. No I'm not saying the sky is falling or any other such thing, but it's also no secret that the mac base just isn't growing like the PC base at the moment...


As an example of the above, a little while ago I ran into a company recently who was going to be doing a vertical-market app for the cabinet/CNC/interior-design industry. For the sake of this, let's call them Acme company.

Acme company is starting to look at a linux port as 'they've been hearing things about it' and part of the . For whatever reason, I started talking about the cocoa frameworks in an abstract way and fired up projectbuilder and mentioned the term 'free'... they really took to it, so I sent them to Apple's dev site to get an idea of the arch, etc. This was more of a lark than anything, and they were "SUPER interested", but basically said "It's really really cool, but no way. None of our clients use macs, the whole industry is windows".

Since none of their clients are using macs, and they just get an occasional call about a mac version, they really can't justify a mac port just to go phishing, as you know, not everyone is as desperate as Corel. So mac users are left without this app to get their Feng Shui on. On the bright side, I got several beers out of it.

There are two quick things to clarify here:


  • They could have been up & running to make a Cocoa version for less than $1k, assuming eMac + Ram + free dev tools. But actually getting someone who could handle the code, could translate the raster library to something on the screen as well as translating the DirectX stuff to OpenGL... you dont even want to upper range of pricing they were being quoted by just about anyone wouldn't be learning-on-thejob, and even then the time-tables were iffy. For a small company, not gonna happen on a lark. Part of that has to do with the fact that they're taking advantage of off-shoring, and the other part is that getting decent Visual C++ guys to smack it together (in the USA) would cost about the same, but for, well, the other 95% of the market. The opportunity cost was just too high.

  • Vertical may be a poor choice of words, or at least can conjure the wrong image, as people often associate it with $20k stock-market apps or Maya plugins or the like. Niche can be more appropriate, and basically spans that isn't mass-market. Most of this stuff isn't very sexay.

    We're talking about apps that interface with sewing machines and download patterns, apps that keep track of soccer statistics for a team (not fantasy games!), tools for making cool Flash stuff, web marketing tools, media compression tools... gazillions of small little markets. And due to share ratios, if there are 5,000 x86 users for a niche market, if its not directly related to one of the macs core markets, chances are there's only a base of ~300 to sell to on the mac. For a $20k vertical app, the user prolly won't care what machine they have to run it on. For a $49, they will.


This isn't saying anything new to anyone who's been around the mac for awhile, but it's started to get a bit exacerbated lately. The loss of Framemaker is going to make people I know have to move to windows to get their stuff done, yet it's still available for Solaris. That's a big wtf. Some are trying to figure out some kinda-insane workarounds, but it's fairly obvious they're going to have to buy a PC to get that stuff done. Palm has dropped mac support in their upcoming OS. Adobe's not exactly making a lot of friends in the mac community, and I swear to gawd I'm not even sure Dreamweaver 2004 shipped with the gawd-damned debugging code removed. But I digress.

The chicken & egg problem is getting worse, and is probably the largest problem on software makers minds. The economy is picking up again, but Apple's unit sales aren't really showing it. I've spent a reasonable amount of time going through Apple's Q1.2004 earnings, and they're a little disturbing. That's a whole other blog post in the making, but some of the highlights:


  • Apple only showed ~5% unit growth in computer sales, while the rest of the industry showed a bit less than 15%. Part of the problem with this is that most of the growth is taking place on the low-end of the market, which is probably an indication that we've seen a downward price point shift.

  • The G5s are still squarely in the problem area, especially considering the very hefty marketing efforts pushing them lately including big rebates, etc. They actually did worse than I thought they would, selling about 174k units. Apple is going to be working on some "intense marketing efforts" to fix this.

  • The iMac and Powerbook are doing pretty poorly, with the iMac showing a 15% drop in sales from last year, and Powerbooks showing a 20% dip between quarters. The revenue dropped on the Powerbooks was less than 19%, which prolly means they've been able to push up the margins since the tech is a bit long in the tooth. Even stranger, the iMac sales are still lumped in with the eMac sales, so we don't really know ohw poorly the iMac is doing.

  • Japanese & European sales are down. Way down. Europe was down 22% for the quarter, and Japan was down 29% for the year. That kind of a drop is more than a little disturbing.

  • The iBooks are doing... ok. They showed flat growth between quarters, but a 50% jump from the last year. More interest was that Apple didn't seem to really know why they had the jump, or at least the analysts weren't buying their pat explanation which was a repetition of the phrase "G4". This was actually an interesting point of the call, with analysts wanting a more concrete explanation as to what was actually going on (as well as with foreign sales), with Apple really not offering much. The phrase "trust us" was made, and was a little disconcerting. I don't think we've heard the last of this, I know it disturbed me.

  • The iPod is making up a hell of a lot of their profit, and saw a 900% growth year over year, but only 10% growth for the quarter. Interestingly enough, they didn't want to give exactly figures for iPods or the iPod Mini for competitive reasons... but they did say they are able to meet the demand for the current iPod, but can't for the Mini just yet. The iPod demand leveling out could piss off HP, but the writing for iPod isn't on the wall yet, and HP being able to push the iPod into foreign areas Apple doesn't have access to should be interesting.

  • The interest on cash stockpile is making up more of their profit than it should, but it has for awhile. I think you're going to hear more & more rumbling about a dividend soon.

  • Higher-education share grew some, but nothing major.

  • I don't believe it was mentioned at the call, as its newer data, but Apple's share would appear to have dropped below 3%

  • Apple is "aware" that they aren't really paricipating in the current personal computer growth, but as others have noted, they've made the conscious decision not to compete in the low-end arena where all the growth is occurring. They made several statements you could tell they were hoping the press (and mac users) would pick up, such as "...it's hard to tell if anyone is making money there anyway" (paraphrased), but this was... disturbing. More disturbing was that they didn't really have an answer to it.

  • Just to hit this point home again, Apple didn't seem to have a whole lot of real data about what was really going on in a whole lot of their personal computer sales areas and the term anecdotal was used enough that people were repeating the question.

Considering the current climate (economy improving, overall personal computer market showing growth, and spyware/worms/viruses gone mad on the windows platform), Apples stunted computer sales are worrying. Sure, certain conditions could be more optimal, but Apple can't expect to sell computers during every economic bubble. The long and short of it is that the userbase isn't growing very well.

Cue the part of the conversation where people start talking about BMW's share of the market, and how marketshare doesn't really matter. I love analogies, but anyone who says it doesn't matter just really doesn't understand the network effect or Reed's law.

Now Apple must surely be aware of some of the more obvious gotchas I've mentioned above, and surely their current developer strategy, right? Cool, anyone happen to know what it is? Do me a quick favor, and google on "Apple Developer Strategy" or just click. Check out what shows up.

When you recover from the 1996-1998 linkage, you might try googling on other things from bits the first search turned up, like "Apple developer adoption program" or other things. Best of luck, but you may end up reaching the conclusion I have: Apple doesn't seem to really have a laid-out developer strategy, much like its M.I.A. security policies (tell me, how long will 10.3 have security updates when 10.4 is released? 10.2?).

So since we don't really have anything from Apple to go on, we're going to kinda have to infer:

  1. Use Cocoa as a competitive advantage for RAD development on the Mac. Theoretically this allows one to get cool shite™ up and running faster for complex apps, and gives Mac developers a competitive advantage over other platforms. Examples of this might be FinalCut Pro, iPhoto, iDVD, Motion, GarageBand, Keynote, OmniGraffle, Omniweb, etc.
Hrm. Ever notice that most of the larger Cocoa apps of any complexity are, well, made by Apple? Yeah, me too. Interesting, that. A lot of the 3rd party apps out there having massive investments in legacy code bases, and the opportunity-cost issue comes into play. And you also have the problem that if you're using Obj-C/Cocoa, you're pretty much tied to the Mac... if your app is of any significant size, this can be a pretty scary proposition. So they just use Metrowerks with C++ and the procedural APIs, aka Carbon. Yeah, it hardly ever feels "quite right", and the wonders of Cocoa RAD are pretty much out of the picture, but it gets the job done and your code can go between platforms fairly easily if you're careful. One could wonder who exactly reaps the lions' share of benefit from Cocoa: Apple or independent developers.
  1. Try to make it fairly easy to port from other platforms to the mac, but even that is fairly secondary. They'd really prefer you're writing mac-specific versions, but hey.
You'll most often see this with things like games, where a lot of the code is segmented out between the engine which is often in a procedural language, like C/C++ for speed. If the stars align, you can take the pieces, slap in some cocoa glue between them and you've got one hell of a turnaround time as far as ports go. That's the ideal. Unfortunately for things like games, this is getting a lot harder due to the rise of Microsoft's DirectX (that sucking sound was OpenGL's market share). Things are easier on the Unix/X11 front if you're talking about running them in an X11 window. But projects of really significant size or too heavily tied to another framework aren't a cakewalk to port over as native apps. Get back to me on this one when we've got NeoOffice.
  1. If there is a gap in the mac market, and Apple considers it strategically important, they'll step in and do it themselves if others don't. Well, and sometimes if others do, but Apple thinks they can do it better, they'll step in. Or if Apple just wants to have more direct control of that market. Well, ok, really anything is fair game. You've been warned.
We're not going to go too far into this, but there is a problem: while an open source chat client isn't necessarily going to stop what they're doing because of iChat, something like Trillian might very well think twice. This is actually a fairly recent development in Apple's M.O., and not something I'm necessarily against. But due to the size of their market one could make a case they're towing a dangerous line here, and its wigging some 3rd parties out.
  1. If Apple decides a specific market is strategically important, they aren't above acquiring some key companies and then making it... fiscally inconvenient to not buy the mac version unless you switch apps altogether.
*shivers* There are still some seriously pissed off Logic/Shake/etc users out there. I would have been too if MS had, say, 5 years ago bought Adobe and either discontinued their products for the mac or charged twice as much for the mac version... Yeah, lets not go here.
  1. Where possible, leverage OSS & Open standards by taking an existing project or technology, polishing it in some way or another and releasing it into the wild under a spiffy new code name.
These generally take two forms: fully open source with Apple-improvements, or a combination of OSS + proprietary Apple tech. Examples of the former would be Java & Rendezvous, while examples of the latter would be Safari (Apple's web browser based on the open-source KHTML engine) and Quartz-WM (Apple's X11 window manager, based on XFree) and, well, MacOSX itself.

Essentially, Apple's ideal is to have 3rd parties creating native high-quality software for the mac, preferably doing things you can't do on other platforms. While they've had decent success with a few of the "strategies" above, none of these seem to be making a dent in the problem we're talking about... and they've been in play for long enough that if they were going to do their thing they'd, well, I wouldn't be annoyed.

This isn't to say that there hasn't been massive value in what they've done, only that, in the context of this particular problem (switching users) has been a failure. Not a complete one, but I'm not really into lowering the bar when you don't make it.

Speaking of bars, that brings to mind an old adage that no one ever says unless they've had enough white russians in them because, well, it's kinda hard to pull off:

"When your opponent is holding all the aces, there's only one thing to do. Kick over the table."

When it comes down to it, Apple needs a disruptive technology in its developer strategy. Not better technology. Not cool technology. Disruptive technology. Apple hasn't really had a disruptive technology in awhile in any form until recently unless iTunes pans out. It's really been quite the drought, and it isn't helping much that google's handing out down the street basically handing out disruptive tech and business models like they're AOL CDs.

There's a reason why disruptive technologies are few & far between, created either by geniuses or someone who happened to be in the right place at the right time. They're often the dark horse in the night, and overlooked until *boom* it's obvious everything has changed. Since I'm neither a genius (I have iQ tests to prove it) and my personal history has shown I'm perpetually running late, I have no disruptive technologies to offer.

But its fair to say that doing the same thing over and over will result in the same outcome over and over, and Apple's current developer strategy is not going to change their current chicken & the egg problem. And the chicken and the egg problem leads us straight back to developers, as they are somewhat inversely proportional to users.

Basically, getting 5 developers onboard increases the value of the platform more than 5 users does. There's a reason why Ballmer was out on the stage screaming "Developers! Developers! Developers!", and while the sweaty video passed around on the web isn't exactly conducive to his argument, the message itself is pretty sound.

Since we've looked at the problem, and looked at what they're doing, it brings us to the crux of that matter: How do we get more developers on board? A lot of things are new on the developer front at the moment, so lets start at the beginning, or rather the last time Apple had a developer strategy.

Namely, Rhapsody.

Yep, hold onto your iPods, we're about to step into the Wayback Machine™ and go retro as hell.

Ahhh.... Rhapsody. Few words will instill loathing in an Apple developer more than that word. QuickdrawGX prolly comes close, and OpenDoc prolly qualifies. But Rhapsody left a very large chunk of Apple's developer base pretty damned pucker-mouthed.

Sure, I could rant about the poor developers who dropped $5k+ on tricked-out dually 200MHz 9600's to develop for OSX. But let's just put it this way: these developers dropped serious money down for kit in 1997 with the full expectation that they were going to be releasing software for the kick-ass new OS soon... the kick-ass OS that had a public beta in 2000, but was released in 2001, and was so immature that there was a free upgrade to 10.1 late in 2001, and was still so immature that most 3rd parties waited for 10.2.

But wait, you say, everyone has screw-ups. Stuff had to change, stuff came up, shite happens, and so on. Fair enough. But for a lot of the old timers, this was, it seemed, the last straw. Apple did have a sort of RDF while Jobs was gone, and were able to convince a lot of people to pour effort into various technologies that died on the vine. They'd been screwed on so many technologies, that Rhapsody was seriously starting to look like another Copland to the world. There's a reason why 10.0 was such a poor release, Apple had to get something out the door. People were literally starting to wonder if they'd ever ship. Again. Uncool.

You'd be well within your rights to ask why the hell I'm going on about this. Or, if you're the type of person who frequents my blog, why the hell I'm rehashing this. It's simply to reiterate just how badly some developers feel towards Apple. Apple has never, ever been considered to be a developer-friendly platform, quite the opposite really. Arrogance, and a feeling of deigning to allow you to develop for their platform come to mind... almost as though they considered it a privilege.

Developers had already been treated like cattle for Apple to herd as appropriate for ages, but the promise of Rhapsody was so strong that much of that was either chocked up to "Bygones" or "Thank you sir, may I have another". I'm not kidding. Mac OSX is cool. Rhapsody was insanely great™. The promise was so strong Apple saved almost $5 million a year in energy costs alone for several years by being able to turn down the dial on the RDF field. Rhapsody had developers for other platforms buying macs simply to use get in on it.

So what was Rhapsody, and why did it inspire such developer wood? Some people say it was a product, some people say it was a strategy, but really it was both. Back in that time, Apple was in... fairly dire straits as far as their OS was concerned. The writing had been on the wall for the Classic MacOS OS for years, and Apple had had failed attempt after failed attempt in creating it's successor, sometimes with some very large partners who they're still working with.

Operating systems were entering a new phase: new world & old world, modern & quaint. A line had been drawn in the sand between what constituted a "modern" OS, and what didn't. This was the time of Microsofts WindowsNT and IBMs OS2/Warp, and Apple desperately needed to be able to haven an OS that could be lumped in the modern category.

It's current OS was exceedingly long in the tooth, and while it had served Apple very well (and still continues to serve millions of people well), it was very much entering the Elizabeth Taylor era of it's life. With enough surgeries it looked ok, and sure it stood up and looked around every once in awhile, but it didn't seem to always know where it was.

It's current effort at the time was Copland, and it was an abysmal failure. My impression is that this wasn't due to the quality of the coders or in-house talent, but rather the technical demands placed upon them in creating the new kernel. Either way, it can't be stressed enough just how badly, and publicly, this project crashed & burned. As an example, some are asking if Longhorn is Microsoft's Copland. Ouch. You really don't want your project entering the tech lexicon once many have forgotten what it originally was. Even worse, the failure of Copland was coming on a series of them.

At this point, Apple didn't really have any confidence in the OS coming from within, so had to look outside. Apple had several different options, including, but prolly not limited to:

  • WindowsNT
    Basing the MacOS on the WindowsNT kernel, which they would license from Microsoft. This seems completely brain dead now, and I'm sure some new kids on the block think I'm making this up. But this was a different time, and Microsoft had ported WindowsNT to PowerPC, specifically the CHRP platform (which seems to be getting new life from IBM lately).

    I don't recall why this one didn't go through, as things were in such dire straights that the mac faithful would have rationalized this somehow. I was ready to.


  • Be
    There was this uber-cool, technically-advanced OS called Be that existed for the PowerPC and was created by an ex-Apple exec who was known for his delusions of grandeur being a bit "high strung". Be was pretty damn unique, and arguably the shizzat of OSs on the market.

    Outside of the Amiga, this was an OS born with multimedia in mind from the start. It was also one of the few modern OSs built from scratch (this is hard), and deserves its due. I could go on for ages about what put Be into the damn cool shite™ category, and Apple heavily considered buying Be. Next to NeXT, it was prolly it's most promising options if you assume pride was a factor.

    This deal died because of some demands by the owner who seemed to be caught up in some irrational exuberance, and the fact that Be was very immature for Apple's needs. This "immaturity" may have been somewhat exaggerated in the hoopla surrounding the choice they did end up going with, but there's no denying Apple's core market (well, it was then) was going to need to, um, print.


  • OS9 Reloaded
    Well, refactored. There was the option of "back-porting" several of the most direly-needed "expected modern OS features" to OS9, namely protected and memory and preemptive multitasking.

    This would have been incredibly painful and a glued-together hack job, but it was theoretically possible. Luckily, this was shelved, although due to delays in Rhapsody some of this did take place, like a multi-threaded finder (which, I swear to god, we might have again in 10.5).


  • Linux
    Apple had been playing a tad with Linux for awhile, there was even something called MKLinux that ran on PPC. They'd also experimented with AU/X. But the Linux of 2004 is not the Linux of '95 or '96, and the amount of work it would haven to get it to where it is now, for one company, was more than a little daunting.

    Still, taking Linux and adding everything to it that Apple would need just didn't feel like an option. You also had the fact that the GNU was still somewhat in its infancy as far as companies were concerned, and the BSD license was considered a lot more corporation-friendly.


  • NeXT
    When Jobs had left Apple, he went on to create a new computer company that arguably engendered the most hype ever to befall a computer launch: NeXT. I could go on and on about NeXT too, and it deserves every kudo you could throw at it.

    In all honesty, the history of NeXT is worth a read if for no other reason than to hear some of Ross Perot's juicy quips or some of Larry Ellison's statements from the time. Or on just how much their logo cost. I love that stuff.

    Long story short, NeXT was very Apple-like, in that they had both an OS and hardware. The hardware, while insanely great for it's time, died. NeXT transitioned to standard x86 boxen, and proceeded to create OpenStep. More on that later. It was Unix-based, which meant it was kinda the Linux route but with a huge leg up. Suffice to say, NeXT bought Apple Apple bought NeXT for $400 million, and proceeded to get started on their next-gen OS: Rhapsody.


  • The Amiga
    This wasn't really an option, but I swear to god I heard it proposed. Sad, sad Amiga.

The early days of the transition to Mac OSX were rough. Really, really rough. There are better places for a more accurate blow-by-blow for what happened, but the strategy was basically this:

  1. Port NeXT's OS to PowerPC
  2. Slap a Classic "platinum" MacOS interface on top of it
  3. Make NeXT's APIs (application programming interface, these are routines developers call to say, make a new window) the new standard, with the old crusty MacOS routines being put out to pasture. These were the YellowBox APIs.
  4. Run the Classic Mac OS as a separate process from with Rhapsody, so that people were able to run their run their current applications in a separate window, similar to VirtualPC. This was the BlueBox.
  5. Pray.

But wait, there's more!

NeXT had already dropped its hardware, and when Apple bought them was running on X86, using an interesting strategy: They sold an OS, and they ported their application frameworks to several OSs, allowing one to create an application on their box running NeXTs Openstep, press a button and have one for WindowsNT or Solaris come out.

You could even do things like Quad-binaries, or dual-binaries, which was somewhat similar to what Apple did with their 68k to PPC transition. What looks like one application to the user, but actually has two separate code bases inside it.

Apple now already had an OS that ran on X86, because Openstep did and really they were porting from x86 to PPC. They also had the same ability that NeXT had for cross-platform development. The idea was to ship Rhapsody for both PowerPC and x86 hardware, which Apple might themselves release. This would have meant that if Apple had two different types of CPUs on the market, a developer could hand you a dual-binary app that would load the x86 code if you had a pentium inside, and the PPC code if you had a PowerPC inside. This also meant that the developer could spit out an app that they could hand to a WindowsNT user and they could use it natively. This was basically the "Yellow Box".

It both went very well and very poorly, and Rhapsody (Mac OSX) was so delayed it engendered class-action lawsuits). But it did ship, just on a timetable that prolly would have allowed them to take any of the other options and do it in the same amount of time.

Several things happened:


  • They had a full-scale revolt from some of their largest 3rd party developers. Most developers were in awe of what Rhapsody was going to bring, but some of these developers had been burned too many times. The current Rhapsody strategy would have caused them to have to rewrite their entire apps to have them run natively.

    The mac's share of the market was already having problems, and there was a full-blown onslaught from WindowsNT on some of their core markets... and Adobe, Quark, etc just really weren't loving the idea of having to rewrite their massive codebases for an unproven OS that was seemed in no hurry to ship. Because OS8 and OS9 weren't going to go away over night, they'd have to support three code bases: Windows, and two code bases for a minority OS. But wait, you say, they'd only have to support one and let the other die? Theoretically, but no one was counting on that.


  • I mentioned the Classic MacOS would be able to run as a separate process, but within its own window. This was called "the Blue Box". Users really, really weren't digging this, primarily because 99% of the apps they'd be running would be running in this compatibility window.

  • Windows95 had morphed into Windows98, and had arguably eroded even more of the day-to-day differences between it and the MacOS interface, including things like plug-and-play and wizards galore. You also had the problem of true preemptive multitasking OS not leaning itself to an interface that wasn't designed for one... The MacOS interface was starting to look decidedly unsexy, and even, dare-i-say-it, globbed together and long in the tooth.

In order to deal with these, several things occurred:


  • The first, or Yellow Box, was handled with Carbon, which was a huge, huge deal: They took the old MacOS APIs, ripped out a chunk that were just way too crufty to consider bringing over with an OS like MacOS, and ported them. Apple's line was that developers would only have to change 10% of their code on average to have a working app. This of course ended up being a tiny bit to some, and a big deal to others... but either way it was kind of a load. Sure, they'd run, but they'd run like crap as developers soon found out. Some of them haven't, which is why we still have the occasional Carbon app using CPU while idle because it is constantly polling.

  • The second, or Blue Box, was solved via the Classic environment, which was distinguished because the separate window idea was abolished but apps instead ran as though they were dated-looking regular apps. This hurt compatibility a bit, but really helped the whole experience.

  • The 3rd was handled with Aqua & Quartz, which arguably did more to harm the speed perception of current macs more than any MHz problems could begin to. Don't get me wrong, I love Aqua, but there's no arguing that Aqua is tomorrow's tech shoved onto yesterday's hardware.

But Apple did actually ship two releases of Rhapsody, both DC1 & DC2 in 1998.

Rhapsody DC2 was the last version of Mac OSX to run on X86 hardware, but that feature was axed later and made PowerPC only.

The cross-platform frameworks were similarly axed, meaning while you still got the frameworks, you weren't going to be handing your app to someone on Windows and having it run.

Some people weren't completely surprised.... Rhapsody DC2 had engendered a lot of excitement, but really the entire OS was so delayed at this point, and had already been repositioned with new life being breathed into the Classic MacOS that people were wondering if anything would ever ship... and there were other signs of problems, what with takeover rumors and the CHRP platform.

When MacOS X shipped, people had an arguable case as to whether Apple had made the right choice with NeXT. Everything was just so... incomplete. And rough. And slooooow.

They most certainly did make the right choice. Part of me still wishes they would have bought Be, Inc. a few years ago, if only so Palm didn't end up picking it up for $40 million and a twinkie. The big things Apple got from NeXt that are applicable to what we're talking about are:


  • *nix environment
    You'd be hard pressed to say this hasn't been used effectively by Apple, as illustrated by the backend, scripting & traditional unix guys I mentioned earlier who have gotten very interested. Sure, there are things they could be doing... but it's brought tremendous value to the OS that arguably wouldn't have been there with some of the alternatives. I know this is what kept me: I had a seriously wandering eye there for awhile, and it just so happened that having #!/bin/sh and ssh -2 that I can access through a native terminal shell went way up on my priority list. I see guys carrying around Powerbooks & iBooks at various groups that wouldn't have looked at them if it didn't.

  • Openstep Frameworks
    Well, we have Cocoa, or the Cocoa Frameworks, which is essentially what the "Yellow Box" was supposed to be, minus anything cross-platform. None of the real value inherent to a developer as far as using Cocoa has been removed, you still get a great RAD environment for prototyping your software, interfaces, what-have-you. But it's on Apple's hardware alone, which goes back to the chicken & the egg problem, and it should be obvious as to where I'm heading with this.

No, I'm not advocating for Mac OSX on x86 hardware, that's a whole separate issue and there's an obvious fear there that it would just destroy Apple's hardware market if they shipped it for generic x86 as planned. It's actually a very valid argument, as I've found the next laptop I want right now and it's not made by Apple (it does, however have a 2GHz+ AMD64, higher-rez screen and every goody I'd want for $1k less...), as Apple only competes in 1" thick laptops. Apple just isn't making what I want, but I'd like to run Mac OSX... I can't be the only one, and I'd have to think lots of us would raid their hardware sales something fierce.

What I'm throwing out there, after talking to a lot of developers, is that they bring back one aspect of it: the ability to port your app, with a minimum of fuss, to other platforms by choosing to use Apples Development tools and OSX (hence, mac hardware) as your development platform.

Depending on who you ask, Java has 1 to 4 million developers programming for it, so we'll assume 2.5. I know guys who develop for Java on their powerbooks, even though 99% of their userbase is on x86 and Solaris. They have like literally less than 5 mac customers using Xserves. This brings 3 things to mind:


  • This isn't a native MacOS X app, refactored into a cocoa codebase, yet Apple has sold at least 3 Powerbooks to these guys (one still uses an IBM thinkpad) simply because they support Java. Without Java's cross-platform capabilities, that's 3 Powerbooks that wouldn't have been sold. There's benefit there.

  • Their app, while Java and can theoretically run anywhere, is fairly complex and they do need to "certify" platforms before they deploy as there is some platform-specific stuff that needs to be done. They would have been in the "if enough people ask, we'll look at it" situation.

  • Their app is pretty darned polished for a sub-5 userbase, simply because they've noticed lots of little things because it's what they're developing on. It's a lot faster and less buggy than it would have been otherwise.

  • If Apple can get 1% of the ~2.5 million out there, you're talking 25,000 developers buying machines of some form, as well as the other things associated with having the apps they do make being made on the platform

I don't want to even guess about what would happen if you ran that number with Microsoft's developer share, so I won't, but you get the idea. There's also the case of Acme Co I mentioned earlier, who was in a development transition point and interested in a Linux version and a Mac version, but the opportunity cost was just too high. Java just isn't an option for them for several reasons, but in running it by them and some others... if they could develop on Mac OSX with their beautiful frameworks and support Mac, Linux and Windows with a minimum of per-platform hassle, you'd really, really have something.

Oh, yeah, Linux.

That's kinda important, as the market hasn't exactly stood still over the last 5 years. We're going to be somewhat cursory about this, but suffice to say, Linux is at another interesting transition point: the desktop. They've already made the leap from hobby OS to credible OS to essentially dominating the server space and some companies with a lot of weight behind them are working to have it eat its way up on the low end of the desktop.

Linux at this point can't be ignored, it's somewhat viral. Sure, your market just might have a slight cough at the moment, but soon you'll be coughing up a lung and really wishing you'd made that doctors appointment. I'm looking at you, Sun.

There are several ways to developer for Linux at the moment, but for desktop apps there are essentially two competing "desktop environments" at the front of the pack:


It'd be really easy to get into a pissing match here about the various merits of each, but that's a whole other can of worms. Instead, lets look at the licenses:

  • Gnome is free as in beer. You can download and hack the source, and basically do whatever the hell you want as long as you follow the GNU license.

  • KDE isn't free, unless you use it for free things. You can essentially develop for KDE for free, as long as your app is for free. If you want to charge for your app, you have to pay KDE.

  • History tells us that when it comes to technology, the markets are like water and tend to go towards the path of least resistance. IE, if you were a betting man, you'd bet that Gnome is going to win the desktop, and KDE is going to end up moving into some sort of niche. Probably a high-end development environment for Gnome (and possibly other) desktops.

No, this isn't going to be tomorrow, but it's going to happen. KDE sees something on the wall with this. Why, exactly, do you think KDE is working so hard to port their frameworks over to OSX? Do you think they have a completely altruistic reason (well, not saying they're doing it for a bad reason) for KOffice running on OSX?

In other words, KDE is very much taking a play from the Openstep playbook here, and if Apple doesn't watch it their Yellowbox ace-up-their-sleeve is about to be rendered scarily redundant. Apple needs to wise up to this, as I certainly doubt the idea of a developer realizing they can just pay KDE and get Linux, Windows & Mac OSX for free, which is of course what KDE wants.

This can't be stressed enough: Apple may not have to choose a "desktop environment" to back, but the frameworks need to be ported to Linux eventually, and the sooner the better. Apple can either do it now, while they can still heavily influence the direction of the Linux stampede, or they can do it after it's passed and they're desperate and all that's left are the droppings from the herd.

Linux isn't the only area in a transition at the moment, the windows developer base is currently in the throws of .NET & C#. Most people are inherently confused about what .NET still is, which is primarily Microsoft's fault due to some really lousy all-inclusive marketing at the beginning.

If you go beyond web services or other things, to a windows developer, .NET is the .NET frameworks which interface with a CLR, or common language runtime. The easiest way to think of a CLR is to imagine Java's JVM (virtual machine) which allows you to write the java code, and then run it on any machine with a JVM installed. It's very close to the same thing, except it's not emulated, so the performance hit is a small fraction of what you get with something like Java. The .NET frameworks are a set of object-oriented APIs that can be called on through a ton of different syntaxes.

I.E., if you can use VisualBasic.NET, C#, Fortran, lord there are a ton, and they're pervasive. If you choose to VB instead of C# (well, and don't write as though you're not using an OO syntax now) your stuff just looks uglier and its a bit harder to scale the code than if you use C#. Well, and less fun. They haven't included Java syntax yet, as that'd prolly be a whole lawsuit in the making... I'm being cursory again, as there are other features and the like, but that's not important to this.

And yes, I'm well aware that I've pretty much just described the "Yellow Box", except that the what the different languages can access have better support for them in the APIs, and the fact that it isn't cross-platform, and you're tied to Windows. But that doesn't mean the CLR is going to stay on one platform... the CLR gives Microsoft enormous freedom between platforms, if they choose to use it.

...which brings us to C#, another big transition point in the windows world. The transition of thousands of code bases from VB6.0 to VB.NET and C# is prolly going to be on the scale of Y2K transition over the next 5 to 10 years. This thing is huge, especially for in-house applications (primarily corporate).

Companies & developers are sitting around realizing they need to move to .NET, and are trying to figure out the pros & cons. It's pretty much going to happen, but they are often having to weigh VB.NET versus C#. It's often not as easy as it sounds, as while the syntax is much the same between VB & VB.NET, that's about it. How you write the applications needs to completely change, or you are screwing yourself. Some people are learning this the hard way, by moving to .NET thinking they'll save time and then realizing they really can't write code in the same way they were.

Long and short of it, the transition isn't going to be painless, and in technology where there's pain there's opportunity. People are sticking their heads up and looking around. More than a year ago I was walking around seeing VB developers carrying C# books around to the coffee shop, not because they were having to use it, but because they believe they're going to and scarily enough... they like it.

But they're not able to use it on OSX, and that's prolly going to have to change, sooner rather than later. Of course, they could always just use Linux...

Yeah, you heard me, Linux. No matter how anti-MS you are, you have to get this through your hard. C# doesn't suck. The .NET frameworks don't suck. You can nitpick on them, or find things here and there, but by and large developers like them. Enough so that not only has the Mono project gone from pariah to greek-cred to momentum in fairly short order. And Mono is basically C# and .NET ported to Linux.

Ayup, geeks like it that much. It's not 100% just yet, but it's getting some big backers, like Novell. It's basically been split into two different stacks, an independent stack for those who want to write Linux apps .NET style and C#, and those who want an easier way for moving their Windows apps to Linux. Ayup, moving their Windows apps to Linux.

In other words, while Mono isn't making it a straight compile for .NET developers on Windows to get their apps over to Linux, you can see where it's heading. Apple needs to move on this yesterday. The value is in the frameworks, not Obj-C.

In all fairness, I'm sure I'm missing some things and there are some obvious problems to what I'm proposing (and possibly already have, I've just not heard good answers) that would need to be worked out by brains larger than mine. Luckily, those are pretty numerous...

So lets go through some of them:

  1. Loss of hardware sales
    You obviously have the danger of say, whipping up the next killer in the Cocoa frameworks and people finding that other platforms just run it faster/better cheaper. Hence, since they don't have to buy a mac to get it, Apple could lose hardware sales.

No real good answer here, but I'll admit I'm the type of person who looks at things like the iBooks with their intentionally crippled video and just gets annoyed. I like competition. Compete, damnit. Hot buttered jesus that irks me.

Here's the thing. One of the fun parts of using an alternative platform is getting to say, "Sorry, you can only do that if you use a...". The worst part is having to say "Sorry, they don't make that for...". I swear to gawd that first one is a granny-smith flavored hit of heroin to the cerebral cortex of your bleed-six-colors mac user, and not something they like to give up lightly. In this case, we might have to give up some of the highs to get rid of some of the lows. Prozac.

  1. The Carbon conundrum
    I mentioned the Carbon layer before... unfortunately that could throw a big wrench in the works. Carbon or Cocoa isn't an all or nothing thing, now, which is also something I mentioned. If you're using Cocoa, specifically, there are lots of things you can't reach without making Carbon calls, and lots of Cocoa calls you do make are actually just wrappers for Carbon calls. This was a good thing at the time, lots of developers were actually worried Carbon was a quick stop-gap and was going to get dropped. But integrating it into everything, it made it obvious that it's here to stay.

    Carbon is C/C++, and as such fairly portable. I get that, but what about things like the code fragment manager (CFM) that a lot of carbon apps seems to use? As it is now my understanding is that these are direct PPC calls that are translated by OSX as, well, it doesn't generally give apps that kind of access anymore (and pushes towards mach-o). Stuff like the CFM would seem to have to be rewritten if you wanted photoshop/office running on x86, or emulated. Emulation isn't a good word, but in the case of not wanting your stuff to run faster on other processors might be...

I know carbon apps can go to mach-o, and some have done so, but I don't really have a handle on how big of an undertaking it'd be for a large (or small) application. I'll have to look into that. But Carbon may well have made things a lot more difficult than they once were.

  1. Cost
    Apple isn't above recalling an old warhorse from the stable, witness Ink, from the newton days. However most who have played with Ink realize that it hasn't seen much improvement since the newton days either, and this probably wouldn't fly with what we're talking about. The windows platform hasn't stood still, and neither has Linux. There's going to be a lot of work there, even if they just ignore things like DX9.

If Apple went cross-platform again with their libraries, and it was going to be a very large investment, I'd have to think there'd have to be something that could be worked out to bring in some cash, such as giving the full-featured dev tools away for free, and charging $1k+ to any developer wanting to use Xcode Extreme to press a button and have it run on 4 platforms... free academic use, and of course, tiered structures so the mac coders at adobe don't piss themselves as they watch their jobs evaporate.

  1. ...like butter spread across too much toast
    Arguably, Apple is spread very, very thin across the board. You can get a sense of this when you look at how many developers work on various projects, and how many of their developers and industrial designers "hop", IE get one version out of one app/hardware, then move onto another app, then move back. Apple has to wear a lot of different hats w/OSX: keeping gcc in sync with obj-c, improving obj-c, improving ppc gcc's performance, improving the cocoa frameworks while also improving and merging with the cocoa frameworks, improving the kernel & userland... ad infineum.

I don't really have a good answer for this one, and it's probably somewhat related to the cost issue above. Ideally I'd like to think that some of this being spread very thin thing was part of their uber retrenchment strategy, and it's time to climb out of the trenches and make some real waves.

To wrap up...

I may sound convinced, but I'm really not. I'm very much keeping an open mind, but also realize things aren't working as they are. This type of topic is also in the "Mac OSX on X86" or "Free Trade" territory, in that it just seems to scare the hell out of some people and engenders a visceral knee-jerk reaction.

I guess that's fairly normal, as while anyone whose read a pamphlet on economics knows protectionism is bad for the economy & industry as a whole, that's left-brain thinking. And when you're in the thick of it, or it directly affects you, the left brain is generally the first to leave a note on the pillow that its taking a leave of absence.

Speaking of absence, you'll notice I haven't mentioned the perennial favorite of mac heads everywhere to the software conundrum: some form of VirtualPC-ish software that doesn't run the apps in a window, but rather an environment similar to Classic or X11... transparently, just another application in the dock. It wasn't mentioned because I don't think things like that are really the answer. Mac users are a fickle lot, and MHz are still a precious commodity in the Mac world.

Besides, when you are paying as much as you do for a piece of Apple kit, having to make do with sloppy seconds is... distasteful.

--------
Update 2004.05.03:
Please see corrections and clarifications here.
--------

yummy alcohol posted button Posted by drunkenbatman
    April 30, 2004, at 04:28 PM


Comments (126)




Post a comment



Anonymous comments are allowed, but please enter something for a name.

And do endeavor to appear sane.









Remember personal info?