|
Be Newsletter
Issue 1, December 6, 1995
Table of Contents
Giving Thanks
By Jean-Louis Gassée
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.
What Are We Doing About It?
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.
Be Engineering Insights
By Erich Ringewald
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.
Developer Relations
Corner
By C.K. Haun ,Valérie Peyre, and Christophe
Droulers (France)
Who are developers?
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.
Be Developer Profile
By C.K. Haun, The Developer Guy at Be, Inc.
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.
|
