Scott Holdaway, Gobe Software Interview by Henry Bortman HB: Tell me a little bit about how Gobe got started. SH: Five of us were all ClarisWorks engineers. There was this whole fiasco with OpenDoc. It's actually a very long story, if you want all the ins and outs. HB: I'm game. SH: OK. Well, basically the ClarisWorks codebase was started in '89 by Bob Hearn and myself, and we sold it back to Claris, but it was getting a little bit long in the tooth. There were some things that it just didn't adapt well to and OpenDoc was one of them. OpenDoc made all these assumptions about how things were coded, which were kind of reasonable for an object-oriented program, which ClarisWorks was not. We told management that it just wasn't going to work trying to put OpenDoc support into ClarisWorks, especially not without doing a lot of rewriting first. And they said, well, too bad, do it anyway. (Bob actually had already left Claris.) And so we tried to put it in there, the support for OpenDoc. It was very difficult. We had three people in Dallas who were doing most of the OpenDoc-related coding and I was pretty much telling them how they had to do it in order to work with ClarisWorks. There was this OpenDoc library that they were trying to manage, which was kind of a hack to begin with, but then Microsoft actually hired those three people away. I don't know whether there was any intent on that or not. Actually, our manager, Don Bradford, had quit Claris over a dispute when they fired the vice president of engineering, Larry Slotnik, at Claris, who everyone really liked. So Don had gone to work for Microsoft. And he hired these three people away from us. Don Bradford was heading up the Macintosh Internet Explorer group, so we were left kind of holding the bag on the OpenDoc stuff. I think we were there for another two or three months before we finally just said we've really had enough of it and decided we wanted to go out on our own. HB: Was OpenDoc a good idea that just didn't work with ClarisWorks, or was it a good idea poorly done? SH: It was a good idea, it was certainly poorly done, but it still could have worked in a different codebase. They had like up to 100 people-engineers, testing, and support and all that-working on OpenDoc. That's too many people. Anytime you have that many people starting something like that, it's usually poorly done. They had too many compromises in their design, or just lack of foresight. Integrating it into ClarisWorks was certainly a huge problem. It was not made to be integrated into existing programs like, say, OLE was. Not that supporting OLE is particularly easy either. In fact, the three people in Dallas had done OLE support for ClarisWorks for Windows. I think they were up to the task, it was going to be a very hard task, and given all the bad feelings that started with Don being fired and hiring those three away, we needed a break. It had gotten to the point that I didn't enjoy working anymore, and three of us were going to leave no matter what. And when we did, the two others decided to join us. It was at that point that we decided we'd go try Be Software for awhile. HB: Why Be Software? It clearly wasn't a market-driven decision. SH: At the time we left it was when Apple had killed Copland, but they had not bought NeXT yet. In retrospect it seems like that would be something they would consider doing. But we thought they would be buying Be, so we thought we would get a leg up. Four months into it all this stuff with NeXT happened, and we saw that [buying Be] wasn't going to happen. But we had gotten enough into BeOS that we really appreciated it for the APIs that were there and the potential-it's not there yet, but we see a great potential at least-so we decided to stick with it. HB: What's the potential that you see in the OS? SH: A fully modern OS where you're not carrying all the baggage around from the last 10 years of compromises and lack of foresight. Incremental changes, that kind of thing. All the APIs from C++ were easy to learn and, for the most part, pretty well designed. So, from the programmer's point of view, it was pretty attractive. I think one of the real bright spots for BeOS, even though we're all mostly coming from the Mac community and have been Mac bigots all our lives-at least all our programmer lives-is that running on the Intel hardware opens up a lot of possibilities where people are willing to install BeOS on their Intel hardware and give BeOS applications a chance. Whereas if you're developing for the MacOS you may not get that opportunity. It depends on how successful they are with MacOS X. Apple's been marginalized by the business community for so long now, it's kind of depressing actually. I want Be to be successful, but I still want Apple to be successful as well. We're honest amongst ourselves that BeOS may not be around three, four years down the road. It think it will be around that long no matter what. And if they do their job well, there's a good chance that three or four years from now they'll have more users than the Mac has. The real question is whether they can get the polish on the OS that's missing and then get the applications out there that make it compelling. In and of itself, we don't expect Gobe Productive to be the application that causes people to switch to BeOS. We'd like to think that, but we're not that naïve. It's just office productivity software. But, I think we can deliver something at a price point that will be compelling. I think we can deliver features that you can't get in other software that some people will find very interesting. A lot of people might not find them compelling enough to switch, but people will find them interesting. We're hoping that someone else will have some more compelling applications. It's not that we're not going to try to deliver-we'll do whatever we can-but you have to be able to do something that you just plain can't do with other software. It can't be just something on a different OS, it can't be just something that's easier to do. That's usually not enough to get people to switch. Otherwise, everyone would have been using MacOS a long time ago. HB: You do want to make some money doing this, though, don't you? SH: I can't deny that making good money, it's attractive. But at this point, after you get enough money to satisfy all of your needs-and depending on what kind of person you are, that could be a lot-but after you've done that, the money thing, that's not what motivates me. It motivates most of the other people, except maybe Bob to a certain extent. But we're all still motivated in trying to produce something that we can be proud of, to look out into the world and see people using our software. I think that was the biggest kick on ClarisWorks-to just be out somewhere like Texas, where most of us grew up, and run into someone who asks what you do for a living, and you say, "I write ClarisWorks software," and they say, "Oh, yeah, I use that." It's just kind of fun. I think most programmers get a kick out of that kind of thing. HB: What are some of the features you're hoping to put into future versions of Gobe Productive? SH: A lot of them are just things that you'd expect, like wrapping text around graphics, stuff that everyone's seen in other programs that we don't have yet. Some of the other things that we have some support for, Scott Lindsey's working on our scripting. I don't know what kind of time frame that's going to be in, but the infrastructure of all our code right now is very message-based. This is very unlike ClarisWorks. For the most part, right now, if you knew the proper protocols-and maybe we'll publish them even if our scripting support isn't real high in our next version-but if you knew the proper protocols on messages to send, you could pretty much get Gobe Productive to do anything programmatically that you can do as a user. At this point, most of that is there, we just need to put a scripting interface on top of it. The BeOS scripting stuff is a little raw at this point. I'm not sure exactly how that will develop, whether that will be in 2.0 or later, but I suppose even if it isn't in 2.0, there's a pretty good chance we'll publish our message protocol so that if somebody wants to write something to get Gobe Productive to do something, they can. Probably the biggest difference between ClarisWorks and Gobe Productive is that everything, all the frames and parts, are plug-ins. At this point it's only set up so that we can easily write new parts and frames and drop them in and have everything work. That was not at all true in ClarisWorks when you wanted to add something. When we added the paint module in 2.0, that was kind of a major undertaking. We're going to-this is planned for 2.0-we'll have an abstract API so that people will be able to write parts that will communicate with our internal architecture, so that if we need to we can change our internal architecture without breaking third-party parts. HB: The user interface for Gobe Productive has some interface elements that aren't standard for BeOS, such as the toolbar. What were you were trying to accomplish with the UI you designed? SH: Well, there were a couple of factors that went into deciding to put all the formatting things in a little toolbar. Hopefully, in the future it will be more customizable, but not everyone likes that. There was a time when I don't think I liked that, either. There are a lot of people who find that really handy, so at the very least, we wanted it to be an option. But the other thing that we found in ClarisWorks was that some of those menus, like the font menu and other formatting things, they tended to jump around depending on what you were doing. If you were in graphics you had your graphic menus in one place, in word processing they'd be in another, and if you were in a spreadsheet, they'd be in a third. I think that was one of the things that confused ClarisWorks users more than almost anything in ClarisWorks, so we wanted to standardize where those things were. If you just say, well, I'm always going to have a Font menu in my menu bar and a Size menu and Style menu, which is what you'd expect if you're doing word processing-at least Word has maybe two of those-you can say that. But for some types of parts, eating up that much menu bar space is not necessarily appropriate. You might have more menus that you need there, so you don't want to see those menus there. I haven't decided whether putting them in the toolbar without customization capabilities is necessarily the right approach. We do eat up a little more screen real estate at the top of the window than I'm completely comfortable with. Monitors are getting bigger, so that is helpful. We definitely didn't want those things jumping around because you're just working along and sometimes you forget what's active, you're not really thinking about it, you're not thinking "I'm editing a text document," you're thinking "I want to change my font," or "I've got a text object selected." We really wanted to get away from that, where it jumps around. HB: How does developing an application for BeOS compare to writing for the MacOS or Windows? SH: It's a lot easier when you know there's some functionality in the OS. You're not sure what it's called, but you know the functionality is there somewhere, or at least you think it is. Under BeOS, if you're trying to figure out what it is you need to do to utilize that functionality, you know that when you're trying to do something with a menu, you need to have a menu object and you look through all the methods for the menu object at once and see the various possibilities that the operating system supports. So, it's a lot easier to find how to do something if you just don't remember or you've never used it before. It's a lot easier to track it down and figure out how to do it. The learning curve is much more shallow, at least once you know object-oriented programming. It's a little bit steeper if you don't know any of the concepts behind object-oriented programming. Windows, I don't have a lot of Windows experience, but from what I've seen, it's kind of a strange beast because they usually have about three or four APIs for doing the same thing. It seems like you almost had to be there when it evolved to know why there are all these APIs for doing the same thing and which one is the right API for you. Maybe that's just an outsider's point of view because like I said, I've never really done any Windows programming, but that's kind of what I see. HB: So is development quicker on BeOS? SH: It is up until when you're actually trying to finish. At this point, when you're actually wanting to ship it to real end-users, that point gets a little slower right now because the print drivers are just not well tested, and it still needs a lot of work. I'm sure Be is working on getting those things fixed. It's hard to know sometimes what all the bugs are in print software unless you have a lot of applications trying to use it. Some of that stuff at the end is actually quite a bit harder because you're trying to get your program to print well and you're running into all these OS bugs and that can be a little frustrating. HB: How is Be about responding to those things? SH: Oh, they're much better than Apple ever was. At Claris, especially working on ClarisWorks, which was one of the more widely used pieces of software on the Mac, you'd think that they would be responsive to our questions-why doesn't this work right, is there any way to work around this bug-and it didn't really work out that way. In fact, I think Apple was always worried about showing favoritism to Claris since they own Claris and so they always kind of bent over backwards to make sure that we did not get more support than some third-party developer, but we often got less. That was frustrating at times. Be's been really quite good about addressing our concerns. They're adding things to R4 that are in there just because we complained about this or that or some other thing. It's nice to be able to influence the maker of the OS. If we ask for something and they say you don't really need that, if we can't convince them that this is something that is really essential for us, then we just haven't been persuasive enough. But at least they listen to us and there's the possibility of them actually adding a few things to R4 specifically as a result of their conversations with us. Granted, it's not a mature OS yet, so there's a lot more ground for things that need to be added. But they're very responsive. HB: What's the coolest thing about Gobe Productive? SH: The coolest thing is actually not in 1.0, it will hopefully be coming out in 2.0. But, the image processing part, hopefully this will actually see the light of day. Scott Lindsey now has it. There's a new plug-in API that is coalescing that he's adding support for, but he has it set up now where you've got these plug-in dialogs with all these various elements and they're all live, or at least you can make them live. Some of the plug-ins might be too slow to be a reasonable speed, but as you change checkboxes and radio buttons and sliders and things, the image automatically gets updated. So it's a lot easier to figure out what all these plug-ins do and how you can vary things. HB: A real-time preview? SH: Yeah. I thought that was really neat. Even if some plug-in is currently too slow, I think there'll be an API in the dialog for turning it on and off if you need to. As machines continue to get faster, more and more of the plug-ins, I'm sure, will be usable with a real-time preview of what they do. Some of the others are things like being able to tear off the whole Size menu and vary the size of a font with a little slider, and having it change real-time until it's the right size you want. That's certainly a lot easier than "let's change it to this size, no, that's not quite right, nope, change it to this size, no, that's not right." That kind of thing gets frustrating after awhile. That's the direction that we're trying to go in. Those are the little things that I think make Gobe Productive neat. Some of these things wouldn't have even occurred to us when we were working on the MacOS and I think that was the biggest change for us. It's a different perspective now. We're always at least trying to make things as live as possible. Sometimes we don't succeed. Sometimes there are problems with making things live. But the influence of the multithreaded nature and what's already been done under BeOS leads you down that path quite naturally. HB: How do you feel about the fact that your software's mostly being deployed on Intel hardware? SH: It's a little bit odd. I still root for Apple. I want them to do well. Our company will have a Mac product someday. I don't know if it will be Gobe Productive. We've got one other project that's kind of more of a technology at this point than a product. If we're an ongoing company, we will have Mac products in the future. I still have great ties to the platform. Intel's a great company, they've probably done a few slimy things, even Apple does some slimy things, but I don't get the gut-wrenching feeling when I think of Intel that I get when I think of Microsoft. Doing anything at all costs to dominate an industry. It's probably unhealthy for a company to have the anti-Microsoft feeling that we do. We try to be honest with ourselves, but we're all big Microsoft bashers. We're trying to be hardware-agnostic and the PowerPC is a great chip-at this point it's probably a better chip than Intel's. But there's an awful lot of Intel hardware out there. When they're selling $15 million in boxes a year it's a lot easier to carve out a little niche than in Apple's world where you've got something in the $2 to $5 million range. It's hard to turn your back on possibilities. Even if BeOS is never installed on more than a million Intel machines, it's still a possibility. HB: What do you do when you're not coding? SH: When we moved up to Portland we were seven or eight minutes outside of downtown Portland. There was stuff everywhere to do. I'm really enjoying Portland. Just walking around and seeing all these little shops. There's a lot of good restaurants in that part of Portland. I developed tastes for food that I never ate when I was growing up. HB: Like what? SH: Indian food and Thai food and garlic. I didn't know what garlic was when I was in high school. I grew up in Dallas and it's kind of like Santa Clara except it's cheap. It's kind of this infinite suburbia. Everybody was white and nobody used spices in their food. HB: In Texas? I thought everybody used spice in their food. SH: OK, there's Mexican food in Texas. But I grew up with that so much that I almost dismiss it now, which is not appropriate. I still like it, you just can't get really good Mexican food in Portland. I think that's the only thing I miss about Texas. Most of us actually did grow up in Texas. It's fun being in a real city, just doing the kinds of things that you can do in a city with some diversity. Our office is in downtown Portland. There's a bookstore in downtown Portland called Powell's, which is the best bookstore I've ever been to. It's not this new fancy building, it's literally just a bunch of buildings that are nothing special, that have been connected together-it's like a whole city block. It has such an incredible collection of new and used books. Our office is right across from Powell's; whenever I'm coding and I run into some nasty problem and it's like how the heck am I going to deal with this, and it's just really frustrating, I just walk across the street and go to the bookstore. It doesn't matter whether I find some book that I'm interested in, it's so relaxing and so different from coding. There are all these different types of people there. It's really fun to get away from programming and go there. That's one of the things that I like a lot. The other thing we do, we started doing this when we were on ClarisWorks, we'd get out there and play Ultimate. We had a few lapses at times, but we usually get out and do that once a week. HB: You're going to have to clue me in. SH: Ultimate? Most of the time we call it frisbee football because we don't play it by the exact rules, but it's kind of like a combination of basketball/football with a frisbee instead so you can't run with the frisbee, you can only pivot on one foot. It's like football, you try to get to the end zone, but you can throw it to someone on your team. If they catch it, then they can throw it to someone else on their team. And if you get to the end zone, you score. That's about the most strenuous exercise I get. We have a lot of fun doing that. A lot of us used to play music at one level or another. I used to play clarinet and I'm not really any good, to be honest. Bob played trumpet, Scott Lindsey played baritone. Scott Lindsey actually went to the same high school I did. HB: So you were in the band together? SH: Yeah. Four of the six programmers all went to Rice University in Houston. Bob and Scott were in the Marching Owl Band band, which is not really a band. It's kind of like the Stanford band except maybe even crazier. They do shows, they don't really do marching. Anyway, they were in the Marching Owl Band band and I was in it some. I went through this period of time when I got braces and I couldn't play very well when I got them, and I kind of adjusted. Then the braces got taken off and I couldn't play very well again and I was really getting into computer science classes. It just really didn't work out. I didn't have a lot of natural ability anyway.