Hypercritical

Paths in the grass

We have created, for the first time in all history, a garden of pure ideology.

by

Last month there was another flare-up in the eternally simmering Mac OS X system extensions debate. This time, it wasn’t a “haxie,” which is a what Unsanity calls its products that run on top of its Application Enhancer (APE) framework. Instead, it was an application that shipped with a system extension called Smart Crash Reports (yes, also made by Unsanity) that leverages the Input Manager mechanism in Mac OS X. Okay, maybe “subverts” is a more apt description, depending on your point of view. But I’ll get to that in a bit.

Anyway, the discussion followed the now-familiar pattern of blog-based conflict resolution. First there was the initial post describing the situation and warning Mac users about it. Then came comments from the usual suspects: a developer of the offending application, someone from Unsanity, and a gaggle of supporters and detractors from all over the web.

The comments went into a bit of a death spiral, and were subsequently disabled by the owner of the blog. A follow-up post more calmly summarized the situation. A week or so later, John Gruber provided an exhaustive exploration of the topic. Smart Crash Reports itself was eventually modified by Unsanity. Finally, Gruber wrapped it all up with an addendum to his earlier post.

This little scuffle reminded me that I’d been meaning to post about the whole system extension debate for a while. So I added an item to my “Blog Ideas” list in Yojimbo…where it stewed with the others for a few weeks. But here I am now, actually posting something for a change, so it’s time to dive in.

The way I see it, There are four stake-holders in the system extensions debate.

There’s an inherent tension between the needs of these groups. When I read any position that focuses on the needs of just one of them, I am immediately suspicious. This issue is simply too complex for an absolutist viewpoint to be accepted without a vigorous defense that acknowledges the needs of all the other stake-holders and convincingly explains why they are all outweighed by the needs of just one. Such a defense is rarely even attempted, let alone successfully executed.

This is why extreme positions always jump out at me as “almost certainly wrong.” Here’s an excerpt from a comment by John C. Randolph in the original blog post about Smart Crash Reports.

Speaking as the person who took all the Cocoa [Developer Technical Support] incidents for about a year, I will go on the record as saying that haxies were a very bad idea from the beginning, and I hope that Apple is investigating ways to render them impossible altogether.

I don’t mean to pick on one particular person or opinion. There are extreme views on all sides of this debate. John’s comment just happens to be the best example of what I’m talking about (i.e., the most extreme) in this particular online scuffle.

The excerpt above goes beyond just saying that running system extensions is a bad idea. It calls for Apple to actively attempt to thwart system extensions, to prevent them from working at all. That’s definitely what I’d call an absolutist viewpoint.

(Let me preface my next statement by saying that I cringe at the off-topic comments it may lead to. But hey, no guts, no glory, right?)

This extreme position on haxies and other system extensions is wrong for the same reason that socialism, communism, and libertarianism are, in the long run, nonviable forms of large-scale governance. It attempts to arrive at a solution by changing the nature of the participants. This will never work.

Any viable solution must work within the (often inconvenient) bounds of reality. It must be constructed in such a way that the motivations and actions of the participants—both the good and the bad…especially the bad—serve to balance the system as a whole. Suggesting that all would be well, if only certain people would act differently or alter their desires in some way is wishful thinking, not an actual solution.

I hesitate to pursue the political analogy much further, so I’ll go right to haxies themselves for a concrete example. Let’s suppose that some people want the ability to make an entire window except for the title bar become invisible. Let’s further suppose that the only way for anyone other than Apple to provide such a feature is through the use of a haxie or other form of system extension.

We all know that haxies have the potential to destabilize a Mac OS X system. No one benefits from a less stable computing environment: not Apple, not traditional application developers, not system extension developers, and certainly not users. So we have a problem. Here are some sentiments that suggest completely nonviable solutions.

It should be blindly obvious which stake-holders are left out in the cold in each of those “solutions.” But if you’re entrenched deeply enough in one of the other camps, it’s possible to go quite blind. Consider John C. Randolph’s comments again. He used to do developer support for Apple. Haxies caused him no end of grief in this role. Under such conditions, it’s easy to see how all other considerations could fade away, leaving only the imperative need to solve the “local” problem.

In this light, the sentiments listed above start to acquire a certain ring of truth, even righteousness. But absolute surety on this issue is a clear sign that you’re off the reservation. It’s almost trivial to completely satisfy any single stake-holder in the haxie debate. It’s nearly as easy to convince yourself that such a solution also adequately addresses all other parties, if only they’d do X or come to understand Y.

Yes, and if wishes were horses, beggars would ride.

The hard truth is that there will always—always—be features that a significant number of Mac users want, but that cannot be implemented using standard APIs in the expected manner. Certain features cut across traditional application boundaries, and these kinds of features are often perversely desirable to users.

