Skip to content
Thoughtful, detailed coverage of everything Apple for 34 years
and the TidBITS Content Network for Apple professionals

Talking Back to Apple at MacHack

Judging from much of the email we at TidBITS receive, many Macintosh owners desperately want to provide feedback to Apple about the Mac OS, Apple’s advertising, Macintosh hardware specifications, hardware color choices, and almost anything else related to Apple. In one respect, Apple should be flattered – the fact that Macintosh users care enough to want to offer their ideas and opinions is impressive. But Apple is a huge company and has no official channel for users to pass on their feedback. The zeitgeist of the industry does filter into the company through indirect means; stories in the press, friends of Apple employees, comments from Apple dealers, the occasional transmission from outer space, and so on.

Part of the problem is simply Apple’s size. Even if there were an email address to which you could send comments (the previous attempt at this, <[email protected]>, appears defunct), it would be difficult for anyone to distribute comments to the appropriate departments, much less the proper people within those departments. Apple has too many employees and too much turnover and movement for anyone to direct feedback effectively.

As much as Apple may not have effective ways of soliciting or managing user feedback, the company does listen, at least sometimes, to Macintosh developers. Apple’s Worldwide Developers Conference (WWDC) offers one forum for that, but Apple’s goal at WWDC is as much to evangelize Apple technologies as to accept feedback on those technologies. But there is another way.

Bash Apple — A long time ago at the MacHack developers conference, there came to be this event called "Bash Apple." As the oral tradition relates, a bunch of developers were sitting around at MacHack bashing on Apple for some stupidity or another. After a bit, one person in the group, a new Apple employee named Jordan Mattson, said, "Look, I’m a nobody at Apple, but I’ll write all this stuff down and when I get back, I’ll see if I can find someone appropriate to tell it to. No promises, no guarantees." And he did, though it was unclear if his efforts had any effect back at Apple. That was immaterial, though, because the developers had had a chance to vent at someone from Apple and, feeling much better, they stayed up the rest of the night writing hacks so useless they produced awe and admiration among the other developers at MacHack (for this year’s hack contest details, see "The MacHack Hack Contest 1999" in TidBITS-488).



The developers so enjoyed having someone at Apple to vent to that they did the same thing the next year, and the year after that. These sessions became formalized under the rubric of "Bash Apple" and grew to include numerous Apple engineers, many of whom had been independent developers in previous years. Jordan even became immortalized in the MacHack argot in the phrase "It’s Jordan’s fault," and though of course essentially none of Apple’s problems actually were Jordan’s fault, he continued to play. The sessions continued to provide a forum for frustrated developers to let off steam, but equally important, they gave Apple folks ammunition to take back and say, "Look, it’s not just me saying this – 200 developers are also ticked off about it."

Apple Handshake 1999 — In recent years, Bash Apple (saddled this year with the horrible moniker "Apple Handshake Session") has evolved to the point where a senior Apple person fields questions and criticisms from developers, backed up by various other Apple folks in attendance. This past MacHack in June (see "MacHack: The Ultimate Macintosh Event" in TidBITS-487) was no exception, with Apple’s vice president of Mac OS engineering, Steve Glass, fielding most questions with assistance from other Apple employees. For instance, in response to a question regarding whether Apple planned to release any more Appearance themes, Apple evangelist Tim Holmes stated unequivocally, "As I’ve said numerous times in numerous places, there is no future for themes. None, nada, zip, zero," and sat down, only to bounce to his feet a second later to reiterate the more carefully phrased, and officially blessed version, "Apple Computer has no plans to offer additional themes, either now or in the future, but the company reserves the right to change its mind, blah, blah, blah."


Every now and then during the session, important bits of information either became public or were emphasized. For example, Steve Glass was adamant about how he was clamping down on shipping independent components of the Mac OS separately from full Mac OS releases. He felt that shipping different versions of Open Transport, for instance, separately from the Mac OS itself made for configuration and testing nightmares; plus it could cause problems for users who were mixing and matching components in combinations that Apple hadn’t tested. In addition, in response to another query, Tim Holmes made the important point that although Mac OS 9 will have multiple user support in the sense of both individual and shared preferences, the feature is aimed at home and small office users, not large installations with many users.

