The BeBox you see today is actually quite a bit different than the one that existed four years ago. Both the hardware and software have come quite far since the version we had running in our old offices, in an industrial park in San Jose in 1991.

The original design of the BeBox was actually implemented as a dual-Hobbit processor machine, with three digital signal processing (DSP) chips on the motherboard. The bus architecture was proprietary, but memory, hard disks, mice, and keyboards were all borrowed from what Jean-Louis likes to call the "PC clone organ bank."

The software at that time consisted of just a multiprocessing, multitasking kernel and a command-line shell for launching applications. There were no graphics, no windowing system, and no integrated database —although all of these items were planned.

The first attempt at bringing some graphics capabilities to the machine came in the form of an evaluation of the NeWS windowing system from Sun Microsystems. My first job at Be was to learn PostScript™ to see what it was like to program in the NeWS environment. While NeWS did offer us a client-server approach to graphics and PostScript as a graphics model, it was rather large and the programming model, as well as the port to the BeBox, seemed complex.

While this evaluation was taking place and while we continued to evaluate other user-interface tool kits and graphics systems, an engineer named Benoit Schillings was quietly developing his own graphical windowing system. Using his intimate knowledge of the Be kernel, he optimized his graphics system to run extremely fast on the BeBox. To this day, Benoit remains our primary resident "speed freak."

The decision at that point became obvious. Although writing the entire graphics system from scratch was never our intent, we could see that it was the only way to achieve the kind of responsiveness and usability that we wanted for the BeBox. I abandoned the evaluation process and set out to help Benoit write the first version of the Be class library, which would interact with his speedy graphics server. Using the initial classes we developed (including windows, views, scroll bars, buttons, and menus), we set out to write a number of applications, including the file system Browser, to demonstrate and test the system. We were later joined by Eric Knight, who worked on the class libraries as well as several key demo applications, such as MIDI, MessageCenter, and FontDemo.

While all of this "high-level" work went on, the kernel, file system, I/O system, and device drivers continued to evolve and improve under Erich Ringewald, Bob Herold, and Cyril Meurillon, who had all been with the company since its inception.

In early 1994, Peter Potrebic joined the Be team and was given the responsibility of maintaining and enhancing the class libraries. Under Peter, the application framework saw a number of significant enhancements, including an improved application messaging system and the addition of threading classes. During release 2 of the software he was absolutely zealous in tracking down a number of extremely difficult bugs, which resulted in the system reaching a level of stability that we had never seen before. Our technical writers, Don Larkin and Doug Fulton also helped tremendously to make sure that the design of the class libraries and APIs were coherent and consistent.

Shortly after Peter joined the team, we hired another engineer named Robert Polic. Robert started out by helping Benoit with the graphics server and then showed tremendous versatility as he went on to work on many different levels of the system, from the SCSI and video drivers to many of our utility applications, such as IconWorld, CDPlayer, Keyboard, and all of our preferences applications.

By this time the team had grown large enough that certain development tools, such as source control and a bug-tracking system, became essential. Ming Low, who had been in charge of all of our builds, developed both of these tools and many others to keep the development effort running smoothly as the team grew. As the team grew, so did Ming's responsibilities, which included system configuration, network debugging, testing, and helping with each release of the software.

All of our software, of course, was still running on the dual-Hobbit, 3-DSP machine. While we were questioning the wisdom of having specialized DSP chips on the motherboard, we saw the entire future of the hardware cast in doubt when AT&T canceled the Hobbit processor line. It was decision-making time at Be again, and this time we saw the opportunity to make improvements in several areas. We needed a new processor and the PowerPC line seemed appealing on a number of fronts. First, it offered pretty good performance for the price. Second, it had the backing of a number of industry leaders (Apple, IBM, and Motorola) who assured its existence and design evolution. Last, but not insignificant from our perspective, was that unlike the Hobbit, the PowerPC chips had the ability to handle floating-point math very quickly. We saw this as our opportunity to abandon the specialized DSP chips and gain a much simpler system design. This new design retained the ability to process floating-point numbers very quickly, and was also able to throw both PowerPC chips at general system tasks if needed.

