Archives for : October2009

Did Open Source Kill Sun?

Some in the Java community are linking to Sun Chairman and Co-Founder Scott McNealy’s comments in the Oracle OpenWorld keynote, in which he wistfully looks back at the soon-to-be-gone Sun and boasts that they:

Kicked butt, had fun, didn’t cheat, loved our customers, changed computing forever

Sorry to bust the warm fuzzies, but we should append that history with a few more words:

and failed anyways

Sun lost money for most of this decade, as its stock fell more than 95%, reaching the point late last year where its market valuation equaled its cash and investments, meaning the market considered the company’s business as having no value whatsoever.

As engineers, we can romanticize Sun’s “good guy” behavior over fine craft beers all night, but at the end of the day, the company ceased to be viable, destroying a great deal of wealth in the process. Sometimes, it seemed like Sun wanted to be the non-profit FSF instead of a publicly-traded company. At least they got the “non-profit” part right.

And clearly understanding Sun’s failure matters because the kinds of things that Sun did are now going to be considered liabilities. Sun tried like crazy to win over the open source community. The community demanded that Sun support Linux, even though Sun would presumably favor its own flavor of Unix, Solaris. But they went along with it… giving companies a reason not to buy Sun hardware and instead lash together cheap Linux boxes, or buy heavy iron from Linux-loving Sun rival IBM. The community demanded that Java be open sourced and, after a series of fits and starts, it finally was, with the ultra-hippie GPL license no less. Ultimately, the community came to believe it had a blank check written against Sun’s engineering resources, as typified in the infamous “changing of the guard” episode of the JavaPosse and the somewhat testy reply.

But what did all these giveaways accomplish? The next time a community goads a company into open sourcing its crown jewels, the critical response may well be “yeah, that worked great for Sun.” In fact, that was pretty much Fake Steve’s take on Sun over the course of Sun’s decline, mocking the company’s giveaways, as it frittered into irrelevance. At the end of the day, how is FSJ not right on this one?

It’s ironic that Sun’s love of the open source community was largely unrequited. As late as 2007, Slashdot founder Rob “CmdrTaco” Malda was still expressing his eternal hatred of Java, and even in GPL form, Java has been slow to win acceptance from the F/OSS types. In an even more ironic twist, Slashdot’s tone has softened lately. For example, a recent article on Android game development quoted its source as saying “While iPhone apps are written in Objective C, the Android SDK uses relatively more programmer-friendly Java.” Why the sudden love for Java? Because it powers Android, the most plausible rival to the iPhone, now telephona non grata to the Slashdot community. In other words, the enemy of my enemy is my friend.

Too late for Sun though, and it’s not clear that a greater acceptance from a community that, by definition, doesn’t like to pay for stuff would even matter anyways. Perhaps the takeaway is that we all need a more realistic attitude about what individuals and companies need to do to continue their existence. Charity is swell, but it’s not necessarily a viable business model.

Royalty pains

Author Peter Cooper posted a blog about his experience publishing Beginning Ruby for APress, a blog that got extraordinary traffic after being featured on Slashdot with a misleading summary. Much of the piece concerns itself with royalties, how they’re calculated, and how they’re paid. In his conclusion, he advocates writing for the Pragmatic Programmers which offers a 50%-of-profits royalty rate.

Tim O’Reilly himself saw fit to counter that advice, claiming that the Prags’ royalty isn’t what it seems, and to imply that a bigger publisher would move more books, meaning that a smaller royalty on bigger sales would cancel out the Prags’ advantage.

About a week later, the Prags’ Dave Thomas posted a blog of his own, spelling out the specifics of the Prags’ royalties.

I commented on Dave’s blog:

Having written one book with the Prags and two elsewhere, my mental taxonomy is now “writing for Prags” versus “writing for free”. Yes, between 10% royalty * coauthors * Amazon discounts * shrinking computer book market, it really is that bad.

But I have more to say, which is why I’m blogging now.

