Volume Number: 15 (1999)
Issue Number: 7
Column Tag: From the Factory Floor

A Conversation with Tim Holmes

By Tim Holmes and Dave Mark, (c)1999 by Metrowerks, Inc., all rights reserved.

This month's Factory Floor interview is with Tim Holmes, Mac OS Technology Manager for Apple Worldwide Developer Relations. Many of you know Tim, if not in person, then certainly by name and by email. Tim offers his insights into the process of transferring technology from Apple to Mac developers throughout the world.

Tim has worked in Apple's Worldwide Developer Relations group for about three and a half years and is coming up on five years at Apple. He previously worked for three years at BMUG, the user group, and served on the BMUG Board of Directors for five. While at BMUG Tim was Editor-in-Chief of the BMUG Newsletter and editor of The Tao of AppleScript. Beyond the walls of Apple, Tim's spare time is mostly consumed by the 25 trees he has to trim, his hot tub, and finding the ultimate brunch cafe in the San Francisco East Bay. Tim can be reached at shortstop@apple.com.

Dave: You are not our typical interviewee here. How do you fit into the Mac OS dev picture?

Tim: Yeah, who am I anyway?

Well, a lot developers out there will know me from my many, many emails. Some will recognize my name from being at the bottom of the Mac OS 8 seed letter for the last three or four years which goes out to the select and premiere developers. And those who attend WWDC know me from the Apple Design Awards as the one on stage in leather pants. There are even some I've met who say "Oh, YOU are shortstop@apple.com."

For those who haven't a clue what I'm talking about, maybe I should answer that in a bit more straightforward fashion.

Let me spell out my position at Apple... I'm the Mac OS Technology Manager. That's "Technology" Manager as opposed to "Partnership" Manager. My role is to work as the representive of our technology to developers, and representative of developers in our technology plans for the future. This is as opposed to representing Apple to a specific market segment, such as Games or Design & Publishing, or to a specific set of developers.

I also do a different job than many of the Technology Managers as I cover a broad set of technologies. Rather than being concentrated on one technology, say QuickTime, or one sort of area, Networking to give a rather broad set of technologies in their own right, I cover the main core of the OS, the Finder, User Experience technologies like Nav Services, Sherlock, as well as File System stuff.

Nearly everyone in Developer Relations works directly with developers at some point, if not constantly, but I'm the person developers contact for issues that don't fall into a specific category. So I get stuff that spans the OS. In addition, many developers know me as someone to contact when they don't know where to turn, so some of my time goes to problem solving specific issues raised by developers or directing such contacts to the appropriate person.

At certain times of the year I get completely wrapped up in events like WWDC, MacHack and so on.

Dave: Why should a developer care about getting on the Mac OS seed list?

Tim: To me that question has always pretty much equated to... "Why should a developer care about the future?" The opportunity is there to get the next OS and see what's changing. It directly affects anyone who makes money putting a product on the market.

There are two big reasons for getting the pre-release versions of the OS: compatibility and technology adoption and there are real benefits aside from those.

If you ship a product on the Mac OS, you want that product to continue to work, obviously. Given that it worked when you shipped it, the time you might really expect that to change is if the OS changes... Well, if you haven't noticed yet, it's changing!

Without getting pre-release versions of the OS how can a developer know if their application will continue to work as expected? Unless your code is perfect you can't, you have to test. And even if your code is perfect, ours might not be. If it's not, we need to know right away to see what we can do about it.

If something isn't happening in the OS the way it's supposed to and you don't tell us, you're risking us shipping that way. Once we know about a problem we can talk with the developer to get whatever information we need to try to reproduce it and see if we can find its source. Incompatibilities make our mutual customers unhappy. We know because they tell us, and we're pretty sure they tell you too.

Apple tests a ton of stuff with the OS, but we'll never be able to test everything on the market. More to the point, even in terms of the software and hardware we do test, we'll never be able to test it with the same depth and knowledge as the authors, the folks who understand what that product is relying on in the OS. That's gotta be done by the developers to do it right. Then, once we've got the bug reports we sort through every one of them. I've said it a hundred times... report bugs, if they get into our internal bug tracking system then they have to be dealt with. They can't slip through the cracks. Every bug gets looked at, every bug gets assigned off to a team to figure out. They can't be ignored.

Side affects of this more widespread testing include a few important to the whole market... Not only does the OS get used and abused by a good deal more individuals, and all their personal habits and quirks, but it exposes the OS to a huge number of hardware and software configurations, so many that we couldn't possibly replicate them all in-house.

This means a more stable OS for everyone, which benefits everyone in real world terms... that means dollars. The OS crashes less, things work as they ought to and our mutual customers love the platform all the more.

Apple seeds the development builds of each operating system release we ship. This has been true for many years obviously. In the past few years we've pushed that process pretty hard within Apple. We now seed from the earliest alpha builds on. This is a significant benefit for developers as the bugs they write into us, and the issues they raise have a much better chance of being solved and implemented better these days since we have more time between initial seed and our ship date than we used to. We also now post several pre-release seeds of the top 7 or 8 languages in addition to US English which are released simultaneously with the US English version.

Getting access to the seed software requires you are a select or premiere member of our programs. Once you have access, you can get whatever the current OS build is and work with it.

It comes down to quality, a quality OS and quality in the developers' products.

The second reason to get the seeds of the OS is technology adoption.