The entire PowerPC motherboard design, including the use of industry-standard ISA and PCI buses, was accomplished by a single hardware engineer, Joe Palmer. The port of our software to the PowerPC processor was basically the work of two engineers, Bob and Cyril. Bob worked magic as he single-handedly brought up each revision of the new hardware and debugged impossibly complex interactions between the lowest levels of our software and the new hardware. Cyril, meanwhile, rewrote a number of speed-critical, machine-dependant pieces of the kernel, including the interface to the memory management unit. The rest of us "high-level" guys basically just continued our work on the Hobbit boxes until the day Joe showed up in our offices with new PowerPC machines. With a new compiler and literally a simple recompile we had all of the applications, including the Browser, running on the new PowerPC boxes.

There was another benefit from the switch to the PowerPC, which we came to appreciate a great deal. Having designed all of our software for the Hobbit we were forced to spend a lot of time looking at performance issues, which we might have ignored had we started with the faster PowerPC. This resulted in a system that ran very well on the Hobbit processors, but was noticeably snappier on the PowerPCs.

As the PowerPC design took hold we added another key engineer, Brad Taylor, who quickly became the most popular guy on engineering row when he implemented the TCP/IP networking stack on the BeBox and ported the ftp tool for us to use for file transfers. Before Brad ported ftp, we had agonizingly used the tar tool to transfer files on floppies from our UNIX development machines to our BeBoxes. With ftp, Brad turned my transfer time for the Browser from one minute to three seconds. Since most of you reading this are developers, you know what a tremendous difference this makes in the development process.

The team itself was run by our VP of engineering, Erich Ringewald. Erich's contributions to the BeBox are considerable. Along with writing kernel code, keyboard drivers, and porting UNIX™ tools he has kept the team on track throughout its existence. He has refereed fierce battles in the engineering team and has made critical decisions throughout the design process. Without actually micromanaging any individual, Erich has managed to keep a team with extremely diverse skills and personalities all focused on the same goal.

Some of the other later additions to the Be product team have been Melissa Rogers, Rico Tudor, Roy West, and Guillaume Desmarets. Melissa is the self-described "chief pitbull." She keeps the engineering team in line and is responsible for the project schedule and about fifty other things at Be. Rico was given the task of porting the bash shell to the Be environment and writing a new ansi terminal application to host bash. Roy thought he was just going to write user documentation, but has ended up becoming our webmaster, writing and editing marketing materials, and proofing this newsletter. And he's even managed to write some user documentation. Guillaume has joined us to help Joe with future versions of Be hardware.

I hope this article has given you a feel for the evolution of the BeBox hardware and software and for some of the major milestones along the way. Even though we've worked on the BeBox for a number of years there's still a great deal left to do. With your help and feedback we'll continue to improve the Be hardware and operating system to give your software a solid base to run on. I hope to write a similar article in the coming years that will continue the story, with all of the incredible innovations you'll bring to the BeBox in the form of enhancements, utilities, and ground-breaking applications.

Anton Travis is looking for a better way to do things. That's why he started BoxTop Software in Starkville, Mississippi, last year. And that's why he's developing software for the BeBox. BoxTop is a small (four person) graphics software developer. They're marketing a new graphics file format support library for Macintosh developers, called the Box Graphics Library. An annual license costs between $800 and $1,400. Travis expects to have a version of the library available for the BeBox by mid-March. The company is also working on a low-cost alternative to Adobe Photoshop. It will sell for $90. BoxTop plans to ship the imaging program for the Mac in the middle of next year, and for the BeBox shortly thereafter. Anton says the new, as yet unnamed, product will have a faster memory management model than Photoshop, smoother editing of large images, and significant improvements in layering capability and text handling. The company has also produced a couple of low-cost GIF and JPEG management shareware programs for the Macintosh, called PhotoGif and ProJPEG, that it distributes over the Internet.

Anton has spent the last ten years as a graphic artist and creative director for his own graphics design agency. Over the last few years, he's grown frustrated. "I got sick of the graphics software tools that I had available and I decided that I could do it better myself," he says. He's also frustrated with Apple's "consistent blundering" of the Macintosh platform. "I wanted something new," he says, and the BeBox appears to be what he's looking for. We have high hopes for the Be dual-PowerPC architecture. It's a perfect platform for pixel graphics."

In fact, he predicts that with its low price, the BeBox "could replace the Macintosh in desktop publishing if it has the right software." Anton speculates that it will take two years for the software to arrive, and then another three years after that for Be to build a dominant position.

