A bunch of my friends, particularly on the F/OSS and Android side, are issuing a new call to the barricades to make the case that APIs should not be copyrightable. In particular, the EFF wants developers to send in stories of how they’ve reimplemented APIs for reasons of competition, interoperability, innovation, etc. The issue is heating up again because a three-judge Federal Circuit panel is going to revisit Judge Aslip’s ruling in Oracle v. Google, where the jury found that Google willfully infringed Oracle’s copyright on the Java APIs, but the Judge found that APIs aren’t copyrightable in the first place, rendering the jury decision moot.
This isn’t the slam dunk some people think it is. During the trial, Florian Mueller pulled up relevant case law to show that copyright has traditionally considered the design of computer code (and, implicitly, its public interfaces) to be protected.
Furthermore, the case against copyrightability of APIs strikes me as quite weak. If software deserves copyright at all — and there are good arguments against it, but that’s not what we’re talking about here — then drawing the line at published interfaces doesn’t hold up.
There are basically two arguments I’ve heard against API copyrightability. Here’s why I think they’re bunk:
Somewhere between the Happily Ever After and the Downer Ending, the Bittersweet Ending happens when victory came at a harsh price, when, for whatever reason, the heroes cannot fully enjoy the reward of their actions, when some irrevocable loss has happened during the course of the events, and nothing will ever be the same again.
So, Apple wins big in their patent case against Samsung, and reactions are pretty much not what you’d expect. While the Fandroids console themselves with a straw-man claim that “Apple patented rounded rectangles”, writers in iOS circles are hardly delighted. Pre-verdict, Matt Drance wrote “However the verdict falls, I feel like there are no winners here in the long term — certainly not us.” And a day after the verdict, John Gruber’s Daring Fireball hasn’t even mentioned the outcome.
Matt’s concern is giving Apple too much power to control the market, and the verdict likely does that. Following along with The Verge’s liveblog, I noticed that a few devices were found as non-infringing. That’s got to be even worse news for Samsung and Google, because the jury is effectively saying that it is possible to make smartphones without copying Apple, and Samsung largely (and willfully) chose not to. Combine this with the speed at which they reached their conclusions and it’s utterly damning.
And yet, on the other hand, what we’re discussing is patents like “slide to unlock”, which many/most of us think is unworthy of patentability in the first place. And that’s what makes this so uncomfortable: Android’s and particularly Samsung’s copying of Apple was egregious and shameless, but since that itself is not illegal (and how could you even codify that as law?), then does settling for a victory over stuff that probably shouldn’t even be patentable count as a victory at all? Making things worse, the jury had the option of invalidating patents on both sides, and declined to do so on every count.
Then again, what do I know? I thought ripping off the Java programming language and practically the entire API of Java SE was a lot worse, but the court said that was OK. So I guess stealing is bad, except when it’s not.
Let me introduce you to the “Whiny Little Bitch Contingent”. This was a term I coined in the late 2000′s to cover the Java developers who cried and moaned about the slow decline in Apple’s support for Java: the deprecation of the Cocoa-Java bridge, the long wait for Java 6 on Mac OS X, its absence from iOS, etc. Every time there was news on this front, they could be reliably counted on to dredge up Steve Jobs’ pledge at the JavaOne 2000 keynote to make the Mac the best Java programming environment… and to bring this up in seeming ignorance of the passage of many years, the changes in the tech world, the abject failure of Desktop Java, other companies’ broken promises (Sony’s pledge of Java on the PlayStation 2, the Java-based Phantom gaming console), etc.
The obvious trait of the Whiny Little Bitch Contingent is their sense of entitlement: companies like Apple owe us stuff. The more subtle trait is their ignorance of the basic principle that people, organizations, and companies largely operate in their own self-interest. Apple got interested in Java when it seemed like a promising way to write Mac apps (or, a promising way to get developers to write Mac apps). When that failed, they had understandably little interest in providing developers a means of writing apps for other platforms. I’m sure I’m not the only person to write a Java webapp on the Mac that I knew my employer would block Mac clients from actually using. By 2008, when Apple entered the mobile market with the iPhone, there was nothing about supporting Java that would appeal to Apple’s self-interest, outside of a small number of hardware sales to Java developers.
That’s what defines the WLBC to me: sense of entitlement, and an igorance of other parties’ self-interest (which leads to an expectation of charity and thus the sense of entitlement).
So, yesterday, Apple holds an event to roll out their whole big deal with Textbooks on the iPad. They look pretty, they’ve got an economic model that may make some sense for publishers (i.e., it may be in the publishers’ self-interest), etc. Also, there’s a tool for creating textbooks in Apple’s format.
And this is where the Whiny Little Bitch Contingent goes ape-shit. Because there’s a clause in the iBooks Author EULA that says if you’re going to charge for your books, you can only publish to Apple’s iBookstore.
So, let’s back up a second. The only point of this software is to feed Apple’s content chain. The only reason it is being offered, free, is to lure authors and publishers to use Apple’s stuff… which in turn sells more iPads and gives Apple a 30% cut. If you are not going to put stuff on Apple’s store, why do you even care about this? Hell, I don’t develop for Microsoft’s platforms, so if they see the need to turn Visual Studio into an adventure game… hey that’s their problem.
If you’re not authoring for Apple’s iBookstore, why do you even care what iBooks Author does, or what’s in its EULA?
In decrying the “cold cynicism” of Apple’s iBook EULA, Marshall Kirkpatrick writes:
It’s hard to wrap my brain around the cold cynicism of Apple’s releasing a new tool to democratize the publishing of eBooks today, only to include in the tool’s terms and conditions a prohibition against selling those books anywhere but through Apple’s own bookstore
“Democratize the publishing of eBooks”? Where the hell did he get that? Maybe he watched the video and fell for the grandiosity and puffery… I never actually watch these Apple dog-and-pony shows anymore, as following the Twitter discussion seems to give me the info I need. But thinking that Apple is in the business of democratizing anything is nuts: they’re in the business of selling stuff, and the only reason they’d give out a free tool is to get you to help them sell more of that stuff.
I didn’t download iBooks Author, even though you’d expect an Apple-skewing author like me to be one of the first onboard. Frankly, I’m pretty tired of writing, as the last two books have been difficult experiences, and the thought of starting another book, even with a 70% royalty instead of 5%, is not that appealing. A year ago I thought about self-publishing a book on AV Foundation, but right now I lack the will (also, I’ve failed to fall in love with AV Foundation, and blanch at its presumptions, limitations, and lack of extensibility… I much prefer the wild and wooly QuickTime or Core Audio).
So, if we’re going to talk about iBooks Author, let me know how it holds up for long documents: if it’s pretty on page 1, is it still usable when you’re 200 pages in? Does it offer useful tools for managing huge numbers of assets? Does it provide its own revision system and change tracking, or does it at least play nicely with Subversion and Git? Can it be used in a collaborative environment? These are interesting questions, at least to people who plan to use the tool to publish books on the iBookstore.
But if Apple’s not giving you a pretty, free tool you can use to write
.mobi files that Amazon can sell Kindles with? Sorry, Whiny Little Bitch Contingent, I’ve got zero sympathy for you there. Call it a third party opportunity. Or just put on your big boy underwear and do it yourself.
Take it, Geddy:
You don’t get something for nothing
You can’t have freedom for free
You won’t get wise
With the sleep still in your eyes
No matter what your dreams might be
As mentioned before, I’m not a big fan of panels at developer conferences, and whenever I’m in one, I deliberately look for points of contention or disagreement, so that we don’t end up as a bunch of nodding heads who all toe a party line. Still, at last week’s CocoaConf in Raleigh, I may have outdone myself.
When an iOS developer in the audience asked if he should get into Mac development, most of the panel said “go for it”, but I said “don’t bother: the Mac is going to be gone in 5-10 years. And what’s going to kill it is iOS.”
This is wrong, but not for the reason I’ll initally be accused of.
First, am I overstating it? Not in the least. Just looking at things where they stand today, and the general trends in computing, I can’t see the Mac disappearing in less than five years, but I also can’t imagine it prevailing more than another 10.
This isn’t the first time I’ve put an unpopular prediction out there: in 2005, back when I was with O’Reilly and right after the Intel transition announcement, I I predicted that Mac OS X 10.6 would come out in 2010 and be Intel-only. This was called “questionable”, “dumb”, and “ridiculous advice”. Readers said I had fooled myself, claimed I was recommending never upgrading because something better is always coming (ie, a straw man argument), argued Intel wouldn’t be that big a deal, and predicted that PPC machines would still be at least as common as Intel when 10.6 came out. For the record, 10.6 came out in August, 2009 and was indeed Intel-only. Also, Intel Macs had already displaced PowerPC in the installed base by 2008.
So, before you tell me I’m an idiot, keep in mind that I’ve been told that lots of times before.
Still, punditry has been in the “Mac is doomed” prediction business for 20 years now… so why am I getting on board now?
Well, the fact that I’m writing this blog on my iPad is a start. And the fact that I never take my MacBook when I travel anymore, just the iPad. And the issue that Lion sucks and is ruining so much of what’s valuable about the Mac. But that’s all subjective. Let’s look at facts and trends.
iOS Devices are Massively Outselling Mac OS X
One easy place to go for numbers is Apple’s latest financial reports. For the quarter that ended Sept. 30, 2011 (4Q by Apple’s financial calendar), the company sold 4.89 million Macs, 11.12 million iPads, and 17.07 million iPhones. That means the iPad is outselling all models of Mac by a factor of more than 2 to 1.
The numbers also mean that iOS devices are outselling Mac OS X devices by a ratio of at least 5.7 to 1… and it must be much more, since Apple also sold 6.62 million iPods (since these aren’t broken down by model, we don’t know which are iOS devices and which aren’t).
While the Mac is growing, iOS is growing much faster, so this gap is only going to continue to grow.
Let’s also think about just which Macs are selling. The answer is obvious: laptops. The Mac Unit Sales chart in this April 2011 MacWorld article shows Apple laptops outselling desktops by a factor of nearly 3-to-1 for the last few quarters. Things are so cold for desktops that there is open speculation about whether the Mac Pro will ever be updated, or if it is destined to go the way of the Xserve.
Now consider: Apple has a whole OS built around mobility, and it’s not Mac OS X. If the market is stating a clear preference for mobile devices, iOS suits that better than the Mac, and the number of buyers who prefer a traditional desktop (and thus the traditional desktop OS) are dwindling.
Replace That Laptop!
Despite the fact that it’s only about 28% of Apple laptop sales, I would argue the definitive Mac laptop at this point is the MacBook Air. It’s the most affordable MacBook, and has gotten more promotion this year than any other Mac (when was the last time you saw an iMac ad?). It also epitomizes Apple’s focus on thinness, lightness, and long battery life.
But on any of these points, does it come out ahead of an iPad 2? It does not. And it costs twice as much. The primary technical advantage of the Air over the iPad 2 are CPU power, RAM, and storage.
Is there $500 worth of win in having bigger SSD options or a faster CPU?
Few People Need Trucks…
“But”, you’re saying, “I can do real work on a Mac”. Definitely true… but how much of it can you really not do on an iPad? For last month’s Voices That Matter conference, I wrote slides for two talks while on the road, using Keynote, OmniGraffle, and Textastic… the same as I would have used on my Mac Pro, except for using Xcode to work with code instead of Textastic. I also delivered the talk via Keynote off the iPad with the VGA cable, and ran the demos via the default mirroring over the cable.
I’ve gone three straight trips without the laptop and really haven’t missed it. And I’m not the only one. Technologizer’s Harry McCracken posted a piece the other week on How the iPad 2 Became My Favorite Computer.
Personally, the only thing that I think I’m really missing on my iPad is Xcode, so that I could develop on the road. I suspect we’ll actually see an Xcode for iPad someday… the Xcode 4 UI changes and its single-window model made the app much more compatible with iPad UI conventions (the hide-and-show panes could become popovers, for example). And lest you argue the iPad isn’t up to the challenge, keep in mind that when Xcode 1.0 was first released in Fall, 2003, a top-of-the-line Power Mac G5 had a dual-core 2.0GHz CPU and 512 MB RAM, whereas the current iPad 2 has a dual-core A5 running at 1.0GHz and 512 MB RAM, meaning iPad is already in the ballpark.
…and Nobody Needs a Bad Truck
“But Mac OS X is a real OS,” someone argues. Sure, but two things:
How much does that matter – a “real OS” means what? Access to a file system instead of having everything adjudicated by apps? I’d say that’s a defining difference, maybe the most important one. But it matters a lot less than we might think. Most files are only used in the context of one application, and many applications make their persistence mechanism opaque. If your mail was stored in flat files or a database, how would you know? How often do you really need or want the Finder? With a few exceptions, the idea of apps as the focus of our attention has worked quite well.
For how long will Mac OS X be a “real OS”? – Anyone who follows me on Twitter knows I don’t like Lion. And much of what I don’t like about it is the ham-handed way iOS concepts have been shoehorned into the Mac, making for a good marketing message but a lousy user experience. Some of it is just misguided, like the impractical and forgettable LaunchPad.
But there’s a lot of concern about the Mac App Store, and the limitations being put on apps sold through the MAS. This starts with sandboxing, which makes it difficult or impossible for applications to damage one another or the system as a whole. As Andy Ihnatko pointed out, this utterly emasculates AppleScript and Automator. Daniel Steinberg, in his “Mac for iOS Programmers” talk at CocoaConf, also wondered aloud if inter-application communication via the
NSDistributedNotificationCenterwill be the next thing to go. And plenty of developers fear that in time, Apple will prohibit third-party software installs outside of the MAS.
Steve Jobs once made a useful analogy that many people need cars and only a few need trucks, implying that the traditional PC as we’ve known it is a “truck”, useful to those with advanced or specific needs. And that would be fine… if they were willing to let the Mac continue to be the best truck. But instead, the creep of inappropriate iPad-isms and the iOS-like limitations being put on Mac apps are encroaching the advanced abilities that make the truck worth owning in the first place.
The Weight of the Evidence
Summarizing these arguments:
- iOS devices are far outselling Mac OS X, and the gulf is growing
- The iPad and the MacBook (the only Mac that matters) are converging on the same place on the product diagram: an ultra-light portable computing device with long battery life
- iOS is already capable of doing nearly anything that Mac OS X can do, and keeps getting better.
- Mac OS X shows signs of becoming less capable, through deliberate crippling of applications by the OS.
Taken together, the trends seem to me like they argue against the future of Mac OS X. Of the things that matter to most people, iOS generally does them better, and the few things the Mac does better seem like they’re being actively subverted.
Some people say the two platforms will merge. That’s certainly an interesting possibility. Imagine, say, an iOS laptop that’s just an iPad in a clamshell with a hardware keyboard, likely still cheaper than the Air, and the case for the MacBook gets weaker still.
Given all this, I think OS X becomes less necessary to Apple — and Apple users — with each passing year. When does it reach a point where OS X doesn’t make sense to Apple anymore? That’s what I’m mentally pencilling in: 5-10 years, maybe after one or two more releases of OS X.
But in the beginning, I said I was wrong to say that an iOS developer shouldn’t get into Mac programming because the Mac is doomed. And here’s why that’s wrong: you shouldn’t let popularity determine what you choose to work with. Chasing a platform or a language just because it’s popular is always a sucker’s bet. For one thing, times change, and the new hotness becomes old news quickly. Imagine jumping into Go, which in 2009 grew fast enough to become the “language of the year” on the TIOBE programming language index. It’s currently in 34th, just behind Prolog, ahead of Visual Basic .NET, and well behind FORTRAN (seriously!).
Moreover, making yourself like something just because it’s popular doesn’t work. As Desktop Java faded into irrelevance, I studied C++ and Flash as possible areas of focus, and found that I really didn’t like either of them. Only when the iPhone OS came along did I find a platform with ideas that appealed to me.
Similarly, I greatly value the time I spent years ago studying Jini, Sun’s mis-marketed and overblown self-networking technology. Even though few applications were ever shipped with it — Jini made the fatal mistake of assuming a Java ubiquity that did not actually exist outside of Sun’s labs — the ideas it represented were profound. Up to that point, I had never seen an API that presented such a realistic view of networking, one that kept in mind the eight fallacies of distributed computing and made them managable, largely by treating failure as a normal state, rather than an exceptional one. In terms of thinking about hard problems and how stuff works (or doesn’t work) in the real world, learning about Jini was hugely valuable to me at the time I encountered it.
And had I known Jini was doomed, would I have been better off studying something more popular, like Java Message Service (which my colleagues preferred, since it “guaranteed” message delivery rather than making developers think about failure)? I don’t think so. And so, even if I don’t think the Mac has a particularly bright future, that’s no reason for me to throw cold water on someone’s interest in learning about the platform. There are more than 20 years of really good ideas in the Mac, and if some of them enlighten and empower you, why not go for it?
Discussing Apple’s Java deprecation, Java creator James Gosling blogged about the background of Java on the Mac, saying “the biggest obstacle was their use of secret APIs. Yes, OS X has piles of secret APIs. Just like the ones that Microsoft had that contributed to their antitrust problems.”
In a recent Q&A at Google, available on YouTube, he elaborates further, around 43 minutes in (embedded YouTube clip will take you right there, otherwise read the blockquote):
At Sun, we had worked with them to try to take it over. But there were all kinds of issues, and it was mostly things like, you know, to integrate properly into the Mac OS, there were a bunch of secret APIs. And in their integration, there were all these secret APIs, and they wouldn’t tell us what they were, we just knew they were there. And then, you know, it’s sort of like half their brain wanted to give us the code, half their brain is like “no no no no no, we can’t”. So, nyah, that was all kind of spastic.
The fact that Dr. Gosling brings up “secret APIs” repeatedly when talking about the subject makes me think that he really wants to make this point that Apple’s use of secret APIs and its intransigence has been a major problem for Java on the Mac.
But… is it true? How big a deal are secret APIs in OSX and iOS anyways?
Nobody denies that there are undocumented and otherwise secret APIs throughout both OSX and iOS. They are easily found through techniques such as reverse-engineering and method swizzling. On OSX, they can be called, provided you can figure out their proper usage without documentation. Technically, this is also possible on iOS, although use of non-public APIs will get your app rejected by the App Store, so it’s largely pointless.
The benign explanation for secret APIs is that they’re used internally but haven’t been fully vetted for use by third-parties. We’ve all written code we’re not proud of and wouldn’t want others calling, or at least written utility functions and methods that were only thought through for certain uses and aren’t known to be appropriate for general use. An interesting example is iOS’
UIGetScreenImage function. As a devforums thread indicates, Apple started allowing use of this private API in 2009 because there wasn’t a good public alternative, with the proviso that its use would be disallowed once a suitable public API was released. This occurred with the arrival of AV Foundation in iOS 4.0, and direct calls to
UIGetScreenImage are again grounds for App Store rejection.
Aside from technical grounds, another reason for secret APIs is legal entanglements. There was an example of this in one of my earliest blogs: Apple licensed AAC encoding for OS X and for its own apps on Windows (iTunes, QuickTime Player), but not for third-party apps on Windows. According to Technical Q&A QA1347, a developer who wanted to provide this functionality on Windows would need to license the AMR encoding separately from VoiceAge, then provide proof of that license to Apple in order to get an SDK that would allow their code to make the secret call into QuickTime’s encoder.
But what can we say about Dr. Gosling’s complaints about secret APIs and Java? Certainly it plays well to the passions and politics of the Java community, but I’m not yet convinced. We know that most of Java actually ports to the Mac pretty easily: Landon Fuller’s “Soy Latte” project ported JDK 6 to the Mac in just a few person-weekends, and was later incorporated into OpenJDK’s BSD Ports subproject. But that left out some hard parts with intense native entanglements: sound, and the UI (Soy Latte, like most vanilla Java ports, relies on X11). Gosling acknowledges this in his blog, saying of these secret APIs that “the big area (that I’m aware of) where these are used is in graphics rendering.”
However, does this seriously mean that porting the Java graphics layer — Java2D, AWT, and Swing — is impractical or impossible without access to these secret APIs? It can’t be. After all, SWT exists for Mac as well, as a third-party creation, and it does the same things as these missing pieces of OpenJDK. In fact, SWT is more tightly-coupled to native code, as its whole approach is to bind Java objects to native peers (originally in Carbon, later in Cocoa), while Swing is all about avoiding native entanglements and instead painting look-alike widgets. Furthermore, I think Java’s rendering pipeline was switched over to an OpenGL implementation a while back, and that’s a public API that exists on OSX. So this kind of begs the question: what does Java need that isn’t provided by a public API? It doesn’t seem like graphics can be the problem.
The conspiracy theorists could argue that Apple has its own APIs that are more performant than the public APIs. Maybe, but what would be the point? Microsoft was roundly criticized for this in the 90′s, but Microsoft had more cases where their own products competed directly with third parties, and therefore could have incentive for their OS team to give a secret hand to the applications team. With Apple, software is their second-smallest revenue segment, and there are fewer cases where the company competes directly with a third-party rival (though there are clearly cases of this, such as Final Cut versus Premiere). Often, Apple’s software serves a strategic role – iLife may be more useful for selling Macs than for selling itself on DVD to existing Mac owners. So sure, Apple could be using secret APIs to give itself a leg up on competitors, but it’s hard to see how that would really be in their self-interest.
Having said all this, I’m still thwarted by a private API I needed this Summer: the “suck into a point” animation isn’t exposed by a Cocoa API on OSX, and asking for help on cocoa-unbound didn’t turn up an answer. Apparently, it’s possible on iOS, but via an undocumented method. Why this isn’t public on OSX or iOS, I can’t imagine, particularly given that Apple’s apps have made it a fairly standard behavior, meaning users will expect it when you use the round close button on a free-floating view. Oversight? Not ready for public consumption? Apple just being dicks? Who knows!
Of course, that brings up the last point about secret APIs. At the end of the day, they’re almost always conveniences. If something is possible at all, you could probably just do it yourself. I don’t know exactly what transforms are involved in the suck-to-close animation, but it’s surely possible to create a reasonably close approximation with Core Animation. Similarly, instead of calling QuickTime’s secret AAC encoder on Windows, you could license some other library or framework, or write your own. It might not be easy or practical, but if Apple can move the bits in some specific way, it must at least be possible for a third-party to do the same.