In my experience, and my understanding of the current nature of the computer book market, O’Reilly’s claims that its size give it an advantage in moving more books is probably true to a limited degree, but not enough to make up what is effectively a four-to-five-fold difference in royalty rates. With computer book sections shrinking year after year in brick-and-mortar bookstores, a huge majority of computer books are purchased online from Amazon and its lesser rivals (or just stolen, but that’s another story), which obviates the advantages a bigger publisher like O’Reilly would have in getting its product into more stores.

I wrote one book for O’Reilly and co-wrote another, both released in 2005. QuickTime for Java: A Developer’s Notebook is clearly a niche title (and the topic API is now deprecated), and if Swing Hacks is somewhat more noticable, it’s only because the Java development community is so large. I suspect only one in every 25 to 50 Java developers does Desktop Java, but over 5 million developers, that’s still enough to be interesting. Over their respective lifetimes, the QTJ book sold about 2,000 copies (bad), and Swing Hacks sold 10,000 (good).

The iPhone SDK Development book that I co-wrote for the Prags nearly outsold both of them, combined, just in pre-release beta sales. Granted, the topic is clearly more in demand, but still, enough people found their way to the Prags’ site to buy the beta that before a single final copy had the shelves. I’ve already outearned four years of royalties on the two O’Reilly books several times over. About the same number of copies, but much higher royalties. It’s that simple.

Aside: one factor that complicates comparing apples to oranges: since QTJ:ADN never outearned its advance, the royalties on I earned SH beyond its advance were applied to my royalty debt on QTJ until that was paid-up. I’m not sure if this is standard practice.

One other factor that I think is even more interesting is that the Prags presumably can offer a higher royalty because their overhead is very low. O’Reilly has a lovely campus in business-unfriendly California; I’m not sure the highly-distributed Prags even have a formal office. The low overhead is presumably what allows the Prags to offer such a high rate, but moreover, they’re able to take a chance on niche-ier topics. O’Reilly’s upcoming Cocoa and Objective-C: Up and Running is, by my count, their fourth introductory Cocoa programming book (following the awful ADC-authored Learning Cocoa, James Duncan Davidson’s rewrite of it, and Mike Beam’s Cocoa in a Nutshell). Apparently the broad Mac programming market is big enough to be interesting to them, but not any smaller part of it. If you want a book on Core Animation or Xcode, you pretty much have to look to other publishers (notable exception: the Bonjour/Zeroconf book).

To me, that’s a bigger deal, because your royalties are zero if a publisher won’t even put your title out there. Right now, the iPhone market has ample introductory titles (and Mac is almost there, once titles are updated for Snow Leopard or Daniel Steinberg finishes his overhauled-for-SL Cocoa book), and the next step is to get deeper into topics that are too large or too difficult to cover in introductory books. But almost by definition, these titles carve up the market for the introductory book, and only publishers who can make money off niches can produce such titles. Pretty safe to say that if we see a book on, say, Core Audio, or advanced use of the Xcode toolset (IB, Instruments, etc.), it’s going to be from one of these smaller publishers.

Video Editing with Haddocks, on evidence of a new Apple video format in iMovie 8.0.5

Dubbed iFrame, the new video format is based on industry standard technologies like H.264 video and AAC audio. As expected with H.264, iFrame produces much smaller file sizes than traditional video formats, while maintaining its high-quality video. Of course, the smaller file size increases import speed and helps with editing video files.

Saying smaller files are easier to edit is like saying cutting down the mightiest tree in the forest is easier with a haddock than with a chainsaw, as the former is lighter to hold.

The real flaw with this is that H.264, while a lovely end-user distribution format, uses heavy temporal compression, potentially employing both P-frames (“predicted” frames, meaning they require data from multiple earlier frames), and B-frames (“bidirectionally predicted” frames, meaning they require data from both earlier and subsequent frames). Scrubbing frame-by-frame through H.264 is therefore slowed by sometimes having to read in and decompress multiple frames of data in order to render the next one. And in my Final Cut experience, scrubbing backwards through H.264 is particularly slow; shuttle a few frames backwards and you literally have to let go of the wheel for a few seconds to let the computer catch up. For editing, you see a huge difference when you use a format with only I-frames (“intra” frames, meaning every frame has all the data it needs), such as M-JPEG or Pixlet.