Unfit for Consumption by Normal Humans

Why do we say such things about our products? What possesses us? Are we suicidally trying to turn business away? Is it some kind of perverse reverse chic, some image of exclusivity we start cultivating in order to raise prices later? After reading me today, I hope you'll conclude we're merely using plain old common business sense and effectively positioning our product in a way that makes the best use of our resources.

Let's observe the record. Many new (and not so new) companies enter the market with a great deal of self-inflicted pressure. They feel they have to offer the best of the past as well as the benefits of the future. Or they think they must represent their products as fully evolved, mature. In other words, they strive to represent themselves, or their products, as adult at birth. Hardly a comfortable position. I know from experience. The reasons are many: Ignorance, political pressure, variations on launch-pad chicken, denial, or simply greed. The litany of consequences is well known. Much money and precious reputations are invested and lost. Feeble and trite excuses are made: The market wasn't ready, the infrastructure didn't materialize, partners bailed out of the alliance.

It doesn't have to be this way. Let's review a well-known example: Newton. Its birth was preceded by much hype. We were witnessing the birth of a new genre, Personal Intelligent Assistants. The total market for products, contents, and services was going to exceed a trillion dollars by the year 2000. And... handwriting recognition worked. Now, imagine another scenario. The Newton is announced as new technology, not a product, from the Genuinely Exciting Evaluation Kernel of the company. Instead of disappointing many early adopters, Newton is viewed as interesting technology by fewer but happier customers. No money is wasted in creating mainstream demand for a product that doesn't exist yet, volume expectations are much lower and met. As a result, when a promising product such as the Message Pad 120 finally emerges, it's preceded by good word-of-mouth, the money saved earlier is available, and it easily and happily reaches the mainstream.

You see where I'm heading. I'd rather present the BeBox as an infant product—because it is. In its current state, it can only satisfy two kinds of users: C++ programmers who program for others, also known as software developers, and C++ programmers who write code for their own projects. I'd rather work with these users and raise the baby with their help. This is not to say we don't have high ambitions for the BeBox. Au contraire, we don't want to jeopardize its future. For the time being, I'd rather narrow our focus on the more technically competent and enterprising users, learn from them, improve the product and our services, and gain a decent reputation and interesting application software. In our industry, word-of-mouth is still the most potent marketing weapon. Advertising budgets and marketing programs can build on a reputation, they cannot create and sustain it.

In early '95, Be, Inc. created a European office in Paris. The European team is composed of: Jean Calmon, V.P. Europe; Christophe Droulers, Developer Services Director; Georges-Edouard Béranger, Developer Technical Support; and Marie-Claude Levrat, Administrative Assistant. Our mission is to create a distribution channel for all of Europe and to support our European developers, customers, resellers, and "aficionados."

At Be, we all know that the BeBox needs the experience, creativity, and talent of you—the developer. For this reason, our first efforts are to serve the developer community. We'll give you all the support you need to create powerful, reliable software and to break down market barriers.

We know that developers often have the answers to other developers' questions, so we've established a mailing list for developers who want to chat, share experiences, and help each other. If you'd like to join this list, let me know by e-mail (my address is droulers@BeEurope.com).

Another good way to sharpen your ideas is to share them in person. So we're planning developer meetings in Paris, where you can show your work to other developers. We'll stock an office with everything you need to demonstrate your product—and even to work a few hours with other developers.

We want to do all we can to help you get your software on the market. Do you need beta-testers? Tell us and we'll provide you with the e-mail addresses of developers and customers who want to help.

When your software is ready, you'll benefit from our European commercial FTP site, where customers can download demo versions or upgrades of your products.

On the Be Europe area of our world-wide web site, you'll soon find a current list of who's developing what in Europe. If your project's missing, send me e-mail and I'll add it to the list. (Of course if you don't want your name or project to appear, we'll respect your privacy.) The list also contains links to developers' own web pages, where you can learn about their projects in greater detail.

Remember, my goal is to help you become the most productive and successful Be developer possible. Send me e-mail with any questions about developing Be products in Europe, or with ideas for how we can improve our developer programs and services.

Sincerely,

Christophe Droulers
Developer Services Director
Be Europe