There's a lot of cool stuff coming in the next release. And if you haven't done so yet, there's a bunch of stuff in the recent releases, Mac OS 8.5 and 8.6 which are pretty cool as well.

Apple Help, Navigation Services, new High Level Toolbox controls... a ton more. You can include this stuff in your application and not have to invent it, not have to qualify the underlying code, and not have to ship it and drive the size of your app up, as it's already in the OS. This can be a real benefit and, added to features a developer would put into a rev of their product anyway, can help drive sales for both Apple and the developer. It makes customers happier, especially Mac customers who tend to see adoption of Mac OS specific technologies as a sign of commitment by the developer and a sign that they are really Mac people.

Each seed is posted along with a seed note. The seed note includes lists of bugs fixed, notes on what you should pay special attention to testing, any build-specific notes, and lists all the proposed features intended for this release.

By the way, about the seed note... We're open for suggestions. We've done a lot of work making this seed note useful and informative. It's just text, email, but it's all structured so you can read it quickly and be done with it, while still having all this reference material in it. We just added descriptive summaries to the line item feature list after a few developers said they didn't know enough about the features by just their names... All of it adds up and the details count.

Along with the seed note and the build itself we also seed what come to be known as the pseudo-SDK. This is a collection of all the SDK components that are relevant to the OS release, but since none of them are finished yet, we get them out as early as we reasonably can so developers can work with whatever is available.

Near the beginning this can be a pretty sparse package of stuff, but as the development of the OS goes on, more documentation gets done by the engineers and the techwriters and we ship more info.

All of this stuff is there for developers to start working with. To get the technology and incorporate it if it fits their needs. And to give us feedback on what we're implementing. There's some really cool stuff going into the OS these days that's worth riding the wave of. We really WANT you to take advantage of us...

Dave: Every new Mac OS release includes a fair share of new technologies. Keeping up with all these technologies raises two problems: Will the technology in question still be around a year from now - and how can we afford the staffing needed to keep up with all the new stuff? Comments?

Tim: I think it's worth noting your assumption! "Every new Mac OS release includes a fair share of new technologies." Hey, that's not by accident! If you look back to the time in which Apple was investing heavily in Copland you see a time when the Mac OS wasn't in the fast track. We'd left it behind for the sake of the future. Two to three years ago, if I'd said to a developer, "you'd better staff up because we're going to put out an incredible amount of new stuff and it'll sell like hotcakes," they'd have looked at me like I was an idiot. Trust me...

But today I can sit here and say, "Here it comes! Better staff up NOW!" and they know I'm not kidding. We've been producing significant enhancements to the Mac OS, on-schedule, for the past three, going on four, years. In addition to the obvious user-level stuff like the new appearance, there's significant developer benefits going in, and fixes to stuff developers have wanted fixed for quite some time. But I'm digressing into pushing the OS, which wasn't your question... It's the evangelist in me.

How can they staff up? Well, I can't recruit for them, but Apple is doing a few things which should directly affect that situation. One is pushing into Higher Ed. in a significant way. We've created a student developer level membership and we're working directly with some important Universities. We had a good number of student developer members at WWDC and set up numerous events specifically for them, such as Job Fairs, receptions, special events, etc. This isn't going to get them a new engineer tomorrow, but then again, it is graduation time, maybe it will.

Also the pure numbers of our sales will help to some extent. If we look back, there were engineers who were looking to see if they needed to switch to coding for Windows, and some certainly did. Some are likely to come back, and there are others who are just now entering the market and seeing that the Macintosh platform is a viable healthy one that they can make money working in.

And will the technologies stick? I think Apple has made it pretty clear, and, if not, I'd like to do so now, Carbon will stick, Mac OS X will stick. You don't need to worry about these. We've got a direction and it's a great one.

We have to do the work and prove it and we're doing that now. We're not done, but the path is clearly in the right direction.

Dave: You don't hear the term evangelism out of Apple any more? Why not?

Tim: It's funny because Apple was the first to use the term Evangelism as a position in the industry. We didn't invent it, I hear that was some other industry..., but in high tech we put it into use.

About a year ago Clent Richardson, now Vice President of Apple's Worldwide Developer Relations, came back to Apple to run the the group. One of the first things he did was to hold a meeting with all of us to set some focus. Something we needed pretty badly at the time.

He'd met with Steve Jobs and told us one of the points Steve made about how he saw our organization working. Steve has said pretty clearly that when he began talking with Developers after he came back to Apple they told him over and over that when dealing with Apple by way of Developer Relations it wasn't the technology they had issues with. They were getting that information clearly. What they were having difficulty with was partnering with Apple. They were having problems relating to Apple in a business sense as developers.

Clent knows that how you perceive yourself is how you'll act, so one of the things he changed, to create a more partnering-palatable company, was to rid us of the notion that our jobs were about throwing information out to developers, getting them to adopt, adopt, adopt, and then moving on.

We needed more partnering, working with the developers to create a better platform for them and, in the end, for our customers. We've done a huge amount of listening to our developers over the past couple of years and this can be seen pretty obviously in our OS strategy.

That's not to say we do everything all our developers want us to, it would not only be impossible, but we tend to know more about where we're going in the long run and some of it wouldn't make sense if we did follow that advice.

So, that's the long way of saying that while I will always "evangelize" the Mac, my position is that of Mac OS Technology Manager, not a bad job. It's a mindset more than anything, it's about the developer.