You can use H.264 in an all-I-frame mode (which makes it more or less M-JPEG), but then you’re not getting small file-sizes meant for end-user distribution. I’ll bet that iFrame employs H.264 P- and B-frames, being aimed at the non-pro user whose editing consists of just a handful of cuts, and won’t mind the disk grinding as they identify the frame to cut on.

But for more sophisticated editing, having your source in H.264 would be painful.

This also speaks to a larger point of Apple seemingly turning its back on advanced media creatives in favor of everyday users with simpler needs. I’ve been surprised at CocoaHeads meetings to hear that I’m not the only one who bemoans the massive loss of functionality from the old 32-bit C-based QuickTime API to the easier-to-use but severely limited QTKit. That said, everyone else expects that we’ll see non-trivial editing APIs in QTKit eventually. I hope they’re right, but everything I see from Apple, including iFrame’s apparent use of H.264 as a capture-time and therefore edit-time format, makes me think otherwise.

Bringing Your Own Maps

Back at the introduction of iPhone SDK 3.0 (check out the video in the Apple Keynotes podcast), Scott Forstall demo’ed Map Kit, showing how to display locations in with the attractive Maps GUI. He added that turn-by-turn apps would be permitted, with one proviso: “bring your own maps”.

So… what does that really entail and mean?

Well, back up and look at what the iPhone provides. Core Location uses whatever location technologies are available to a device — Skyhook‘s wifi positioning system, cell tower triangulation, and/or GPS — to determine your location. Depending on your hardware, you may also get a course (which indicates a direction of travel) and on iPhone 3GS you can get a heading from the compass, indicating the orientation of the device.

Map Kit, on the other hand, is responsible for displaying location data. Given a location to center on and a zoom level, you can show maps of the location, and decorate the map with annotations (often displayed as push-pins) that represent points of interest on the map.

So what’s missing? The ability to get any kind of location data other than the user’s current position. You can show the user on the map, but there’s little in Core Location or Map Kit that relates the location to what’s around it. Map Kit does provide “reverse geolocation”, so you can get some region information for a point (city, state, country for sure, maybe street if you have a good location). But even if you see streets on your map view, there’s nothing in the provided APIs to tell you what or where those streets are, what’s located on them, or how to move about them.

This is what “bring your own maps” means. Simple iPhone apps might be able to put a bunch of Lat/Lng pairs on a map from some kind of data source (like a database of where you’ve sent tweets from), but can’t really do anything with that data other than display it. Nothing in the provided APIs lets you, say, search for all the Apple Stores in Michigan, or get directions to one of them.

The point of “bring your own maps” was made again in the WWDC Map Kits presentation, noting that there are many map services out there. And this is true. Programmable Web has a nice list of dozens of online geolocation, mapping, and other location services. You just need to pick one, incorporate it into your application, and do whatever logic you’re going to do with the data you receive from it: show points of interest on a map, calculate routes, etc.

I’ve been working on prototyping a geo-app and it turns out that bringing your own maps is a bigger problem than you might think. As an end user, there’s a glut of online map sites to freely play with. But using this data in an iPhone application is quite another story.

