Author Archives: Daniel Jalkut

End WWDC

Not long ago, when Apple’s WWDC conference dates were announced, a slow trickle of registrations would occur as developers consulted with spouses, bosses, and co-workers to determine, in their own sweet time, whether or not they would attend. There was never any rush, because the conference never sold out. Weeks after the announcement, developers who had not registered might even receive a personalized telephone call from Apple, urging them to make a decision. Seriously kids, this is how it used to be.

Over the past several years, demand increased such that at last, those telephone reminders from Apple were no longer necessary. By 2008, the conference sold out for the first time, in a matter of months. By 2010 it took eight days. Last year it took less than 2 hours, and this year? Less than two minutes. I was one of the lucky ones who got a ticket. A few minutes later, as I witnessed friends and colleagues upset after missing the boat? I cancelled my order. It made me uncomfortable to know we had all made the same effort to register as quickly as possible, but for arbitrary reasons I was admitted in and they were left out.

The conference has room for at most 5,000 developers. According to Apple’s job stimulus statistics, there are 275,000 or more registered iOS developers alone. Let’s assume for the sake of argument that Mac developers add only 25,000, bringing the total to 300,000. Every year, 5,000 attendees are selected from the qualified pool, meaning just 1 out of 60, or 1.5% of potential attendees will have the chance to attend.

What are the goals of WWDC, anyway? For Apple, it’s primarily a chance to educate developers and to encourage them to contribute to the growth of Apple’s platforms. By teaching developers the latest and greatest technologies, they leverage developer efforts to differentiate Apple and to make its platforms more competitive.

For developers the main goal is to get a leg up on the persistent challenge of developing great software for these platforms, even as they are constantly changing. A side-benefit is the opportunity to commune with like-minded developers who are trying to do the same. Ideally with folks who share similar visions for how software should be developed and how the end product should behave for customers.

As the sheer number of Apple developers increases, the capacity of WWDC remains the same. The goals of the conference both for Apple and for developers are increasingly unmet as the number of developers who would like to be educated, indoctrinated, and communed with far outweighs the number of developers who actually can be.

Over the years people have made plenty of flip suggestions for how Apple can solve the problems that plague WWDC: get a bigger venue, charge more money, split it up into multiple conferences. But any of these would be a very small band-aid on a very large wound. WWDC is flat-out busted, and can’t be fixed by any of these analog solutions.

The whole point of the conference needs to be rethought, and the goals addressed from scratch using new approaches. As the greatest challenge for WWDC is in scaling to meet demand, I think it’s obvious that the rethought WWDC should be considered in terms of digital solutions. Call it WWDC if you like, but it needs to take place 365 days a year instead of 4. It needs to serve 300,000 developers, not 5,000. And it needs to take place online, not within the cramped confines of a small convention center in San Francisco.

Apple has effectively headed down this course with their laudable offering of free videos of conference sessions. The high-level goal of merely educating developers is largely met by these. But what of the other goals? The vast majority of benefits that Apple and developers see in WWDC could be achieved online using more effective digital materials that are available to, and more importantly, that scale to the vast number of developers eager to learn about and promote Apple’s platforms.

Instead of a week each year when a developer must enter a lottery for a chance at talking directly with a knowledgable Apple engineer in the labs, beef up the existing Developer Technical Support process and workflow so that vexing issues can be driven to the point of resolution, and so that the fruits of those discoveries can be shared with others. For every “lifesaving” tip a developer has received in the WWDC labs, how many others continue to struggle in anguish because the effort was never made to codify that wisdom in the form of a developer technote or other reference material? It doesn’t make sense … it’s a bug, if you will … that so many Apple developers feel that their only opportunity to solve a problem is by meeting in person with an Apple engineer at WWDC.

Instead of asking Apple’s engineers to spend weeks every year preparing, rehearsing, and delivering sessions in San Francisco, ask them to spend a reasonable percentage of the year consulting with and assisting in the development of long-term interactive, iteratively improved video documentation. Start with the last 3 years of WWDC talks on a given subject and condense it down to concise summary of the most pertinent instruction, tips, and demos. It would be ridiculous for Apple to maintain separate text documents for each year, and for developers to be told “Oh, that was addressed in 2011’s NSTextView documentation, go back and look it up.” Yet that’s what developers are forced to do when trying to extract gems of knowledge from past WWDC sessions. (Cough, it’s regrettably true that Apple’s “Release Notes” sometimes serve as a similar kind of decentralized documentation authority).

