Converstion Tim Holmes
Volume Number: 15
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.