Stephen Beaulieu, DTS Manager Interview by Henry Bortman HB: We should probably start with what DTS (developer technical support) does. SB: Most of what we do is building online resources for developers. Our team is responsible for half of the developer workshop in the weekly newsletter, so every other week at least one member of our team writes a news article with corresponding sample code. We answer all of the front-line developer questions, whether they are installation-related issues or, I've got a problem with my code, or I think I've found a bug. We do a lot of that investigation and we also manage running the beta tests when we get to that point. HB: I've heard a lot of war stories from developers about the poor tech support they get from other OS vendors. What's your approach at Be? SB: It's definitely different and I won't say we've been completely successful trying to do what we want to do. We've had our problems. But, in general our goal is unlimited online technical support. We do know how to develop programs that actually get direct technical support from my team-you have to pay a certain amount per year. But unlike other OSs, there's no limit to how much support you get, there's not a per-incident-"you get three incidents with our team, and that's what it is." Send in as much email as you want and we will help you work through things. Now, we won't sit down and write your application for you-yeah, I know, we can't do everything-but our philosophy is, in general, that our developers are our most important customers because there's no point in having a new OS unless there are compelling applications for that OS, and the only way that happens is if you have good developers, and the only way good developers write good programs is if they have access to the technical information they need. So, our top goals are get good developers, make sure they have the information they need, and deliver customers to those developers. And if we can meet those goals, then we'll end up being a successful company. Our overall goal is to provide enough online information so that developers don't have to ask us questions. Most developers prefer to just be able to find the answers themselves and do it without bothering us. When they have to ask us questions, if we don't get back to them for a couple of days, then it might be a couple of days that they don't get stuff done. The other thing is to get our developers' applications out the door. So, quick turnaround of questions for developers. We're not perfect, so easy questions generally get answered within a day or two. Difficult questions could take a couple of weeks. Those aren't hard-and-fast deadlines, but we try to be as responsive as possible, as helpful as possible to our developers, because that's what we're here for. Our job is to make sure that people use the system as efficiently as possible when they design their applications. We're a very multithreaded OS. It's very easy to write simple programs and some complex programs; you can do it a lot more efficiently than with other operating systems. However, some of the advantages of the operating system-its messaging model, and its multithreaded nature-can make it difficult and tricky to track down bugs because a lot of people aren't used to an operating system that works exactly the way this does, where you have all sorts of interaction. So, part of our goal is to show people how to program in a multithreaded environment effectively without deadlocking their application and, as with every API, there are some calls for certain classes that are just faster than others and you like to tell people, "You should do it this way because we've discovered in-house that this is kind of the best way to do it." HB: How different is it really from Unix or NT or other threaded operating systems? SB: It's not that different, but BeOS threads are a lot more lightweight, so there's a lot less performance loss to actually spawn off a thread to do something. So, it becomes more efficient to start using more threads, and people start using more threads than they're used to under other operating systems simply because they can. There was a newsletter article from Pierre [Raynaud-Richard], the head of the graphics team, just in the last couple of weeks where in R3 we had a big slow-down in graphics performance compared to things like BeBox with the preview of DR8-, especially since DR8., and iIt came down to a contention for a shared resource between multiple threads where graphics threads were all trying to grab one lock that they needed, and even though they were higher-priority threads and therefore should receive, on average, more processor time than lower-priority threads, they were getting starved because we only guarantee that higher-priority threads willhad been scheduled;, we don't guarantee that they'll run for the full time they're allowed to, and they would run and immediately block. And so, that really hurt graphics performance. Well, it took us a long time to find that, but we found it and fixed it, and everything's a lot faster now, but it's tricky because people just aren't used to threading as much as we do. For example, MacOS programmers. You've got threads, but you don't really have threads. Everything pretty much runs in a single thread, you're not in a situation where you can literally have two threads running concurrently, and with the BeOS running on multiple- processor machines, you literally can have that. And, it's just different from what a lot of people are used to. HB: What questions don't you get as a result of BeOS having done things to make life easier for developers? SB: Well, we get a lot fewer interface questions than I would have thought. The Interface Kit inside BeOS handles all of the windows, the views for drawing information, various things like buttons, controls, pop-up menus, things like that. So, once people understand the relationship between a window and a view, even people who've never done interface work at all put up interfaces that are good looking, easy to use, have pop-up buttons and everything interacting; that is very, very difficult and much more complex on other operating systems. So, we don't get very many of those sorts of questions. Once people know how the system is supposed to work, they just go at it. We generally don't see them. We tend to get the questions like, "I'm resizing my window and it flickers a little bit more than I'd like." OK, there are some techniques that you can use to do that, but we don't tend to get, "I don't know how to make a menu, I don't know how to put a window up. I don't know how to interact with a text control so that when I enter it the information changes in my file. I don't know how to open up a file and read and write contents out of it." We don't get those sorts of questions very often. The questions we don't get change, because when we get questions from a bunch of people, we'll write a piece of sample code about it. There'll be a newsletter article written about it that explains how it works and then we tend to not get those questions anymore. So, our goal is to get to the point that the questions coming in that people don't understand are about the new stuff that we haven't dealt with yet. We'd like to get to a point that for all of the older stuff in the operating system, the base-level stuff, there aren't that many questions, or the questions are coming in from new, first-time programmers who need the quick answer once and then we don't hear from them again because they can just write their app. HB: What are developers saying about writing for BeOS as compared to writing for say Windows, or NT, or the MacOS? SB: One of the things, and it was a design goal, is that the BeOS is simple to understand and program, especially at the basic levels. We've got two books, one is about to come out from O'Reilly called Be Advanced Topics, and the current one out, The Be Developer's Guide, where essentially in two volumes, we list the entire API of the system with detailed discussion of how things work. Compare that with the Inside the Mac OS series; it's like 30 volumes. The BeOS is a lot easier; one of the design goals was that programmers work more efficiently when they really understand what they have to work with and the OS will be designed in such a way that someone can have most of the API in their head once they understand it. There are some things that some developers don't like. A lot of developers really hate C++. A lot of developers would be much, much happier writing in Pascal or C or whatever language, Object Pascal, things like that. So, people want to use different languages. They want to use SmallTalk, they want to have C access to everything. They want to program everything in Java, not to run the Java VM, but they want to use the Java classes and compile to native code, and we don't support that. We are a C++ shop. It was a design decision we made for the OS and we use a lot of stuff in C++ that other people just aren't used to using. We use multiple inheritance, we use virtual classes, we use static initializers for objects with private constructors. Stuff that people just aren't as familiar with in their day-to-day life. So, there's a lot of things that people don't like about C++. We regularly get comments in, basically saying, "C++ sucks, why don't you use something else?" Well, C++ may not be the best programming language in the world, but lots of people know it and it allows us to do a lot of really interesting things and it's well understood by people. It's got all sorts of drawbacks, but the upshot is, it works. If you don't like it, then maybe programming with the BeOS isn't for you. So, those are some of the main sort of differences, things they like. Again, there are things they don't like about programming and it goes back to things like no choice in developer tools. It goes back to things like not liking C++. Some things are different. Using the application framework. Having the full multithreaded nature of the OS is just different from what most people are working on. A lot of people, Unix hackers ... we have a compliance layer that allows a lot of basic, new sort of Unix tools to recompile. Some of them don't because we do things differently and so a lot of people don't like it. They can't just take the tools that they've known and loved forever and bring all of them immediately over. We're working on making that better, but for some reason, it's not a real high priority for us, because things are going to perform better if they're written for BeOS and that's kind of our goal. HB: This book is an end-user book and what your team does is primarily oriented toward developers, but can you close that gap? For an end-user who's reading about developer technical support ... SB: Why should they care? That's a good question, why should they care? To a certain extent, it doesn't affect their day-do-day life. What I can do to close the gap is [say that] because we're really interested in finding excellent developer support and making it easier for our developers, the easier it is for them to write correct programs that perform well and efficiently on the operating system, the more time they have to add features to their programs, to come up with new things that they can do. So, basically, developer technical support makes their applications better and that's kind of the whole goal. It's worked for some and it hasn't worked for others. But, if we weren't there doing this ... we provide a common baseline. We are not telling one set of developers one thing and another set of developers another thing. We're basically saying, no, there are efficient ways to program this operating system and these are the ways to do it, and that will hopefully provide some consistency in behavior among applications. And again, with the user interface guidelines that will be coming out, which I don't know about, that will also help to provide some sort of consistency for the applications and better performance. The other thing that frankly our team is good for is bugs. Whether a user or developer submits a bug, a lot of times we investigate it and see if it's true or not. If it is and we can prove that it actually is a bug, we can get it into the system and get it fixed. That's another large part of what we do and what we care about, the stability of the OS. Developers in technical support run the beta test, so before they get the brand new version of the OS, we'll have made sure that as much as possible it's gone through all our developers who have shipping applications so that they can use the newest and best features, and if things are broken because they did things wrong before, or whatever, we can get them fixed. They should care because, the upshot is, we help make their applications better. HB: How did you get into all this? SB: This will probably be a more unique story than you'll get from the rest of the guys. Just to give you a little bit of background, I went to Stanford, I had a self-designed major in African studies. I'd never taken a computer science class in my life. It's a very different path from most of the people who get here. I was good with computers, I used FileMaker database stuff, but it wasn't what I was focusing on. So, I had a standard liberal arts, sociology, history sort of background. I moved around, basically, from office job to office job. Ended up down in Austin, Texas, working for the university there. And I was basically doing FileMaker database stuff for a couple of different groups there. I got bored with office jobs, so I set up my own Web server from home, ran it on WebStar, the first version that came out, and was doing Frontier scripting. I was starting to learn that, like, "Wow, I can actually do this sort of stuff." And In January of '96 through a friend I was working with I stumbled across the Be Web site. HB: So, you had your own Web site? What was up on your Web site? SB: Nothing. Basically, just stuff. HB: Stephen's Web site? SB: Yeah, it was my Web site, I ran a couple of friends' stuff, ran an email server and other stuff, all from a LC2 on a 14.4 dedicated modem, very impressive! Slowest damn thing I've ever done, you know. And, I was doing things like I was part of an online gaming community, so I was writing Web pages for Diplomacy, and old Avalon Hill game, and working on stuff like that. Essentially not much. But I was learning to do Frontier scripting for a port system and things like that. And I stumbled across the Be Web site and it just made sense. It was like stumbling across Nirvana, and I looked through and just ... I'd heard about a bunch of things that were supposed to come out in MacOS 8, which was continually being delayed. And I was looking and seeing, wow, this stuff makes sense. I downloaded a copy of the Be Book, printed it out, and January '96 when I was looking at this, I knew no C programming, no C++ programming, nothing. I was doing basically Frontier scripting, which is, you know, somewhat C-like, and structural programming. But, I hadn't actually done any of this, and I looked and, you know, this makes sense. You've got objects that do these various things and you have these things that happen. I thought, hm, I really want to do this, and so I bought myself a C++ manual and started looking through it to understand what was going on and kind got into the developer program through a friend on the side, then I just opened the box and started programming. So, I'm probably the only person engineering-related in this company that learned to program on BeOS. Everyone else did it from various other things. It's strange. HB: So what were you programming? SB: Well, what I was first working on was a mail server for BeOS and I got hired by Purity Software in Austin, Texas. They do MacOS Web server tools, Web site scripting, server-side scripting solutions. I wanted to work on BeOS servers and I was doing customer support for them on that-they were a developer and we decided that our first BeOS product would be a BeOS Web server, so I was working on that, it was called Charlotte. It didn't actually make it out the door. It happens. HB: Great T-shirt, though. SB: Yes, everyone likes those. So, I got to the point where that's what I was working on and we would come to the shows and we showed the product and it never got finished just for the normal sort of reasons. Too small a company trying to do too many things. You know, depending upon the Mac software that was out to fund things and needing to focus energies into that. So, in November, for various reasons, not the least of which was I was getting married and I wanted to look at my options, there were opportunities here for developer technical support, which is kind of what I was doing back at Purity when I wasn't doing the BeOS programming, because they had their own programming language for the server-side scripting, so I was used to doing that. I knew the BeOS, a lot of the people knew me because I'd been through a lot of the stuff and had the technical skill, so I came on board and a couple of months ago I was promoted to manager because things just worked out. That's kind of my path to get here and it's a little bit different than what a lot of people had. HB: So, how is it working here? SB: I love it. Absolutely the best job I've had. Well, the biggest thing is that there are some amazingly brilliant people here. You've got quite a few of them on your list of people here you're talking to. You know, Dominic and Pavel and Benoit and Bob Herold, you know, Pierre. George, who's not on your list-George Hoffman works with Pierre. Basically, between the two of them they've done all the new improvements to the App Server. Benoit Schillings wrote all the original stuff that made BeOS what it was to get where we are and other people have come behind to improve things. Just amazingly brilliant people who really, really know their stuff. Really, really friendly, easy to get along with and work with and that's part of it. Not having come from a computer background where I had lots of people programming and doing things, I come and look at these people and what they can do and it's just amazing. It's a very good atmosphere. One of the things I like in a work environment is where people know what your skills are, know what you're capable of, give you responsibilities and let you alone to do it. We're a small enough company that we depend upon every member working here to get their job done and do their job well. I find that I thrive in that sort of environment. That works really well for me. Other people who like to have a lot more support and direction, for the most part here at Be, we don't have time for that. And that's very exciting, the fun of startups, the fire in the belly, let's go, go, go, we know what we're doing and we're making a difference. So that combination of things is really good. And then, it's the product. You know, from the beginning, when I stumbled across BeOS and looked at it and saw the way it was designed and saw what it had done, it just made sense to me. It was just a decision that, you know, I really just want to keep programming BeOS so I can play with it all day. I really, really like the product and I really, really like programming for it. I like helping other people get the job done, which is good. That's what I'm supposed to do. But not everyone can do that. For the most part people here in the engineering staff upstairs are doing different things from similar sorts of jobs in other companies. If you were to go work at a large company like Microsoft or Adobe or Intuit or something like that, your engineers are going to have, "We've got three engineers to write this Open panel and makes sure the API works well and that it looks good, and stuff like that. We've got four people whose job it is to draw the icons for this sort of thing." Here, you can really, really carve out an area for yourself. There's a lot of ... again, anywhere, whether it's engineering or what I've done since I've come on here, or upstairs in marketing, if you've got some ideas and you want to do certain things, there's always more work to be done than there's people to do it. You can really, really make a difference to the company. Whereas, in other places you're somewhat insignificant until you get up to the higher sort of levels. Office jobs just don't cut it for me anymore. HB: But if Be is successful, that will all change, right? SB: Yep, a lot of that will change. It's interesting what will change. Let's assume that some massive cosmic change happens and we replace Microsoft as the most popular operating system out there. Yeah, that's gonna change a bunch of things. Are we suddenly going to have 300 engineers working on our browser for the platform? No. Part of the way that Be has been successful and the reason that we put a good product out is that we have small teams working fairly independently on their section of things, so they know most of the system, they can get it done, and they're not hampered by levels of management that basically make them not be able to do their work. They're teams of, you know, five, eight, ten people. I would imagine that the engineering staff is going to want to keep it that way because it just works. And you know having 20 people working on a Web browser is just not good. We're getting to the point with some new hires, that live where Pavel works on the Tracker here, where he actually is going to have a couple of people working with him on that. And that's like, oh, wow, someone's got a couple of people working with them on one program, which is different. But, growth will come. If we're successful, the company will grow. My division will grow. There are probably around 50, 75, maybe 100 people really actively working on programs, really making an effort doing BeOS programs. If we become wildly popular, that can easily jump into the hundreds of people working on big-time programs and into thousands of people, collateral people just playing around who may or may not become the next Adobe software depending on what they're capable of doing. So, yeah, for my team, that's going to mean growing. And it's difficult finding good DTS people because it's an interesting combination of communication skills and getting along well with people, and patience, and real good, broad technical understanding of the operating system and programming in general. If you get the people who are really good at the programming side, they all want to be engineers. But if you get the people who are really good at the people side, they either want to be marketers or they don't have the technical information to do the job. So, it's a strange sort of beast, but it will grow. HB: So, are there enough hours when you're not working that I can ask you about what you do when you're not working? SB: Oh, sure, there's a lot of stuff. I have a wife and two kittens at home and most of my time is either spent here or at home with my wife. We generally go see a couple of movies a week. We take dance lessons and go out swing dancing every Saturday night. That's mostly what we do. My wife is a writer, she works from home, she does costume sewing and things like that, this weekend we're going down to the Ren Fest. But, I'm a geek, what can I say? I like sitting down and working with BeOS. I wish I had some more free time so I could actually write an application for BeOS rather than other things, so, I'd like to do that. HB: What would it be? SB: I don't know. It would be nice to go back to doing some of the mail server stuff because it would just be nice to have a better solution for that on the BeOS. I'm working on the database system internally. I have thoughts of turning that into a sort of FileMaker system, or at least doing a series of APIs where anyone can plug in their own database, whether it's an attribute database or whether it's connected to SQL server or whatever, and then write their own interface on top of it. That might be a lot of fun, but probably I'm not going to find the time to sit down and write a totally independent app from the things I'm doing at work or meaning to do, so if I can just make something better than what I'm working on that would be good. Who knows, other stuff might come up. I'm not a media person, I'm not into video or audio editing stuff, so it won't be like that. It would be more likely to be a Net utility or something user-related. HB: So, speaking of media, what gadgets do you play with? SB: Not a whole hell of a lot anymore. I used to, I don't have time anymore. I used to do film stuff, some video cameras. And back when I was at Stanford I played in the band for most of the time, bass and singing. Not standup. I actually want to get a standup in the next little bit to learn that stuff, but it's been a long time. I played a little guitar as well, electric. It's interesting, because if you wander around here, there are quite a few musical instruments that float around. We could put together a band with like 10 or 12 guitar players, a drummer or two, three or four bass players. HB: When I took computer classes, like many, many years ago, the teacher in the one of the first classes asked how many people in the class were musicians and about half of the class put their hands up. So, what movies? SB: Well, we go see everything from big hits like Saving Private Ryan to other things. We just saw Ever After a couple of weeks ago. HB: Did you like that? SB: Yeah, actually, it was fun. It was a cute little period piece. We love old classic films, so we go to the Stanford regularly and we like to see a lot of the art films. There've been a lot of good films, actually, that have come out this year. The Spanish Prisoner was really good, Shooting Fish was good. The Last Days of Disco was pretty good, so it's a lot of things. Generally, the modern slapsticky sort of comedy stuff, you know, the Leslie Nielsen sort of stuff, we generally don't go into. However, we like the old classic Marx Brothers sort of stuff. HB: What are you reading right now? SB: Well, what I'm reading right now is actually a departure from what I had been. I'm reading Paul Kennedy's The Rise and Fall of the Great Powers. It's been awhile since I've read a history book. But, I read science fiction, mystery, and basically just contemporary fiction, people who are out there. Christopher Moore is one my favorite authors right now. He's very, very funny. Yeah, just a broad range of things. I don't read horror. I don't read western, I don't read romance.