And what about the community incentive for developers? Isn’t it important to have an opportunity to meet with and catch up with developers from around the world? Yes, it is important, or I should say it would be if it actually worked any longer at WWDC. The very small fraction of developers who are admitted, combined with the unpredictability of whether you or your friends will make the cut, make it essentially useless as an annual catching-up venue. Look to smaller conferences for this ambition. While some of them are similarly challenged in meeting demand for attendance, many are more fine-tuned both in teaching style and in topic choice. They each have a special feel of their own, which naturally attracts a repeat audience whose members are more likely to find fellowship with one another than in the comparatively giant, rotating petri dish of this year’s random WWDC ticket winners.

I have loved the times I’ve attended WWDC, and I may yet end up enjoying it again, but its time has passed. It’s time to move on. In 1983, 1993, and 2003 it was the right tool for the job because it largely fulfilled the objectives for both Apple and developers. In 2013 it’s a strangely exclusive, rotating club with arbitrary membership rules, and increasingly dubious advantages. It’s a source of annual stress and uncertainty for would-be attendees, and has just delivered a whopping blow to thousands of developers who didn’t make the cut for this year’s show.

I would miss many things about WWDC, but the things I would miss could easily be offset by superior, scalable solutions. And I would be happy to leave behind the increasing number of obnoxious aspects of the yearly ritual. It’s time for something better. It’s time to end WWDC.

Bitsplitting With Jacqui Cheng

I’ve just posted the third episode of the Bitsplitting Podcast, with my friend Jacqui Cheng from Ars Technica.

I have known Jacqui for many years, but have rarely had the opportunity to sit down and chat about sundry topics technical and otherwise. I learned a great deal about Jacqui’s background as a software engineer, her many hobbies, and the evolution of her own self image.

It’s been gratifying to finish up three episodes so far, and to be so happy with each of them. I think this is really working out well. Thank to all who are tuning in.

Check Your Libel

Two days ago, the internet went nuts over Apple’s alleged homophobic, capricious censorship of Saga #12, an adult-themed comic. As far as I can tell, the allegations originate in a statement from the comic’s co-creator, Brian K. Vaughan, in which he claimed that the issue had been banned specifically by Apple:

Unfortunately, because of two postage stamp-sized images of gay sex, Apple is banning tomorrow’s SAGA #12 from being sold through any iOS apps.

The claim was taken by many at face value, and folks were understandably outraged by the implication that Apple was specifically rejecting the issue based on gay-themed content. It didn’t take long before the claim had been republished in zillions of tweets and on blogs ranging from casual fan sites to Comic Riffs, a blog residing under the banner of the Washington Post.

In short: it didn’t take long before everybody “knew” that Apple was a big, bad, homophobic, reckless censor of artistic content. Until yesterday, when the news came out that Apple had not, in fact, rejected the content in question:

It appears that Vaughan may have been jumping the gun in assigning blame. Apple confirmed to Macworld later on Wednesday that it did not block Saga #12, and Comixology CEO David Steinberger subsequently took responsibility in a post on the company’s blog.

It turned out that the content in question had never even been submitted to Apple. I’m guessing some kind of communication breakdown occurred between Comixology, the creators of the app, and Image Comics, the publishers of the comic. Amid this miscommunication, Brian K. Vaughan presumably leapt to the conclusion that Apple was at fault, and chaos ensued.

I myself have been guilty of jumping to conclusions about Apple. But when allegations like these take on a kind of collective confirmation, it’s unfairly damaging to the brand and, by extension to the reputations of the people who work for Apple. I am not an expert in legal matters, so I can’t say that it constitutes libel, per se, but it meets my everyday understanding of the term: a false written statement that damages a person or company’s reputation.

It’s extremely upsetting when a damaging claim turns out to have been false. We need to be outraged by this, or the whole system of fact-based accountability breaks down. As mad as you or I or anybody else may have been about the alleged misdeed by Apple, we should be at least as mad that we were misled to believe it was true.