For the most part, though, I got the impression that developers weren’t entirely happy with the session, perhaps because even though they were talking with an Apple VP, he wasn’t able to be concrete about much. Steve Glass could and did respond to issues surrounding Mac OS 8.x, since that’s his team. He was also able to offer standard industry platitudes about concerns that either were outside his field (Mac OS X, hardware) or that undoubtedly are not yet even decided at Apple. Trade-offs, resource allocation, ship time, investigating the issue now… all of these meaningless phrases came forth at one time or another. But what should he have said? The problem with those industry platitudes is that they’re often true – there are trade-offs between offering individual component releases versus unified system releases; Apple does have to pay attention to how they allocate engineering resources to future projects versus maintaining backward compatibility to System 7.x; and so on. In short, Steve Glass was incapable, through no fault of his own, to offer any sort of official assurances about how, for example, Steve Jobs may have traded his soul and a total lack of commitment for Java 2 for Apple’s recovery. Even if Steve Glass knew that Apple had decided to ignore Java 2, he wouldn’t break the news at MacHack.

Top Ten Developer Issues — In the last few years, the organizers of MacHack decided to create a list of the top ten developer issues, rightly believing that it would be easier for the press to write about than a two-hour Q&A session. The list, voted on by the gathered attendees, was an attempt to collect and prioritize the concerns held by the Macintosh development community. Here then is a slightly edited version of this year’s list, with links to relevant TidBITS articles where possible.

1) MacsBug support: The MacsBug debugger is a critical Macintosh development tool. Developers need Apple to dedicate engineering resources to this tool and to new ones like it. If you’re interested in what it can do for you, check out Geoff Duncan’s three-part series on MacsBug.


2) Greater stability and easier debugging: Developers need increased reliability and greater ease in debugging software on Mac OS. Apple has done a good job of improving stability since System 7, but more stability is always welcome.

3) Mac OS X look and feel: Developers want Mac OS X to look like a Macintosh, not like a Unix workstation. We touched on this topic with "Mac OS X or Mac OS NeXT?" in TidBITS-483.


4) Documentation improvements: Developers need technical documentation to be available sooner, and to be more complete, accurate, and accessible. Although our "Death of Documentation" article focused on user documentation, many of the issues are similar.


5) Better mouse and keyboard: Developers believe that high-end Macs need a better standard mouse and keyboard with a full set of keys. Smaller is not always better with keyboards. Amazingly, the new Power Macintosh G4 does not include an improved keyboard and mouse.

6) Machine differentiation for support needs: Developers need Macs to be more clearly marked because support staffers need to identify users’ machines easily. I raised this issue at the session and was gratified to see that developers shared my concern. See "Macintosh Model Implosion: What’s in a Name?" in TidBITS-485.


7) Extending the OS: The "patching" mechanism for extending the Mac OS in unplanned ways is important for many reasons, including providing disability access. Developers need a similar mechanism in Mac OS X.

8) Cleaning up Mac OS: Developers believe that Mac OS would benefit from being further cleaned up. Removing vestigial code from the OS would improve memory footprint and performance, including faster booting.

9) Java: Developers need a clear direction on Java. A commitment from Apple regarding support for Java and Java 2 would be greatly beneficial.

10) Release discontinued development tools as open source: Many developers still rely on tools that Apple no longer supports, like MPW. Releasing such tools as open source would allow developers to maintain and improve the tools they find essential.

Tracking the Feedback — One aspect of this year’s Bash Apple session that was missing was a recap of the previous year’s Top 10 list. It’s instructive to see both how Apple has responded to items on the list and how developers’ opinions of what’s important changes from year to year. I’ll be sure to see how this year’s list fares at MacHack 2000, by which time we might have various new Macs, Mac OS X, and inconceivable policy changes from Apple.

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For over 33 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

This site is protected by reCAPTCHA. The Google Privacy Policy and Terms of Service apply.