The "Be Newsletter" has been published weekly for seven months. In that time, we've had a chance to review its presentation and content. You'll notice a few changes in this week's edition:

• The biggest change is in the weekly DEVELOPER PROFILE article. We've changed the focus of the article to allow the developer's voice to be heard more directly. Dispensing with the familiar journalistic reportage, the profile is now presented "straight from the horse's mouth." Even the name has changed: The profile is now called "BE DEVELOPER TALK." Our first developer in this new presentation is Steven Knudsen of Resolute Research Ltd.

• A number of readers have asked that we provide more sales and marketing information. Starting this week, you'll find a "BE MARKETING MUTTERINGS" column that should help you understand Be's products and marketing strategies. The column will appear biweekly.

• Starting next week, we will provide a summary of the threads that are taking place on the BeDevTalk discussion group. As many of you know, BeDevTalk is an unmonitored forum where Be developers (and other interested parties) exchange ideas, myths, suspicions, recipes, and, occasionally, throw virtual brickbats at each other. In summarizing the week's BeDevTalk traffic, we hope to provide a scorecard for new and casual listeners. (To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/about_be/mailinglists.html.)

That's it! We hope you'll like the way we've revamped the newsletter. We want to know what you think, so please send your comments and ideas to newsletter@be.com.

Nope, sorry—this article doesn't contain advice on where to stash your money for the highest return. But it does contain advice on making a smart purchase of a SCSI CD-ROM drive for the current BeBox system software.

The ANSI SCSI II specification does an excellent job of providing commands for extracting data from CD-ROMs. Following the specification, we've been able to extract data from every drive we've tested with our SCSI CD-ROM driver.

Unfortunately, it appears that the standards committee ran out of time in the process of providing the same level of commands for accessing audio tracks. While the specification does provide audio commands for playing, pausing, accessing the table of contents, and adjusting the volume (though different vendors have different interpretations on this), there are no standard commands for stopping, scanning (fast- forward, fast-reverse), and reading audio tracks. Because of this, each vendor has chosen to implement these commands in a unique way.

Be's current implementation of the SCSI CD-ROM driver only offers full support (data and audio) for the Toshiba family of drives (the 3401, 3601, and 3701). The driver only offers data and limited audio support for other drives. If you need to extract digital audio from a CD, then you'll need a Toshiba drive. Disregarding audio, any SCSI drive (the cheapest you can find) should be sufficient.

In the future we'll provide support for more drives and make it simpler to add support for others. We'll do this by redesigning our current driver to use "add-ons" for audio access (currently, all audio access is done in the driver, which is linked into the kernel and not easily replaceable). We'll publish the API for CD-ROM add-ons so developers and vendors can also add support for additional drives.

All I could think when I first saw a BeBox was, "Gee! It sure would have come in handy for my Ph.D.!"

My wife, Katherine, and I started Resolute Research in 1994. We develop custom scientific and engineering solutions including signal processing, data analysis and manipulation, communications, and embedded microsystems. It's pretty much right down our alley, because I've got a Ph.D. in multidimensional signal processing and Katherine's a petroleum engineer.

Be has me as excited as the day my first full-blown Mac application ran. For an electrical/computer engineer, the BeBox is a "must-have" platform. Its combination of a brand new OS and development environment, a flexible, open hardware architecture, and accessibility to the entire system from the external signal/board level on up is unique.

Like all developers, I want to see the BeBox achieve a significant customer base in the long run, but for now, for the markets we serve, I see it as a very practical platform upon which to base powerful, new, vertical market solutions. The GeekPort™ in particular is ideal for prototyping electronic circuits in signal processing and robot projects. I'm dying to try some of my nonlinear adaptive filtering algorithms in real-time!

The more I work with the BeBox, the more ideas spring to mind. The problem is deciding what to focus on first! Right now, I'm spending most of my time learning the system. And I've started on a port of the NCSA's Hierarchical Data Format (HDF), with an eye toward using it as the basis of a multidimensional data manipulation and analysis library and application.

Further down the road we'll be working on microcontroller development tools, primarily for the PIC family of microcontrollers. The GeekPort is a natural fit. A possible first application would involve the control of household electronic equipment and monitoring household functions using the BeBox's IR ports and an IR transceiver, built around a PIC. It's also the first step in developing and controlling autonomous and semi-autonomous mobile robots.

Longer term? We're looking at projects centered on signal processing applications. Initially, some sort of basic DSP framework, and after that, some state-of-the-art, one- dimensional and multidimensional signal processing algorithms. Motion detection and tracking in digitized video are particularly interesting.

Our database libraries should be available by mid-summer 1996, with the DSP environment and associated applications coming in late 1996. We wish it were sooner, but, like so many small consulting companies, we've been busier satisfying customer contracts than developing our own products.

Actually, that's not entirely true. Katherine has, after nine months of development, produced our finest product to date: Baby Knud Soren Knudsen! I lobbied for a name that included "Be-something," but being only Vice President , I was voted down...