To Brian K. Vaughan’s credit, he apologized publicly for the mistake, in a brief statement published by The Verge and also on Image Comics’s Tumblr:

I wanted to apologize to everyone for this entire Saga #12 kerfuffle. Yesterday, I was mistakenly led to believe that this issue was solely with Apple, but it’s now clear that it was only ever Comixology too conservatively interpreting Apple’s rules. I’m truly sorry. I never thought either company was being homophobic, only weirdly inconsistent about what kind of adult material was permissible.

It’s an apology, and that’s a start. But in my opinion it doesn’t meet the standard of a great apology. First, the “led to believe this issue was solely with Apple” leaves open the implication that some of the fault remains with Apple, when all evidence points to the fault being entirely in Comixology’s decision to not submit the issue. Second, the apology fails to acknowledge and specifically apologize to Apple for the damage his statement has done to them.

When any of us witnesses what we believe to be an injustice, it’s tempting to cry out loudly and forcefully. The web is a great tool for dissemination of information, but it’s just as good or better at spreading misinformation. In the old days, libel was something that, practically speaking, only an elite class of published writers risked committing. Most people didn’t publish written content for all the world to read. These days, any one of us could be on the verge of stating as fact something that is very damaging to a person or company, yet very false. Check your libel.

Why Mention Android

Facebook is apparently due to launch an Android-based phone next week. John Sherrod wonders why they bother to mention the Android brand at all (emphasis mine):

Lately the trend has been for companies to develop phones and tablets based on a heavily customized version of Android and not even mention Google’s OS in their press events. The mention of Android is particularly surprising given all the ways that Google and Facebook compete with one another.

Google has been ridiculed in the years since Android’s debut for failing to profit much from the technology, in spite of using it to stake out a modicum of control over a large segment of the mobile industry.

Let’s assume for the sake of argument that the Facebook product is a success. Let’s assume they make a ton of money off of it. What better way to rub it in a competitor’s face than to make it very clear that you succeeded not in spite of but thanks to their technology. That you succeeded with it in a way that they couldn’t?

Mentioning Android today sets the stage for a graceful postmortem, regardless. If Facebook’s phone is a flop, they can assign some blame to Android (c.f. Motorola Rokr). If it’s a huge hit: “Google, we pwned you!”

(Via Daring Fireball)

Google’s Next Great Thing

Google Express promises same-day delivery of goods from a variety of San Francisco retailers.

Roberto Baldwin makes the very San Francisco comparison to Kozmo, the famously failing ‘90s home-delivery startup, while John Gruber chastises Google for an evident lack of focus.

But what if this is the embodiment of Google finding its focus?

Steve Jobs said of Apple, before returning to the company in 1996, that he would “milk the Macintosh for all it’s worth — and get busy on the next great thing.” It’s reasonable to argue in retrospect that this is exactly what he did.

Suppose Google recognizes that they can’t play king of online advertising forever, that it must hunker down and focus on its own “next great thing?” What technology does Google own that sets it farthest apart from potential competitors? Driverless vehicles.

Google has allegedly been testing its delivery service with employees and their friends since at least October, 2012. If this fleet is not driverless yet, I’m sure it’s slated to become so.

I’m not sure it matters too much if Google succeeds, at least in the conventional sense of toppling rivals such as Amazon in the home delivery market. I imagine they see this as a no-lose gamble. If they happen to strike a chord of convenience, price, and quality in retail delivery, they may just give Amazon a run for their money. If they don’t, they will still have pushed their driverless cars through another phase of real-world testing. Amazon can keep its massive, profitless customer base, and Google can keep its next great thing.

Bitsplitting With Erika Hall

I’m pleased to announced that the second episode of the Bitsplitting Podcast is now available, featuring my friend Erika Hall of the Mule Design Studio.

It was a lot of fun talking with Erika. Easily the greatest challenge so far in recording this podcast is trying to keep the length of shows around the 1-hour mark instead of talking for four hours as I’d be inclined to do.

I hope you enjoy the interview!

The Bitsplitting Podcast

