Garry Hornbuckle, DevTech Leader

By Dave Mark

This month’s interview is with Garry Hornbuckle, manager of Apple’s Developer Technology Services Group. You may recall that, two months ago, this column featured Heidi Roizen, Vice President of Apple Developer Relations (ADR), and that Heidi introduced Garry’s group. Here, we’ll take a closer look at its various activities.

Dave: Tell me about Developer Technology Services.

Garry: Our overall mission in DevTech is to design, develop, and deliver the technical information, services, and systems needed by developers to be successful with Apple technologies. This group includes the teams from Developer University (DU), Developer Press (DP), and Developer Technical Support (DTS).

Bringing these three teams together organizationally is a reflection of one of my key goals for improving the technical proposition for our developers. Individually, the past efforts of these groups have ranged from pretty good to excellent. We’ve had award-winning technical documentation, for example. But we haven’t been good enough at integrating each of these information delivery channels. Supporting developers technically is, after all, a life-cycle. If we do a poor job with documentation or with training, we have to expect decreased technology adoption, or increased technical support requests, or both. But if we do a great job with documentation and training, we can look forward to greater technology adoption, and to better, more focused support questions. That means faster turnaround times and crisper responses for developers from DTS, and that means that developers can get back to coding more quickly. And now, we’re talking about improving the business proposition!

In addition to those three groups, DevTech consolidates world-wide responsibility for Apple’s third-party compatibility labs with our developer training facilities. We expect that this will allow us to better equip labs world-wide, utilize facilities, and coordinate with the prototype hardware seeding program managed in ADR Evangelism.

Finally, DevTech includes a “systems” group to provide IS&T services across ADR and to our developers. Most visibly, this includes Apple’s presence for developers on the Internet. We’ve been moving rapidly to leverage Web technology for distributing information, and there’s lots more on the way.

Dave: The Windows universe is undeniably larger, and many people say that Microsoft’s Developer program is better than Apple’s (and it’s free, I believe). What ammunition can you give to Mac developers trying to persuade their bosses (and possibly themselves) to keep their focus on the Mac?

Garry: First off, I’m not going to take any shots at Microsoft or at Windows. They’re an important developer on the Mac platform, and today’s business proposition is largely cross-platform.

That said, Apple has to offer a compelling business and technology proposition on the Mac OS to attract and retain developers. I believe that most of the coolest, most innovative technology appears on the Mac platform first - sometimes from Apple (such as QuickTime), and sometimes from developers (there are many examples). But cool technology is valuable only if we enable developers to access, understand, and effectively apply the technology to their product. That’s where my group comes in, with a goal of providing the best possible documentation, training, sample code, and technical support.

Other parts of ADR are chartered with other parts of the platform proposition: marketing with and for developers, providing access to market information, offering strong developer programs, and so forth.

What’s free and what’s not? An easy question to answer in general, but much harder to answer specifically. In general, Apple should not and does not view developers as a profit center. They should be, and are, seen as an investment in our future, as their success and our success are completely interlinked. Does that mean that all developer support programs and services should be free? Well, it’s a goal for ADR to offer the best possible support to the broadest possible audience. But I don’t think that means “one size fits all” in terms of support needs, nor do I think that every support option we might offer to developers will have the same perceived value.

To me, the bottom line is value. If the value of what we provide to a developer is worth (or exceeds) the cost to the developer (which might or might not be zero), then we have a win-win. If we have a program or service where the value proposition is not right (it costs too much for what you get), then we need to fix that. That may be done by lowering the price, by increasing the value of the content, or through some combination of both.

Dave: Right now, trying to master a specific Mac technology means tracking down a series of Tech Notes, juggling multiple Inside Macintosh volumes, hunting for obscure (and often unpublicized) emails from DTS, plus searching through comp.sys.mac.programming. You get the idea. How will you help ease this learning curve?

Garry: You’re right. This has been a problem. As the Mac OS platform has gotten more and more complex, we’ve had a hard time keeping our documentation, training, and support strategies synchronized with each other and with R&D engineering. As I mentioned earlier, this is one of my top priorities this year in this new job. The first step is a reorganization such that all of our written technical content is managed by a single organization. That means that there’s a specific human being whose neck is on the line to make this better. - And it happens to be me... (Laughs)