Accepting this reality is step one on the path to haxie enlightenment. There is no magic bullet, no Grand Unified Solution that solves everyone’s problems. And the big spoilers, the stake-holders that ruin it for everyone, are the users.

People are inscrutable; Mac users, doubly so. Their computing desires follow suit. You can waste all the time and energy you want explaining why some feature is dumb or foolish or will actually make the people who use it less effective or efficient or whatever objective metric you’re using to judge such things. But if it makes someone happy, you’re sunk. Argument over.

Given this, Apple can’t possibly satisfy all possible feature requests, nor can it reasonably provide officially sanctioned facilities for third-parties to do so. There are simply too many users, too many different hearts and minds, and too many possible features.

The best we can hope for is a compromise, a (perhaps uneasy) truce that satisfies all parties to the fullest extent possible. Ideally, this compromise will be self-balancing, this truce self-sustaining. To achieve this, all parties must be allowed to be true to themselves.

Apple and application developers are still going to want a stable, predictable environment for their software. Users will still harbor their quirky desires for features of all kinds. System extension developers will still step in to implement the features that users want that simply cannot be done any other way. Despite all this, the computing environment must not become too destabilized because that hurts everyone.

Although the bulk of the blame for this conundrum lies with those inscrutable users, the power to strike the right balance for a good compromise lies almost entirely with Apple. Yes, it’s impossible for Apple to ever provide “clean hooks” for all of the features that users might want, but a few judicious choices can address the needs of most users with minimal effort. In other words, instead of wasting time addressing the needs of a million different users who want a million different features, Apple can find the handful of features that are demanded by the largest number of users and implement (or provide clean hooks for) just those features.

Okay, sure, but which features are those, exactly? That’s where haxies come in. Allow me to shamelessly steal from Larry Wall as I explain by way of this this slightly modified analogy.

When the University of California at Irvine campus was first built, they just put the buildings in. They did not put in any sidewalks; they just planted grass. The next year, they came back and built the sidewalks where the trails were in the grass. That’s what haxies are to the Mac software market. Haxies are those paths in the grass.

The existence and popularity of particular haxies and other system extensions lays out, in concrete terms, exactly which features are in demand. If someone goes through the trouble of creating and then supporting a system extension that provides a certain feature, and a significant number of users are willing to spend money—and, in many cases, willingly compromise the stability of their systems—to get this feature, then that’s a pretty good sign that this feature is a “high-value target” for Apple.

The not-so-invisible hand of the market is showing Apple the way. Want to eliminate, say, half of all haxie-related developer support issues? Want to stop thousands, perhaps millions of Mac users from running haxies? Start by adding a window shade feature to Mac OS X. Want to expend a little more effort to future-proof the solution and, at the same time, avoid stepping on Unsanity’s toes? Then provide a clean, officially supported way for third-party developers to implement custom window minimization behaviors.

And so on, for each of the most popular system extensions. I just picked window shade as a seat-of-the-pants example. I don’t know Unsanity’s, or any other system extension developers' sales figures for individual products. But any Mac user engaged in the community should have a rough feel for which are the most popular. And remember, regardless of sales figures, the mere existence of one of these products is a sign that there is some minimum level of interest—a significant level, I’d say, given all the drawbacks.

Make no mistake, the downsides of system extensions are felt by all parties, including the users and the system extensions developers themselves. Keeping a haxie working across OS updates and architecture changes is hard work for developers like Unsanity. Similarly, the potential for instability and future incompatibility is a constant burden on the user. How can such self-inflicted punishment be justified?

It’s a simple case of supply and demand, cost and benefit. Developers like Unsanity are not creating system extensions in order to be 133+ H4X0RZ. If there were any other, safer way to implement these features, Unsanity would jump all over it. And the people who buy haxies are not trying to make a statement or prove a point. They just want the features, period. They want them so badly that they’re willing to risk the stability of their systems to get them! With this kind of demand, is it any wonder that the market has produced a supply?

Anyway, let me try to wrap this up. You may disagree with the particulars of my examples, or you may consider the current balance of haxies, built-in OS features, and “clean hooks” to be optimal. That’s fine. What I really want to get across is the idea that such a balance is necessary, and that there is no viable “winner take all” solution. There is only a continuum of possible compromises.

Ignorance or denial of this reality helps no one, and is especially damaging when perpetrated by the one party with the power to change things for the better. If Apple is not constantly and honestly considering which features currently implemented with haxies should be either rolled into the OS or exposed via officially supported APIs, then all is lost. No amount of preaching to users or yelling at developers is going to make things better.

Debating the appropriate balance between Apple, developers, and users is fine. Attempting to entirely subjugate any single party is pointless. In the context of this debate, haxies are the symptom, not the problem. Remember this the next time there’s a haxie-related flare-up in ye olde blogosphere.

This article originally appeared at Ars Technica. It is reproduced here with permission.