Let's say you witness odd behavior in your application. And let's further assume that you suspect that the culprit isn't in your own code. Moreover, you prove to yourself that it is, indeed, a bug in the BeOS™. You can work around the bug—perhaps at the expense of performance—but you sure would sleep better at night if you had a clean version of the OS. How do you get us (Be) to fix one of our own bugs and release the improved OS? I'll tell you how. But first, let's look at the Be release process.

We follow Metrowerks' release strategy of delivering new software four times a year. That's a release every three months, which gives us just enough time to make an appreciable improvement in the OS. In an ideal world a release every other month—an almost constant, on-demand release system—would be great. We actually tried it once, but found that a monthly release schedule didn't leave much (any) time for testing —and you thought DR7 was unstable. So for now, anyway, we'll try to keep up with a three-month release cycle. This is pertinent to the developer because as a rule, we only distribute bug fixes as part of new releases.

Of course, bugs don't fix themselves; and within a single release cycle, we many not even have time to fix all the bugs we can identify and understand. So we have to do some filtering: We decide which bugs are most important and which ones we (and you) can live with until the next go-round.

We have a reasonably simple strategy for release content. In the first part of the release cycle, we make a list of the features that we really want to include—without regard for the time it would take to implement them. The feature list is always longer than a novel. Then we look at each feature, figure out how long it will take, and try to fit it into the schedule of the appropriate programmer. This goes a long way in cutting down the list. When we think we have a list of features that can be managed in three months—given the talents and temperaments of our engineers—we look at the list once more and lop off one feature from each assignation. This is the sacrificial feature—the time that this feature would have taken is devoted to fixing bugs. That's the theory.

Once a week we pull down the bug reports from the Be web site and separate the good bugs (feature requests) from the bad bugs. We try to reproduce each bad bug and to figure out the scope of its malfeasance -- does this bug merely hang a window, or does it kill an entire app? Does it wedge the app server, crash the entire machine, crash all machines in the same room, shut off the electricity to the building, or run around the parking lot letting air out of car tires?