I’m excited to announce that the previously hinted Bitsplitting Podcast is now live. The first episode features Guy English of Çingleton and Aged & Distilled fame.

The show will come out on a biweekly schedule, so in general you can expect a new episode “every other Friday” from here on out.

New episodes will always appear on the podcast’s home page, but I encourage you to subscribe via iTunes, or through another app using the podcast-specific RSS feed.

I hope you enjoy the show.

NetNewsWire Cloud

My friend Brent Simmons created NetNewsWire over 10 years ago. The app, a Mac-based RSS aggregator, has been a constant companion to me for what feels like an eternity: I check it daily to keep up with the most important blogs, Google searches, and referral notices that I want to keep on top of. Most important of all to me, NetNewsWire spawned MarsEdit, the blogging app that I now develop and which supports me and my family.

Today Google announced they are shuttering Google Reader, the web service that has brought RSS aggregation to what I would guess is the largest number of people to ever enjoy the benefits of “news feeds” on the web. The termination of Google Reader is a disappointment to its loyal users, but it will also have a huge impact on the number of client apps, including NetNewsWire, that have built their syncing functionality on top of the service. When Google Reader goes away, all those apps will lose their syncing capability, or outright stop working.

Some folks will claim that nobody cares about RSS anymore. But the loud outcry on Twitter and through other channels indicates there is still a significant number of people who rely on the technology.

Which brings me back to NetNewsWire. My guess is that after Google Reader, and possibly after Newsvine, NetNewsWire is the most recognized brand in the world for the admittedly niche market for “RSS Readers.” When the top brand in the market drops out, it puts a huge amount of focus on the remainders. Black Pixel, the current developers of NetNewsWire, have to be taking notice.

At this point Black Pixel need to ask themselves one question: are we interested in RSS, or aren’t we? They acquired NetNewsWire because they no doubt loved it and had become reliant on using it themselves. They wanted to see it live on and prosper. But did they expect to be put in a position where they are faced with the challenge/opportunity of becoming the world’s leading RSS services company? Probably not.

My understanding is that the slowness in developing and releasing a successor to NetNewsWire 3 is largely in coming to terms with the challenges of working around Google Reader issues. With Google Reader out of the picture, not just for NetNewsWire, but for everybody, a new future for RSS syncing arises: NetNewsWire Cloud.

By implementing a suitable syncing API for RSS, and implementing a reasonably useful web interface, Black Pixel could establish NetNewsWire Cloud as the de facto replacement for Google Reader. Charging a reasonable fee for this service would likely inoculate it from the risk of sudden termination, and it would doubly serve to provide the very service that NetNewsWire needs to thrive on the desktop and on iOS.

Don’t get me wrong: this is no small order. I would not fault Black Pixel one iota for looking at the challenge and deciding to take a pass. But if they are truly passionate about RSS, this is their moment. This is the time when accepting the impossible challenge will reap the greatest reward.

An Indie State Of Mind

Marco Arment and John Siracusa recently wrapped up their long-running podcasts, Build & Analyze, and Hypercritical. They have since gone on, in collaboration with Casey Liss, to establish two new podcasts: Neutral, a show about cars, and the Accidental Tech Podcast.

Each of the retired shows was on the popular 5by5 podasting network, while each of the new shows is not. Since John Gruber’s sudden departure last year from 5by5, people are particularly keen to look for elements of drama related to the network. I’m guilty of it, myself. But Occam’s razor applies in situations such as this as well. The simple explanation? People who are satisfied stay where they are, and people who are less satisfied move on.

Marco acknowledged that he has been asked repeatedly why the new shows aren’t on 5by5, and conceded to share his own personal reasoning:

I want to own everything I do professionally unless there’s a very compelling reason not to. Some people feel uneasy having that level of control, but I feel uneasy not having it (to a fault).

There you have it: Marco is an indie, and he is bound to behave like one. Working within the confines, no matter how cushy, of another institution is simply not his style. He was destined to be unsatisfied with the status quo, and leaving to do his own thing no doubt resolved a great deal of tension.

I’m surprised by how consistently people assume that joining a large podcasting network is an end-goal for indie podcasters. My friend Manton Reece and I have been recording Core Intuition for over 4 years, yet when I have guest-hosted Build & Analyze or appeared on other 5by5 shows, a significant number of people write or comment on Twitter that I should “have my own show.” I have my own show, thank you very much. And I’m starting another one.

