Be Newsletters - Volume 1: 1995–1996
I want to thank all of you for the warm reception accorded to our baby. And I want to offer apologies. We were not prepared for the response, the volume of inquiries and the interest from software developers and prospective customers. As a result, many of you found the timing and quality of our response lacking. Please accept my apologies.
We are hiring and we are using the Web. On the hiring side, we now have CK Kaun, Valérie Peyre, and Maureen Miller respectively in charge of developer technical support, responding to customer and press inquiries, organizing demo days and trade shows and other public events. As you can see on our Web page, we're still hiring and hopefully will continue on that mode for a long time, albeit under less pressure.
However, before we address our Web page, a word on infrastructure, company size and the type of individuals we are looking for. Many of us worked for large, prosperous and benevolent companies. We also found out that work became compartmentalized and politicized. As a result, customers got a product that inevitably reflected the size, style and mores of the group producing the product. Some tasks, such as picking detritus of a beach, can be effectively compartmentalized . Others, such as scaling a North face, cannot. We hope you see in our product the work of a few people who made all decisions (in HR-speak, empowerment) over a large span of the product. For instance, Steve Horowitz wrote the user-interface browser (the user shell), all by himself, Benoit Schillings did most of the database engine, the graphics engine and the file system and Joe Palmer the motherboard. And our VP of Engineering, player coach as he is, wrote the kernel with Cyril Meurillon. Soon I'll have exhausted the whole engineering roster. You got the idea, we are looking for people who can carry on their shoulders and inside their minds a broad range of our activities. Be these sales, marketing, administrative or engineering. This will allow us to respond more flexibly and more creatively to the opportunities - or the crises. If you think you can help us grow this baby, e-mail (text only) your resume to jobs@be.com or fax it to (415) 462-4129.
Now, the Web. You have seen the beginning of our use of the Web as a tool to make our relationship more pleasant and more productive. Your questions and comments feed the evolving FAQ section and we will continue to put all our technical documentation on our site. We will not stop at programming manuals, diagrams, pictures of the product and the team. We will publish programming examples and the source code of the applications we've written, or that others will let us publish. We will do the same for the drivers we've written for graphics, networking and other add-on cards. Perhaps we'll get the occasional egg on our code, that'll be good for our soul, and it will help you modify these for your own use or in writing your own.
As always, please let us know what you think, what we should emphasize or do differently—not that you've been shy thus far. We enjoy the feedback and the discussions. They're fun and fruitful.
What were they thinking? The thought has crossed each of our minds at one point or another, when confronted with some new product or API. There's no doubt that this thought will cross the minds of not a few of our developers as they explore the Be system. In this space each issue we'll pick a subject that we get questions about, and let the engineer responsible explain the design choices, describe what they feel are the merits and drawbacks of their approach, perhaps give tips and techniques on how best to use a certain feature, and generally try to give you the developer a better understanding of what went on in the design of the machine. Not that we expect to replace or circumvent the documentation; the Be Book is still your reference for the API.
So, generally speaking, what were we thinking when we set out to create this machine? Well, first and foremost, we wanted to make available to developers a collection of technologies we thought were cool, technologies which weren't showing up on the mainstream platforms of Wintel and Mac. We wanted to make the machine lean, cheap, and fast—things not many people are accusing the mainstream platforms of being. And we wanted to help change the model of software distribution; with the emergence of the Internet and more specifically the Web, we wanted software to be distributed electronically, with frequent updates to take advantage of new features (and fix the inevitable bugs) as responsively as possible.
What new technologies were important to us? Well, to understand this you must understand a bit of the background of the engineers at Be. Most, but not all of us come from Apple. This has been, I think, both good and bad. There was certainly a lot to learn from the Mac about UI and consistency, ease of use, and an elegant "look and feel". From the point of view of OS technology, the Mac is not the place to look for great insights. So luckily we have team members with a fairly healthy dose of experience with other, even more real Oss.
So our OS certainly owes more of its multitasking, multiprocessor heritage to UNIX, Mach, Chorus, et al than it does to the Mac Segment Loader. We thought it was time to try to offer a system with the look and feel elegance of the Mac, with a real OS underneath. I really don't think any system out there has delivered on that promise as we have. (X Windows is not very popular here at Be).
Supporting multiple processors also was a very important factor. There is just no excuse for a multitasking personal computer which is expected to maintain user responsiveness, display multimedia data types, and manage a sophisticated communications protocol to the net not to have more than one processor to throw at the jobs. Compatibility with legacy applications prevents the big guys from doing this (it's not because they're not smart —I can't say that because even we didn't do it when we were at Apple). That's the good news about the size of our installed base—it hasn't prevented us from bringing these technologies to the market, at what I think is a very reasonable price. Over the next few issues, we'll go into some detail of the technologies we think are important in our machine, why we did them at all, and why we did them the way we did. I hope that this sort of information will make for interesting reading, as well as helping you better understand the potential of this new machine.
Developers are people who want to make something happen with a BeBox.
A developer is a single person working on a photo slideshow application or a 500 person company writing a relational database. Someone hooking up a thermocouple to a serial port is a developer.
The BeBox is an opportunity, and we want to see where you'll be taking it. We have no expectations or preconceptions, so if you are doing anything with your BeBox, you are a developer that we are interested in.
Our job in developer relations is to give you all the information you need to successfully create your dream on the BeBox.
Our job is to represent 3rd parties inside Be. We'll be representing your interests to all segments of Be engineering, marketing, sales, or whatever else. We know that if we can't do something, or if we can't find the answer easily, then neither can you. Our job is to go through the pain first, so you don't have to. We'll be doing that by creating sample code, keeping Q&A; information current and accurate, answering your individual questions, creating events to attend, and other things.
We'll be doing that by listening to you, reading everything you write to us, and asking questions to help us better understand your needs.
Be is a small company, and the developer relations group is a small part of a small company. This means that we will need some help to be able to give the best service to you. This corner of the Be newsletter will be the place where we'll talk about upcoming developer issues, and keep you informed about upcoming events and software releases.
This section of the Be Newsletter is devoted to YOU, the person or people who are making the knockout applications for the BeBox. We'll be profiling a Be developer each issue.
Corporate Identity
We'll name your company here.Who We Really Are
Your names, and a brief description of what you want to be known for.What We're Doing
An overview of your product, or the ideas you're pursuing. Like "We're deep in development of a robust client-server paradigm that fully leverages the high bandwidth of hardware compressed InfoSuperhighway quotes in Web sites."Why Be?
Give us some reasons why you chose the BeBox as a development environment. Like "We chose the BeBox because we thought the time had come for yellow window title tabs"Quote of the Day
Something pithy to go down in history with.
We'll be choosing people somewhat at random for this, so be prepared.