Having gauged a bug's severity, we argue over which ones we'll try to fix. Once a week, seven of us enter a room and, a few hours later, at least three of us are still talking to each other (it's astonishing how much heat can be generated when you sit in a room and discuss bugs with the programmers who imposed them). We mark bugs with four different priorities: A priority 1 bug is important enough to hold up a release -- we won't ship until the bug is fixed. Priorities 2 and 3 mean we'll live with the bug if we have to, but we'll be ashamed (priority 2) or merely chagrined (priority 3). Priority 4 means the bug is deferred until next time. On average we fix 180 bugs each release. That's pretty good for 13 engineers.

So now that you know where the ballpark is, here's how you play the game:

• Submit your bugs and feature requests on our web site (http://www.be.com/developers/bugform.html). As a rule of thumb, bugs reported after the first four weeks of a release cycle must wait until the next release.

• Submit one bug per report. If it looks like there might be more than one bug on a report, then someone over here (me) has to figure out how many bugs are really there, which takes time and makes me grouchy.

• If you're reporting a "bad bug" (as opposed to a feature request), give us an easily reproducible case. We love it when there are steps to follow or example source code.

• If you're sending us a feature request or UI enhancement, please be clear and precise about what you want. We have plenty of bugs that are long-winded philosophical tracts (then again, if you're looking for an essay for your Computer Interface Design 101 term paper, maybe we can work a deal).

• Bugs that crash apps (or, gasp, the machine) are pretty easy to peg. But if a bug doesn't crash your app, try to tell us exactly what adverse effect it does have. Sometimes we have a hard time assigning a priority to a bug because we don't know why or how the bug affects you.

• And the number one secret to getting your bug fixed, (drum roll please...):

  Send us your bug in the first place! If we don't know about it we can't fix it. We really, really want to fix any and all bugs that keep you from easily developing your application on the BeBox.

By day, I work as a software developer for Switchview Inc., a Canadian telecommunications business. But at night, I become Double P Software, developing programs for several clients in Canada and for developers on PC and BeBox platforms. I've developed games, such as Dragon's Lair, Space Ace, Brain Dead 13 (Readysoft Inc), written problem-solving applications (Waterloo Engineering Software), and built custom, real-time control systems for high-resolution projection systems (Electrohome Ltd.).

I started in electronics when my uncle introduced me to "Electronic-Logic," used for controllers of sorts. We built an entire railway station: Tracks, trains, lights—all controlled in real time. Then came the first microcomputers, Z80, ZX Spectrum, Commodore64/128, Amiga, Pcs... and now the BeBox. Progressing from one to another I have loved the possibility to be creative as a programmer, to create something completely new. At school I was already programming on contracts for the Academy of Art in Poland and then created special effects for the SFI movie "Snake Valley."

I love the power of creativity that computers give me; but I need a powerful, flexible programming environment that's driven by an easy-to-use and powerful OS. I also need a system that allows various peripherals for direct hardware control, that provides communications via network or modem access to the Internet, and that's FUN to program and use, intuitive and smooth (not like some "windows" are).

When a friend introduced me to the BeBox, I saw an opportunity to be a part of a growing community and to be able to contribute to the new OS, which is not a hog like some other systems. And the machine itself has exactly what I need: Power, graphics, the GeekPort™, and for now at least, relatively small competition.

I love the responsiveness of the GUI, the flexibility in using PC peripherals, and the great ideas in the OS, such as the database. On the other hand, I would like to see a few things change: For example, I prefer an Explorer-like browser, rather than Mac-style folder windows. Also, some parts of the window design are less than ideal: I would like to be able to resize a window by grabbing any edge, for instance.

As for products that I'm thinking of producing: I would like to address other software developers so the software base for BeBox can be much bigger. I would also like to address the needs of Musicians by working on MIDI software for controlling MIDI equipment (patch editors...) and sound (accompaniment).

Other plans I have include porting the Timex Data Link communication protocol, creating an add-on for a universal HTML parser/browser that could be used for Web browsing and pop-up (balloon) help boxes for all applications. I'd also like to integrate a web browser, mail client, FTP, and user groups (Internet news) into a single shared package, so anyone can take advantage of those facilities.

But in general, I'd like to share my experience in software development and tools for programmers. I believe that the wheel should not be re-invented so many times. Every single invention should be available to everyone for immediate use and every developer could then concentrate on new tools and inventions, allowing everyone to grow much faster.

Last time, I wrote about hardware unbundling and how it seemed to be working just fine for our customers and for us. I also promised, or threatened, to address the much thornier topic of software bundling in my next mutterings. Alas, my two weeks are up and there is no escape; our newsletter editor is a person not to be trifled with, and she combines this with an elephantine memory, truly a formidable combination of attributes. Resistance is futile.

Whereas hardware bundling stimulates powerful emotions, these pale into insignificance compared to the reactions generated by software bundling. In particular, application developers become very upset (and with good cause) when hardware vendors begin to invade their turf by bundling applications that compete directly with third-party products. Users may like the idea of getting "free" software but, of course, it isn't really free and it restricts competition in the long run.

Let's deal first with "shovelware." Shovelware is simply the practice of including mostly tired old CD-ROMs, a few restricted apps, and the obligatory free samplers for CompuServe and America Online with a hardware platform, advertising it as "up to or more than $1000 worth of free software." Unless you have a burning desire to browse the full text of 1991's "Time" magazines or to play the first two levels of a 70-level adventure game, you may find shovelware a little disappointing. If you believe that it's worth $1000, please call me to discuss some real estate opportunities I happen to have available for your investment dollars.

Needless to say, you won't be able to buy a BeBox with "up to $1000 or more" of free software anytime soon. We ARE planning CD and on-line software samplers, but we won't pretend that they take the place of real applications.

A less common but more significant form of software bundling involves a hardware vendor preloading usable, useful applications. Be's philosophy on this is simple: Avoid competing with our application developers and avoid giving one developer an unfair advantage over another. In practice, this means that we'll include with our hardware all the basic software required to provide a comfortable environment for developers and users alike, but no more. Based on input from developers, we have included, or will include, items such as standard graphics and networking APIs, a simple text editor, and sound players. It can always be argued that by including, for example, a MIDI player, we're competing with a developer who could offer a better one if only we weren't unfairly excluding him or her. Here we apply the "reasonable person" test and, yes, there are always gray areas. Nobody would argue that we shouldn't "bundle" an API for reading and writing files, nor would anybody argue that we should bundle a full-featured video editing suite. There are many less clear-cut examples, such as a web browser. This has become a requisite on all computer platforms, particularly on the BeOS as all our on-line documentation is, well, on-line, and in HTML format. In situations such as this, we'll provide a "good enough" solution, leaving the field open for developers with better, more extensive, or more innovative solutions. It will be hard to please everybody all of the time, but we'll optimize our approach to come as close to this as possible.

Before I jump into this week's topic, a correction. Two weeks ago I discussed the opportunities for more interesting audio afforded by DVD, referring to these opportunities as the A behind the V of the Digital Video Disc. It turns out I was mistaken, not about the potential for better audio, but about the V: It doesn't stand for video, but for versatile. We agree. Others even find it a little too versatile. Hollywood and other contents owners haven't yet reached an agreement with DVD manufacturers on ways to protect their intellectual property from DVD's versatility. We might have to wait a little longer for DVD sales to take off, even if Toshiba bravely claims to be going ahead with an October 96 release.

This week I'll discuss our e-mail client, included in the upcoming Developer Release 8 of the BeOS. I expect we'll get questions or even criticism for "bundling" an e-mail client, and I'd like to take this opportunity to clarify our position on the matter. You might also want to refer to my related article, "Bungling Bundling," in Issue 1-9 of this newsletter (it's on our web site at http://www.be.com/about_be/benewsletters/Issue09.html).

E-mail is so nice and useful we can't conceive of a personal computer without it anymore. Windows 95 includes a mail client, the Macintosh had the ill-fated PowerTalk, one of our engineers, Robert Polic, also an avid and prolific contributor to this newsletter, wrote BeMail for the BeBox. A question immediately comes to mind: Is this the first of many third-party opportunities Be will take away from application developers as the BeOS expands its capabilities? On the surface, yes, but a look under the hood will convince you we're actually creating opportunities.

First, Robert wrote BeMail as an application. The mail client can easily be replaced by a third-party application. Unlike what we've seen on another platform, no hidden hooks, no hard-to-delete web client icon. One might object it'll be hard to sell a third-party mail client while Be's is "free," included with the BeOS. Eudora is a good counter example. They offer a base level version for free and charge for the "Pro" client. Exchange, included in Windows, doesn't prevent Eudora from selling well on that platform. It's simply a much better, richer, nicer product—at least I think so, I love it and I use it on my Pentium system as well as on my Macs.

Second, to make e-mail matters more hospitable to developers, Robert has built an e-mail API into our system, and anyone can use it to write something better than BeMail, or more suited to particular needs, or integrated into another application. Third, we'll go even further and release the source code of our mail client as an example, illustrating system features such as the database, the network, and drag-and-drop.

Hopefully, someone will shame us and write the next Eudora, or the next Claris E-Mailer. That would make Robert proud, and he stands ready to change his e-mail API to suit your creative drive.

Tons of mail this last week, yet barely a word about GUI. Miracolo.

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads. To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/about_be/mailinglists.html.