The lifeblood of any company is communication, between its customers, partners, suppliers, employees, friends, and shareholders (with, we hope, significant overlap among these groups). The primary function of a marketing organization is CONNECTION: To lubricate, stimulate, and participate in the connections between customers and engineers, developers and managers, and others. To aid in forming and maintaining those connections, we're going to use this space in the newsletter every two weeks to write about goings on at Be and in the Be community. True communication is, by its very nature, bidirectional, so send me feedback, comments, criticisms, and suggestions (to alex@be.com).

Startup companies live by only one credo: Product. Those that don't live by that credo don't live. So, for the past five years, Be has focused on developing its product and turning it into something ready for the market —or at least ready for application developers, who will help us turn it into something ready for end users. As the product neared developer readiness, Be hired a few people to focus on getting that product out to the developer market. As a recent hire myself, I am simultaneously excited by the product and what it could do and somewhat wistful at having missed the company's first five years of hard work and satisfaction; there's nothing quite like being in at the beginning of something great and seeing it grow. However, there was a reason why Be didn't hire a salesperson five years ago: The company is resisting the allure of the quick buck and—gasp—is selling what it has today rather than what it will have someday in the future.

So what is the purpose of the freshly minted sales and marketing team, hired over the past few months? The answer is simple: To help developers ship successful applications on the Be OS. Our priorities are to provide technical and marketing support to developers, to assist in connecting developers with potential customers, and to manage the logistics of buying, shipping, and (occasionally) fixing machines. In the past week, I hope that every developer who has applied to join our developer program has heard back from us (if not, please let me know). BeBoxes are available immediately to all developers. Now is the time to start developing your application! To help fulfill our promises of support, we're hiring evangelists: Highly technical people who can work alongside a developer to get applications out. Those are the only people we're hiring this year into the sales and marketing organization. If you know of someone, or have a yearning to evangelize the BeBox and Be OS, we'll roll out the red carpet for you.

Keep in touch.

The term "evangelism" was coined by Steve Jobs at Apple, in the pirate flag days of the Macintosh division. At the time, the Holy Grail was getting application software for the Macintosh. The Apple /// wasn't working too well, the Apple II was running out of hardware, and the Lisa was destined to disappear after being rechristened Mac XL (for Xtra Large or eX Lisa...). The adversary at the time was IBM, positioned as Big Brother in the 1984 Ridley Scott commercial. The polarization was effective. IBM still reigned and had done a terrific job in establishing themselves as the winner in the battle for the PC market, or so said the "Business Week" cover story. At the time, little did we know that the real winner lived inside the PC: Microsoft would end up dominating both the operating system and office application markets.

I have two problems with the implications of the word evangelism—even if I agree to bow to usage.

The first problem is with the religious implications. More precisely, the intolerance often associated with evangelical religion. I'd rather not see our company behave in a rigid fashion and belittle "nonbelievers." There are many ways in the Lord's House, and I'd like to present ours as one way—not The way—to exciting new technologies, markets, and applications. Which leads me to the second problem: Polarization. Yes, after seeing the famous commercial and the Macintosh descend from the sky, Steve Jobs' depicting IBM as the oppressor of personal computing freedom focused emotions. But, as we know now, that was at the expense of intellect. One's opinions on who was the real adversary may vary, but it wasn't IBM.

Polarization makes good PR, but it doesn't necessarily make good sense after the newspapers are recycled. Yes, some say they'll work with us because we aren't this company or that one. If it's because we offer features, market space, or services not easily accessible through other associations, we have a sound basis for a partnership. We'll also take style or chemistry: Even the computer business is still conducted by humans. But we'd rather appeal to positive aspirations such as innovating, building, and sharing. Does this make us naive? On the contrary. We have high aspirations for this company, and we'd rather build it on positive foundations with like-minded partners. Still, we have competition, which will intensify as we gain momentum. This is no excuse for facile polarization. I'd rather follow the "two Bills" school of coaching. Outside the company: Bill Walsh. We're playing against a great team, it will be a tough game. If you win, you beat a great team -- if you lose, you lost against a great opponent. Inside the company: Bill Gates, always on the watch for threats and opportunities.

So, we'll strive for good deeds, we'll speak well of our partners and competitors, and we'll keep our dark thoughts to ourselves. What about evangelism, then? Many things have changed since that term was coined. Even if the stated goal is the same—to get applications on the platform—even if Guy Kawasaki's book, "The Macintosh Way," has withstood the passage of time, much of the context has changed. Great development tools, a simpler platform, and electronic distribution of software have simplified the business model of application development on the BeBox.

As a result, we're singly focused on establishing relationships with authors who'll produce good code—not business plans. We want evangelists who can sell the benefits of the platform, stay on the relationship, and provide at least the first level of technical support to their developers. It seems a tall order, but we believe the benefits to be even taller. Just as we say better products are developed if more decisions reside inside a single human head, we'll have a better relationship with each developer if technical and business discussions are held with a single Be human. We'll advertise for several evangelist positions. Given our requirements, we're also likely to use a search firm. But if you know an MBA who can write and debug C++ code, let us know, let him or her know. You might help a great application be born and you'll certainly help this young company.