The major road blocks come from terms-of-service limitations:

  • The iPhone SDK TOS forbids using any interpreted language, so SDKs that use server-side languages like Java, PHP, etc. are off-limits.
  • Many of the mapping sites put the majority of their work into a JavaScript API, but again, you can’t run JavaScript by itself in an iPhone application (even though this is a much-touted form of development on the Mac, as seen in Dashboard widgets and Quartz Composer).
  • As an upshot of the previous two points, you generally need to find a map service that offers data via a web service, or a similar network protocol. It’s possible that a C or C++ API could be incorporated into a native iPhone app, depending on what libraries it uses (stdio and BSD sockets already being present on the iPhone).
  • Most map providers explicitly prohibit commercial use, at least at their free level of service (which only makes sense… why would they pay to license map data and let someone else make money off it?) Some allow commercial use in specific web-centric scenarios, such as hosting Google Maps on a site that is supported by advertising.
  • Many providers prohibit initiating a search from a sensor-determined location, ie, the GPS-identified current location, which obviates the whole point of many potential iPhone location-based apps.
  • Some providers explicitly prohibit incorporating their mapping data with other providers’. Since Google’s tiles are the visuals for Map Kit, you can’t incorporate data from Bing’s map service into an MKMapView.

So, I spent last night going over the Terms of Service from various providers. Here are the good and bad points (from the POV of developing a paid iPhone app) from each:

  • Google Maps (FAQ, terms)
    • Good: Commercial use OK if freely available (presumably an ad-supported free app would qualify?). Non-web apps specifically permitted (if free).
    • Bad: Can’t use in paid app. HTTP API limited (doesn’t do directions, though this is the top feature request). “Maps Data” API still driven by creation/manipulation of maps, not geo-data by itself. No real-time guidance (10.9.a). Only to be used for displaying Google maps (10.12)
  • Yahoo! Maps (terms)
    • Good: Free, even for some commercial uses. REST web service.
    • Bad: Can’t use with GPS data (, can’t use for anything other than showing Yahoo! maps (1.f.ix).
  • MapQuest (terms)
    • Good: Most (all?) functionality available via HTTP/XML.
    • Bad: Free access is only for evaluation (2.4.b). Not clear if starting your search from a GPS position is prohibited. See if you can make sense of this proviso from section 3, because I can’t:

      “[You may not…] derive results from the Service based on sensor-derived location data or information or input in the form of coordinate data, provided that a coordinate location or location derived by a single sensor, including without limitation a sensor incorporated into, connected to or in communication with any mobile device or system, may be used solely as an origin or destination in deriving a map or direction;”

  • Navteq (terms)
    • Good: Multiple web services
    • Bad: 30-day trial (10K sessions or 10K transactions), then must pay for license. Haven’t yet found the TOS for commercial licensees (the evaluation terms are fairly short, and of course preclude use in commercial apps)
  • Teleatlas (terms)
    • Good: N/A.
    • Bad: C#, VB, and Java only.
  • Bing Maps Web Services (terms)
    • Good: Free terms apparently prohibit only the routing of multiple GPS-located objects (but also prohibit presenting “individual maneuvers” of a route sync’ed to user’s GPS-located position).
    • Bad: Dev Kit for web services requires downloading an .exe (uh, no). Programming reference is all in terms of CLR langauges (C#, VB, J#, etc.) [except possibly for C++ ?]. No integrating with other mapping platforms.
  • OpenStreetMap
    • Good: N/A.
    • Bad: No API. Not even clear how you restrict a search to a geographic area. Web results border on useless (no hits for “subway in grand rapids” or “subway 49525”)

Some of these clearly cannot work in an iPhone application, most notably those that that are built around languages that don’t exist and/or are forbidden on the iPhone (sure, you can probably statically compile a scripting language, but is that really going to be easier than just finding a web service you can call from Obj-C?). Of those that remain, the big question is whether enough of the deal-killers go away with commercial licensing. For example, if you can find points-of-interest or routes with Bing, but can’t put them on a Google Map, then Bing is probably out of the running.

To top it all off, there’s a question of financial viability. Your map licensing model probably needs to match your app’s pay model. If you’re going to charge for your app, you need to make sure the location service you license is fully paid up for as long as your app may be in use out in the field (which is indefinite). If the map service is a recurring fee, maybe you get around this by selling to the user as the app plus n months or years of service, then fund the future use of the app with in-app purchase. Another option if the map service requires periodic payment is to give the app away free, support it with advertising, and use recurring ad revenues to pay the mapping bills. This clearly has both merits and hazards, to say nothing of the dubious prospect of serving up tiny little hard-to-see Google ads if your app is meant to be used in a moving vehicle.

A final point: with so many of the TOSes written with the expectation that they’ll be used in webapps, maybe that’s an equally valid way to go for some applications. After all, iPhone 3.0 provides location awareness in Safari, so you could write a web app that figures out where it is when run on an iPhone.

Flash? Go on…

Much tweetage today over the announcement of Flash for iPhone. Not as a browser plug-in, which Apple still refuses (and which would be desirable for the many Flash-dependent pages out there), but as a cross-compiler solution: take a Flash project, hit export, get an iPhone app.

Fine in theory. In fact, kind of neat. But what’s the point? I had a torrid session of tweetage with friends, my main point being that the most typical use of Flash is in enhancing web pages, and there’s not much value bringing a fragment of a web page over as a stand-alone iPhone app. The number of cases where you spend a significant amount of time directly interacting with Flash is pretty low and, Mad Men Yourself notwithstanding, most of them are games (which the iPhone already has a glut of). I hoped to leave things with this:

In summary: Flash offers 2 things browsers don’t have: graphics-rich runtime and media. Cocoa Touch lacks neither.

I’m not trying to make the case that Cocoa Touch and Objective-C is better than Flash and ActionScript, I just don’t see how this solves anyone’s real problems. [Cynical aside: except for Adobe’s need to sell more Flash CS Professional licenses]. It’s impressive from a technological point of view, but is there really that much Flash code that’s going to be viable and valuable as stand-alone iPhone applications?

Actually, there was one more tweet I held back from sending, because I didn’t want the debate to get nasty. Since nobody reads this blog, I’ll post it here:

Meanest thing I could say about Flash-for-iPhone: “That sounds like something Sun would do.”

We love your book, we just don’t feel like paying you for it.

I knew this would happen, but it’s still pretty grating:

Screen shot 2009-10-05 at 1.13.18 PM

Also woke up to a robo-Tweet from an iPhone news account that was passing along the URL to illicit copies of the book.

Hope you kids can learn everything you need from blogs, because books are going to be gone pretty soon at this rate.

@property blah blah

Like everyone else, I’ve tired of Obj-C’s dance of redundancy, specifically having to declare interface variables for properties if you want to run in the simulator (or the “old” Obj-C runtime on Mac). To speed things up, I create the ivars first, then copy-and-paste outside the @interface block to set up the properties. Which still sucks, because I have to prepend every line with the @property declaration.

9 times out of 10, the property is for a UI outlet, so I’m always setting it up as @property (nonatomic, retain) IBOutlet IvarType *ivarName

To speed things up, I finally figured out how to set up an Xcode text macro for this:

    Identifier =;
    BasedOn = objc;
    IsMenuItem = YES;
    Name = "IBOutlet @property";
    TextString = "@property (nonatomic, retain) IBOutlet ";
    CompletionPrefix = "@property";
    OnlyAtBOL = YES;
    IncludeContexts = ( "xcode.lang.objc.block" );

Then I used the Keyboard system pref to add an Xcode-only keyboard shortcut to the “IBOutlet @property” menu item (right now it’s cmd-option-I… we’ll see if that sticks).

And all this makes setting up my properties suck just a little bit less.

A Two-fer to Close out September

Well, here is some hilarious timing for you:

Screen shot 2009-10-01 at 9.55.16 AM

What you’re seeing in my inbox (click for full-size image) are notifications of the release of the print edition of iPhone SDK Development, arriving just 20 minutes after word from Apple that my iPhone game Don’t You Know Your Own Tunes? had been approved and made available on the App Store.

Yeah, kind of too bad that these both came out just six hours before the close of the third quarter, meaning that some proceeds won’t show up until 2010. But that’s nit-picking. I’m just glad to have both projects finished and available to everyone, and to be working on a new app that will be difficult but highly satisfying when it’s done.