Of course, another part of the answer is technology. We are rapidly getting all of our technical content up on the Web, in a searchable form. That’s got to help. We are also rolling out interactive developer training on the Web. In fact, there are four DU classes on the Web now (including an introduction to MacOS 8), with several more scheduled to be ready and online before the end of this year. We are also working on using Internet chat to support Web-based training, so you’ll be able to interact with an instructor, live, in real time, without leaving your office.

We’ve got a number of DTS engineers who, just because they are amazing and cool people, hang out on the net, in c.s.m.p., or on AOL, or elsewhere, answering questions. We’re working with Apple IS&T to complete the internal transition to Internet technologies. As our infrastructure gets better, you’ll see more of this, not less.

Dave: How about the path from DTS to documentation? Will you do anything to help cause the answers provided by DTS to migrate into Inside Macintosh?

Garry: DTS has been great about turning important questions with broad interest into Tech Notes. What we haven’t done in the past is to have a well-defined path by which Tech Notes “grow up” to become more formal documentation. So there was a separate Tech Note index, and revisions to Tech Notes, etc. Why not just have Tech Note content integrated with the reference materials on a regular basis, you have to ask. And that’s the direction we’re pushing.

That doesn’t mean that Tech Notes aren’t valuable; they are. But their core value is that they are quick turnaround, and accurate enough to get the job done. They may not have perfect grammar or style, and they may not meet other standards for Apple technical documentation, but they are quick enough, and good enough. We don’t want to lose that, but I do want them to become incorporated much more quickly into our reference documentation such as IM.

Dave: What is the future of Inside Macintosh? Given the dynamic nature of Apple technology, will Apple’s official documentation continue to be a batch series that gets updated only every few years?

Garry: As we have started our move from “paper-first” to electronic publishing and online content delivery, we’ve also been reworking our internal processes. Before, things were oriented around a large project, delivered in print - for example, an IM volume. We’re now pushing for a model that is based on smaller chunks of work that are continuously “pipelined” through the electronic publishing process. IM itself is a huge challenge, but one that we are going to tackle. It’s too soon for me to know what I can promise, and by when. But if you look at the process we are now using to write seeding documentation for prototype hardware, you’ll see that we’re ready to move on this. You’ll also see Inside Mac on the Web, probably by the time this interview is published.

Dave: How about tracking bugs on the Internet? Will there be a mechanism for finding out if what I suspect is a bug is already known?

Garry: We’re now beta-testing and making final tweaks to a brand new system that exports Apple’s internal bug reporting and tracking system, called Radar, to the Web. Internally we call the result RadarWeb, though I think we’ll probably introduce it as the Apple Bug Tracking System. Using RadarWeb, developers will be able to view a list of known bugs across several technologies, including Mac OS 8, ETO, and System Update, with more planned as we go forward. In addition, developers will be able to submit new bug reports against these technologies, and track their bug through the various stages to its resolution. Rollout of RadarWeb is planned to accompany the DR1 release of Mac OS 8. And before you ask: no, I don’t have new information to share about DR1 availability - but remember that we’re keeping the Mac OS 8 developer Web site updated with new information as it becomes available:

http://www.macos.apple.com/macos8/dev/devworld.html

Dave: Apple’s current developer Web presence is slow. What changes do you have in store?

Garry: We’re making a significant investment to upgrade our internet infrastructure; this includes working out world-wide mirror sites, getting bigger, faster, and more numerous servers, routers, and pipes, and thinking much more carefully about the way in which we organize our content, so that it takes less time to find what you need. And, as I mentioned earlier, I’ve also created the ADR Systems group, with a specific manager held accountable for keeping pace with the demands for Apple-developer Web-based communications. You get a lot of focus on a problem when there is a directly responsible person.

Dave: What will you do for folks who don’t have access (or have only slow access) to the Web?

Garry: We are moving strongly to the Internet and Web as our main focus, but the Web is not everywhere, for everyone, at least not yet. So we will continue to use other media for content distribution and communications, based on local conditions and options. Print and CD in particular will continue to play an important role. In Beijiing, we do tech support by fax. So it really depends on the specific situation.