I worked at Apple for more than 7 years, before branching out on my own to focus exclusively on Red Sweater. I’m grateful that, in contrast to indie podcasting, there is far less bias towards conglomeration in the indie software scene. I’m not constantly nagged about when I’m going to re-join Apple, or Google, or Microsoft, or Twitter. And when I ship a new app, I don’t face a barrage of questioning about which larger company will be distributing it. It’s understood that I build, test, distribute, debug, and market the software by myself. And people respect that.

Like Marco, I derive a great amount of satisfaction from doing things for myself. Also like Marco, it can sometimes be a fault. No doubt I would benefit in many ways from working for a company or from joining a podcasting network. The resources and reach of these institutions could help me build greater things and get them in the hands of more people. On the other hand, they could force me to build things that suck. Folks like us, we with an indie state of mind, tend to face a far simpler choice: be dissatisfied working for somebody else, or gratified by the thrill of trying our own thing.

Coming Soon: The Bitsplitting Podcast

I have really enjoyed, and will continue to enjoy, producing the Core Intuition podcast with my friend Manton Reece. What started as an irregular, very casual podcast more than four years ago turned into a much less irregular, weekly show last year.

The success of Core Intuition inspired me to revisit a long-standing interest I’ve had in interview-style podcasts. I have always been a fan of the humanistic style of interview as perfected by Fresh Air’s Terry Gross, and while I have no illusion of matching Ms. Gross’s impeccable style, I hope to start down the path that ends at being at least a bit more like her. In a nutshell, the gist of my show will be interviewing folks I’ve had the luxury of meeting, who have interesting perspectives. I’ll differentiate my show from some others by focusing more on the personal background of my guests, and on trying to discern a philosophical arc to their life and career choices.

We are currently enjoying a renaissance in podcasting (hat-tip for that assessment to Brent Simmons), and I’m excited to be among the lucky folks who are more-or-less ready to seize on the opportunity. I have learned a lot from producing Core Intuition, and from being a guest on countless other shows. What can I say? I’m a lucky guy. Right place, right time, right skills.

With Core Intuition, we waited over four years before we started accepting sponsorships. For the Bitsplitting podcast, I will accept them from day one. I was skeptical about sponsorship, but I’ve learned that it creates both a positive obligation and a positive reward. Once a sponsor has committed to paying for the privilege of a mention on my show, I feel obligated to not only record and publish the show, but to do so in a way that exudes professionalism worthy of the sponsor’s blessing.

The rewards are more complex. Obviously, there’s the money. Money is good. But less obvious is a certain validation that comes from anybody else sticking their neck out to validate your work. Spending money is a somewhat crude, yet very unambiguous way of sticking one’s neck out. I have found with Core Intuition that while the money is nice, it’s most important that we have an unambiguous message from our sponsors that the show is valuable. It helps us, literally, to get out of bed in the morning to record the show.

So I need sponsors. I understand that with Bitsplitting, “there’s no there there” yet, and that makes this a harder sell. If you work for or own a company with vision and a willingness to take a chance, consider being among my debut sponsors. How many listeners do I have? Zero. How many listeners will I have? Time will tell. To balance your faith in sponsoring something new, I’m offering a reduced-cost sponsorship while the wheels are set to motion. If you’re interested, please check out this preliminary sponsorship information, and drop me a line.

Update February 21, 2013: I am humbled by the reaction to my call for sponsors. We are in good shape for the launch of the show, and I’ll resume booking sponsors for future episodes after the show debuts.

Whether or not you’re in a position to sponsor the show, I hope you’ll keep your eyes on this site, or on the @bitsplitting Twitter account, to learn about the launch of the podcast, which I am confident you will find both educational and amusing.

Virtual ROM

My attention was drawn by Anil Dash on Twitter to two posts discussing the purported and actual capacities of devices that, for example, advertise “64GB of storage.”

Marco Arment linked to an article on The Verge, asserting Microsoft’s 64GB Surface Pro will have only 23GB of usable space. Arment went on to suggest that device manufacturers should be required to market devices based on the “amount of space available for end-user” data.