Dave: What is the future of Apple’s various disk-based document types for documentation? We see Acrobat, DocMaker, MS Word, SimpleText, and even HyperCard. Is there a final word?

Garry: (Sighs) No final word, but a current plan. If only all of you could agree on a single choice! And if the discussion of the pros and cons on Semper.Fi is any indication, we’re not at all close to that goal.

Seriously, we’re going to produce documentation in multiple formats for now. There are various reasons for using some of these different tools, and each is valid in its own context. There are some incremental costs incurred in doing this, and I would really like to squeeze these out. But with good automated tools, the incremental costs needed in order to output QuickView in addition to HTML, for example, are not that great.

Dave: Are there plans for expanding Apple’s storehouse of sample code?

Garry: I hear this request all the time, and yes, we are planning to expand in several ways.

Our first step is to take stock of what we have (almost complete), and to get a real source code control system into place (scheduled for Q4 CY96). At the same time, we need to get a process and resources in place to make sure that all of the sample code compiles every time we update system headers, etc. Then we get all of the documentation efforts to reference into this sample code library, so that the examples you read about are available, and the examples you discover online are documented. Then, we’ll start writing and collecting and publishing even more examples. Of course, DTS and the documentation group will continue to create sample code on a day-to-day basis as they do now. But I want to dramatically improve our sample code library in the future, including making it searchable on the Web.

Dave: What about the famous twenty million dollars that Gil gave Heidi? Do you get any of it? If so, what are you going to do with it?

Garry: If I had one dollar for every time someone asked me about the $20M, well, I’d have $20M! - Right. Apple has allocated $20M over the next twelve months to help developers get their products in front of customers. This money will be spent roughly half in the US and Canada and half in Apple’s markets outside the US. All of Heidi’s team are working on programs now that will best leverage this money in both the traditional channel as well as in some emerging channels.

The funding is likely to be split among channel initiatives, “virtual” and Internet initiatives, co-marketing and collateral materials, and some pull advertising. In order to maximize the leverage, we aren’t going to be looking at specific proposals from developers, but rather to take their input and create a few standard programs that can either be shared by all, be “pay-to-play”, or be targeted to particular segments of the market. That said, we are looking at some new and expanded support services and options in DevTech as well - things like the expanded sample code library service, for example, improved compatibility lab access, and more.

Dave: People on the West coast have great access to Apple’s compatibility labs. What are you doing for the rest of us?

Garry: This is a harder problem to solve than some, but consolidating ADR labs and the Cupertino third-party compatibility lab group is the right first step. Next, we need to work much more closely with Evangelism to coordinate the availability of prototype hardware in our labs. We’ve just brought the Munich lab up; this should help European developers some. We’re now looking into the next priorities - a possible second lab in the US (probably in Boston), a lab in southeast Asia, and a lab in Latin America.

Since we are still in the planning stage, and our FY97 budgets are not nailed down yet, I can’t promise how this will come out. But I think that it would probably save Apple money and would be a strong benefit to developers if we could assure world-wide lab capacity, including old and new hardware, rather than having too few prototype machines to ship around for too few days at each location.

Dave: What is your vision for the future of Apple Developer Relations? How does this impact the smaller developer?

Garry: I have two major goals for my new job. The first I’ve already talked about - getting our technical content and services integrated into a life-cycle approach to communications with developers. The second is extending the range of developers’ needs that we can address. Access to technical information and support options should be there for any developer interested in our platform. Some will be free, some will be pay-to-play. But I’d hate to see anyone turned away because they “didn’t fit the mold”.

If you think of DTS as the middle of the support spectrum (predominantly but not exclusively mainstream, commercial, etc.), then we need to broaden in two directions. First, “downward” to reach out to the larger number of casual developers, hobbyists, students, etc. Second, “upward” to smaller but significant numbers of strategic opportunities that require rapid response and the highest level of expertise. We have plans on the FY97 drawing board for new services in both of these areas, and I am very hopeful that we’ll successfully launch new support offerings this year.

To check out the fruits of Garry and Apple’s labor, including Inside Mac online, check out:

http://www.devworld.com/

-ed/wgi