Ed Bott’s take, on the other hand, was that Microsoft’s Surface Pro is more comparable to a MacBook Air than other tablets, and its baseline disk usage should be considered in that context.

I think each of Arment’s and Bott’s analyses are useful. It would be nice, as Arment suggests, if users were presented with a realistic expectation of how much capacity a device will have after they actually start to use it. And there is merit in Bott’s defense that a powerful tablet, using a more computer-scale percentage of a built-in disk’s storage, should be compared with other full-fledged computers.

Let’s just say if fudging capacity numbers was patented, every tech company would be in hot water with the patent trolls. A quick glance at iTunes reveals that my allegedly 64GB iPhone actually has a capacity of 57.3GB.

ITunes

I don’t know precisely what accounts for this discrepancy, but I can guess that technological detritus such as the metadata used by the filesystem to merely manage the content on the disk takes up a significant amount of space. On top of that, the discrepancy may include space allotted for Apple’s operating system, bundled frameworks, and apps. Additional features such as recovery partitions always come at the cost of that precious disk space. Nonetheless, Apple doesn’t sell this 64GB iPhone as the 57.30GB iPhone. No other company would, either.

It seems that in the marketing of computers, capacity has always been cited in the absence of any clarification about actual utility. One of my first computers (after my Timex Sinclair 1000) was the Commodore 64, a computer whose RAM capacity was built in to the very marketing name of the product. Later, Apple followed this scheme with computers that would be known as the Mac 128K and Mac 512K. Each alluding to its ever-increasing RAM capacity.

The purported RAM capacity was somewhat misleading. Sure, the Commodore 64 had 64K of RAM, but some of that had to be used up by the operating system. Surely it would not be possible to run a program that expects 64K of RAM, and have it work. So was it misleading? Yes, all marketing is misleading, and just as it’s easier to describe an iPhone 5 as having 64GB capacity, it was easier to describe a Commodore as having 64K, or a Mac as having 128K of RAM.

But the capacity claims were more honest than they might have been, thanks to the pragmatic allure of storing much of a computer’s own private data in ROM instead of RAM. Because in those days it was much faster to read data from ROM than from RAM, there was a practical, competitive reason for a company to store as much of its “nuts & bolts” code in ROM. The Mac 128K shipped with 128K of RAM, but also shipped with 64K of ROM, on which much of the operating system’s own code could be stored and accessed.

Thanks to the ROM storage that came bundled with computers, more of the installed RAM was available to end users. And thanks to the slowness of floppy and hard disks, not to mention the question of whether a particular user would even have one, disk storage was also primarily at the user’s discretion. It was only after the performance of hard drives and RAM increased that the allure of ROM diminished, and computer makers turned gradually away from storing their own data separately from the space previously reserved for users. With the increasing speed and size of RAM, and then with the advent of virtual memory on consumer computers, disk and RAM storage graduated into a sort of virtual ROM.

The transition took some time. Over the years from that Mac 128K, for example, Apple did continue to increase the amount of ROM that it included in its computers. I started working at Apple in an era when a good portion of an operating system would be “burned in ROM”, with only the requisite bug fixes and updates patched in via updates that were loaded from disk. I haven’t kept up with the latest developments, but I wouldn’t be surprised if the ROM on modern Macs is only sufficient to boot the computer and bootstrap the operating system from disk. For example, the technical specifications of the Mac Mini don’t even list ROM among its attributes. The vast majority of capacity for running code on modern computers is derived from leveraging in tandem the RAM and hard disk capacities of the device.

So we have transitioned from a time where the advertised capacity of a device was largely available to a user, to an era where the technical capacity may deviate greatly from what a user can realistically work with. The speed and affordability of RAM, magnetic disk, and most recently SSD storage, have created a situation where the parts of a computer that the vendor most wants to exploit are the same that the customer covets. Two parties laying claim to a single precious resource can be a recipe for disaster. Fortunately for us customers, RAM, SSD, and hard disks are cheaper than they have ever been. Whether we opt for 64GB, 128GB, or 1TB, we can probably afford to lend the device makers a little space for their virtual ROM.