Well, not for me, at least, not as the newletter editor here at OpenBeOS (about 6 months now). But a whole lot has certainly changed since a year ago today. The community has moved from a complete dependence on Be, Inc. to a strong, substantiated belief that we actually can go it on our own.

The handful of people that have been working hard on OpenBeOS are a rare, hard-to-find few. They deserve all of the credit thus far. They are putting their blood, sweat and tears into keeping all of our dreams alive. Fighting an uphill battle - no, climbing Mount Everest while battling off gremlins, bugs and every other bit of code varmit you can think of - all for us.

It is an insurmountable task they have set out to do, and they are succeeding. They have gone further in the past year than many had predicted, and farther than many can believe. But this past year for them has meant missing out on a great deal of things that most of us take for granted. Such as time to relax. To watch a movie. To get a decent night's sleep.

So, for the birthday of OpenBeOS, and the newsletter that marks the 1st anniversary, we open the mic to them: to let you hear a few words from them, to let them tell you why they are doing it, what this past year means to them, where they see our destination, or just whatever they might feel like saying in the wee hours of the morning between C and C++.

I was not one of the first developers to join the OpenBeOS project, but I am sure I would be the last one to leave. When I decided to join, it was simply because I decided I wanted to help with something that I believe could become one of the most interesting open-source projects ever. It looks like I was right.

Working with all the project members has been a pleasure. Sure we had our share of problems but it is just to be expected. The cool thing is that our objective seems to be the most noble of all... Do the right thing. All we want to do is create a great operating system and, maybe, people will even use it! At the end of the day, it will be worthwhile anyway as we would have had lots of fun in the process.

DarkWyrm
App Server architect

I envision having an operating system which is light, fast, small, and inexpensive. Be did it. We'll do what they did and more, which is why I'm slaving away on the app_server.

Especially after reading about the misadventures of Micro$oft on The Register, OSNews, and Slashdot, I am convinced that if a distro is done well, it'll blow the doors off the desktop market, which will make us all rich and famous, and then we'll tackle curing AIDS and then, uh.......oh, I'm rambling again.

Tyler Dauwalder
Storage Kit Lead

BeOS was born,
BeOS rocked the casbah,
BeOS became BeIA became Palm's super expensive toy that no one else was allowed to play with,
OpenBeOS was started by some folks with way more foresight (meaning balls) than me,
I stumbled upon OpenBeOS and realized how horribly sick I was of having nothing but free time,
the Storage Kit team spent forever trying to figure out what they were doing thanks in great part to the brilliant blindfolded leadership of yours truly,
coding finally began,
I wrote a few hundred lines of code and smiled a lot,
Ingo showed up and wrote 2 billion lines of code in something like three days,
BMimeType showed up and told us he was way too big and we'd never finish him so we made up a story about needing to work on something mysterious and nebulous called The Registrar,
other nice people showed up and helped tie up a few loose ends despite never hearing from me,
Ingo wrote a few billion more lines of code while I tinkered with the MIME sniffer,
after that Ingo introduced us to someone he likes to call The Registrar and I said "I feel like working on a MIME database" so I did and now you're up to speed.

Axel Dörfler
BFS, Kernel, Networking

When Michael Phipps announced the OpenBeOS project, I didn't believe it was the right thing to do at that time: it seemed to be a lot of hard work which would take years to complete. In fact, I didn't even take the project too seriously at its beginning; it was announced very shortly after the Palm deal, and I didn't know anything about this Michael Phipps and if he was capable to initiate such a big project successfully.

Obviously, he was. While I was waiting for a definitive answer from Palm (I would have loved to improve the real thing instead), he did a great job at getting the right people together. Although I completely missed out that important phase of the project, I eventually realized that they have come up with a good and doable plan to recreate and reanimate BeOS.

Together with Bruno G. Albuquerque (we were already working together as part of the Dr. Zoidberg team), I joined OpenBeOS to work on the BFS implementation (due to my work on the BFS-tools, http://www.bebits.com/ app/2788 ) which later made for the virtual file system layer in the kernel which is still my main region of interest.

I very much enjoy working (and/or talking) together with a group of very good developers from whom I learned a lot in the last months. I think I am in a relatively safe place when I say that R1 will happen.

Phillipe Houdoin
Networking Lead

I joined OpenBeOS because it was best house for the open source PDF Writer driver that Michael Pfeiffer, Simon Gauvin and I were working on. And it was the best contribution I could make to OpenBeOS at this time too, as my skills then were mostly print kit related only.

Since, after being a net kit mailing list lurker, I joined the network team when I commited, as proof-of-concept at first, a socket driver providing the so-called "sockets == file descriptors" support. David Reid gave life to network stack in shorter time than I could read his one-day contributed code, but then left us after a short journey in the kernel team. I got promoted as new network team leader, so someone has to read all his code I guess ;-) His orphan network stack is crying to reach alpha stage, so we are working on this next milestone: release a first version to alpha-testers.

One year later, I see developers uniting, working together and (even better!) learning from each other in their biggest collaborative project *ever*: OpenBeOS. Heck, I'm even part of them! :-)

Let's keep for the future this motto: Faith, Focus and Fun.
Happy birthday OpenBeOS!
Happy birthday to all BeOS community!

Mike Lee
Storage Kit

I like BeOS, it's the only OS I actually enjoy using. But it has some vital features missing.

The biggest challenge is getting the time and the CVS access. Shortly after joining OBOS I started a new job, with a nasty firewall so bang went my CVS access and most of my time.

My fears: other developers being lazy sods like me ;) and OBOS going completly off track. Some of the ideas on GE are just scary, but others I'd love to see implemented.

Andrew Edward McCall
Preferences Lead

I joined the project simply because I believe BeOS *must* survive, its the only operating system that has ever offered the strengths of UNIX, the simplicity of MacOS, and the multimedia capabilities of the Amiga - all rolled together into a seam-less experience. I have also always wanted to write an Operating System. I read the older posts about Linux with envy, wishing I was around during the earlier days of the Linux kernel, well now I can be apart of something like that, but with a better goal.

One of the things that keeps me around BeOS is the community. The BeOS channels on IRC, and BeOS related mailing lists are always buzzing with people who are willing to help and share ideas and suggestions. I think that the community itself deserves a big cheer for keeping itself so strong over the last year.

Currently I am working on tidying up all the Preflets, getting as many command line applications working under the new kernel as possible - which includes a little kernel hacking where I am able, and investigating a replacement for Net+ using existing rendering engines such as the ones from Konqueror or Mozilla.

I am really excited about OpenBeOS, I know that what we are working on is the future OS. During the peak of BeOS, around R4.5/R5 a lot of Linux advocates were talking about how good BeOS was, but they wouldn't use it because its not Open Source Software.... well pretty soon they are going to have to find some new excuses as to why they don't.

I hope that we are able to live up to the dream the engineers who originally wrote BeOS had. While the management of Be, Inc may have sucked, the products didn't - I would love for some of the original developers to get hold of OpenBeOS and think, "Wow, they did it... now what was that feature I always wanted to add but management wouldn't let me....". They gave us the vision, now I hope we can give them something back.

The only concern I have is that we are going to produce a mass of incompatible distributions and software. We need to take a leaf out of Microsoft's book in this area: while their Operating Systems suck, their management and marketing doesn't.... hmmm I wonder if I would have still liked BeOS if Bill Gates was in charge of Be, Inc now...

Angelo Mottola
Kernel

Hello all, my name is Angelo, and I am proud to be part of the OpenBeOS project! I kinda joined it 1-2 months ago, even though I was following the development since long before. Why didn't I join earlier? Simple: because my main interests were the kernel and the game kit, and while the first scared me a lot, working on the second was premature for the project in my opinion.

Later though I got courage and started working on the kernel; since then this is still my main focus. I don't consider myself as a kernel hacker, but I'm trying to learn ;) This is proving to be a *great* experience to me, and working on such low-level stuff is very fun! I strongly suggest everyone with good C skills to start studying the kernel; this will be the start of a wonderful journey...

Currently I'm working on the scheduler and the threading system in general; it's a fun topic to dig into. In the future I plan on adding more BeOS-like features, and if I find the will, I'll work on adding signals support (if the NewOS people don't do it first), which is needed as soon as possible.

What I'd love to see soon is bash running under OBOS, but for this to work properly I fear we'll first need signals, pipes and a tty layer, and possibly more. But I can't wait for the moment it'll run... It'll be a first big step towards usability, with the next big goal being a system that boots into a graphical environment ;)

I strongly believe in this project, and I think we can all do it. Go OpenBeOS, go!

Marcus Overhagen
Media Kit Lead

I joined this project because I always liked the BeOS API more than any other. Programming with the BeOS API is easy most of the time, while it provides enough flexibility. The OS itself is also easy to use.

On the other hand, I was still unhappy with some bugs that Be Inc. never fixed, like the small but ugly Num Lock key problem. After Be Inc. decided to no longer develop BeOS and Michael decided to launch the OpenBeOS development project, this looked like the perfect opportunity to continue by doing the right thing, creating an open source BeOS clone.

I'm responsible for the media kit, and currently working on the internal functionality that get's your audio data from Soundplay into the soundcard. This is a lot of work, but I think we've already made good progress. Luckily some people decided to help me, but as always, more help is welcome.

I have to admit that it's not very fun to invest hours into programming something that doesn't work at once, because it requires many other parts to be done that are not implemented, and you don't get early results. But in the end, everything will work, and certain parts are already starting to work. I'm quite confident that during the following month, the media kit will grow and start being usable.

Jeremy Rand
App/Interface Kit

I got involved in OpenBeOS because I can't imagine leaving behind an environment as good as BeOS. Without OpenBeOS, eventually I will end up with hardware which BeOS will not boot on.

I am currently working on BPropertyInfo and will start work on BDeskbar soon. The biggest challenge OpenBeOS presents to me is trying to find the time to work on the project that it deserves. Its been a great first year and I look forward to even better this year!

Daniel Reinhold
Website, Kernel, Whatever

I was excited about this project from the moment it was announced. I never had a moment's doubt as to the worthiness of the goal, or the achievability of the result.

Initially, I wanted to work on the kernel, but frankly, I just didn't have the kind of knowledge required for this. So I jumped in on building a website when the need arose. It was a blast in the beginning. Such a feeling of power (hehe). But soon, the rigors of maintaining the site, and posting news items, and writing newsletter articles, etc. etc. became too burdensome and was overtaking every free moment I had. So I decided to get the heck out of the webmaster business.

But I'm still around. I'll still post the occasional news item. And I'll still write some newsletter articles. But mostly, I'm going to concentrate on learning more about kernel development. I've already submitted a few things to the kernel kit, altho my contribution is pretty minimal at this point. As I gain understanding, hopefully I can do more.

This project is exciting and scary. Weary and invigorating. More stuff has been accomplished so far than I could have dreamed. And so much is left. I'm still fearful on some days that it will all blow away and that the developers will just head off into different directions. But the closer the project comes to completing R1, the less likely it is such a dreaded thing will happen. If we get to R1 (and I believe we will), then there will be no stopping this monster we've created. It will be a force unto itself.

François Revol
Kernel, User Apps

How I joined the project is quite an odd story. I knew BeOS for some time already, but really only switched to it at nearly the same time OpenBeOS was born... to discover soon after that the former was dead... This really shocked me, and I decided not to withdraw my engagement in BeOS but to push it further and not let it die this way.

Although I'm officially in the kernel team, I haven't contributed much kernel code yet, as I've some issues to deal with beforehand, but I've contributed some userland code and I'm actively following the whole project (planned contributions on the Media side too).

One of the biggest challenges is getting people to understand BeOS is anything but dead :))) I hope to be able to show Linux folks what a real desktop OS is :^) Also, I see *BeOS future as the OS of interoperability, the one that fits anywhere, and brings together other technologies.

David Shipman
Media Kit

As a musician, the idea of writing my own 'instrument' as always held a special appeal... so, a few months back, I opened the BeBook, drank a whole lot of coffee, and finally started to put some of my ideas into code.

When the time came, it seemed like a logical next step to get involved in the Media Kit team - where I could use my knowledge to help, while taking a ground-up approach to an area of real personal interest. I'm currently working on the system audio mixer, in addition to my own media kit projects.

The most exciting aspect of the OpenBeOS project, to me, is what will happen after we hit Release 1. I look at R1 as a 'seed' of sorts; and its certainly an impressive seed to begin with. With proper tending it can grow into into something new and complete in itself - a thing of beauty, with a life of its own, bringing forth strange and wonderful fruit.

Thankfully we have the right people in the garden.

Ingo Weinhold
Storage Kit, Registrar

For awhile, I had been quite busy with my master thesis and then afterwards took a long computer-abstinent vacation down under, so I became aware of the existence of the OpenBeOS project very late. I couldn't wait and join this enthusiastic (but, considering the effort, apparently insane ;-) group in early April, immediately after visiting the very professional- looking project home page.

Since then I've been proud of being able to help out in the Storage Kit team, and I'm particularly enjoying the current work on the registrar (together with Tyler and being supported by IK team members), an inconspicuous but nevertheless important part of the system. Seeing the progress that has been made by all the skilled and motivated people, I deeply believe that we will succeed. "Never give up, never surrender!" :-)

Jason VanDerMark
InputServer Lead

Thinking back to the time of the Palm buy-out announcement, I remember thinking to myself, "There is no way that any company would let such a great thing as the BeOS die. It was so close to breaking into the mainstream. There must be something that can be done." After BeUnited's attempts to license BeOS from Palm failed, I was excited to hear about the OpenBeOS project. I looked at all of the areas that needed developers and figured that the input_server would be pretty cool to work on and is not overly complicated, so that was then. Today we have an input_server with a working InputServerDevice (Nervous) which works with the proto6 of the app_server.

There is still much to do on the input_server before it is totally finished. I am currently working on fleshing out some of the empty functions within the input_server and restructuring everything so that it can work the way it should. I recently added the tracking of the mouse cursor's position into the input_server. It took about 15 minutes to do. Keep watching the input_server team's progress as we start bringing this server to a close.

I think that I can speak for our whole team by saying that attempting to reverse engineer the communication protocol between the input_server and the app_server was the biggest challenge. We literally spent most of our first few months (one day a week) trying to get the info necessary to allow our input_server to simply replace the existing one. After realizing that it was a moot point as the app_server folks had given up on trying to discern the protocol info, we simply stopped worrying about it and came up with our own. Since then we have made huge strides to having our own input_server.

The most enjoyable part of working on the OpenBeOS project is knowing that through our efforts, and the will power of the community, the dream of BeOS will live on. To think that next year come this time we will likely be working on bug fixes for R1, makes the hairs on my neck stand up. If it does that for me, it must do it for others. BeOS was not just an OS, but a way of thinking, the idea of giving the developers and the users everything that they need to enjoy their time spent computing, that is something that should never die. We won't let it die.

When I think about all of the different OSBOS projects, I really think that those that disagree on our choice of license as a basis for fragmenting the developers amongst different projects is sad. We are all doing what we are doing with one goal in mind... the continued survival of BeOS in one form or another. Just think what we could do if we had all of the developers of all the OSBOS projects under the same roof. No duplication of effort, we would probably be close to an alpha release already if that had happened.

Looking to the future, I am very excited. I think that without having to worry about a companies financial future, the OSBOS movements will bring about a new BeOS and that OS will be well received. With a completed R1, the media will take notice as well as new developers and new users. The BeOS community will once again grow and the future will be good.

I would like to say thanks to all of you die-hard BeOS fanatics out there. We are doing this for you as much as we are doing this for ourselves. If you are out there wondering what you can do to help because you can't code/type/draw/test anything or just don't have the time, the best thing that you could do is to keep the faith and help spread the word to others. Start a BUG in your area. Remember, the revolution is coming and it will begin with R1.

Mike Wilber
Translation Kit Lead

Everytime I tell someone that I am working on the OpenBeOS project, they always ask me the same question: why? I don't think I've ever given anyone a straight answer, mostly, it just seems like the right thing to do.

Much of the reason why I'm working on the OpenBeOS project is because I like the BeOS and when Be, Inc. went under, I didn't want to see it go away. Another reason is that I'm tired of Windows and Microsoft's arrogance and monopolistic tactics. I also don't like Linux, it is too hard to use, takes too long to learn and Linux is only free if your time has no value. There is Mac OS X, which is supposed to be good, but I would have to spend much more on a Mac than I would on a PC with comparable features. So, this leaves me with the OpenBeOS.

Just how did all of this come about? Let me enage in a bit of nostalgia and share with you a snippet from a mail exchange this time last year:

>Subject: Developers - which direction?
>From: Michael Armida :
>With the most recent news, where are y'all headed?

"Cedric Degea" :
>* maybe a BeOS rewrite "from scratch".. was very reluctant to the
> very idea proposed by a friend a few montsh ago, but now
> I think I'll offer my help to him. It's been extremly late
> already for me, but it seemed indecent to me to envision
> a BeOS repalcement as long as the company was still "alive
> and kicking", like whispering with a friend what to do after
> the death of a person in the hospital's room of said (ill) person.
> Now is the time..

Me:
This is an interesting idea (rewriting BeOS). Open Source has proven its ability to take an existing API and re-implement it.

It would be a very interesting (and fun) project to work on. The modular design of BeOS would allow for this, in terms of replacing one piece at a time, much as we (the community, not me personally) have done with OpenTracker, OpenDesktop and mail_server.

app_server seems like one large piece that would be challenging enough to be interesting but small enough to be (fairly) quickly do-able. Plus, we could implement enough new features to make it worthwhile (multiple monitors, new widgets, etc).

print_server is a place where BeOS has always been weak, due to lack of focus. A re-write of that would be worthwhile and hard to make worse. :-)

media_server is a piece that many (not me) would be interested in.

cddb is a small piece that an ambitious developer could do by themself.

Finally, the monster. The kernel. I wonder if we could grab something like NewOS or something similar that is small enough to be managable, but advanced enough to be interesting. Add areas and the bus interface API and replace the kernel when possible. This would be the toughest, but it is not unconquered territory - Linux, BSD (X N) , NewOS, Darwin, Minix and other kernels for X86 exist in the O.S. world. I dunno. This sounds kind of like fun. Anyone else really interested?

OK, enough of where we started, let's talk a little bit about where we are.

Website - Our initial website (may it forever be forgotten) was a disaster - I am a coder, not a web developer. Phyte stepped in and designed something much prettier. That lived for a few months, but being our web master is not an easy or low load job, and he had to resign. Daniel stepped in and did a tremendous job, building us a whole new site with a very crisp and professional look. Kurtis and Jesse have taken it over and totally rewrote the backend. It is now smooth and database driven.

The Documentation team has been busily working on preparing the BeBook for the changes that the developers are making.

Creative Design Team has been actively helping in the name change and site design issues.

There is a QA team that is looking over our alpha and beta software and helping us make it better.

Finally, there are the coding teams. Most are in alpha or very close. The big three that are the furthest away, Kernel, Media and Interface Kit are the biggest three pieces - and we knew this going in.

OK, so that covers past and present. Let's talk a little about future. There are some obvious milestones coming up. Kernel boots from hard disk. Networking and BFS integration into Kernel. First "real" app_server. Media Kit playing its first movie. Then, the big one - the first time that *every* kit boots up in one cohesive piece. I really want to see this. Call it your Christmas present to me, but I really want to see this by Christmas. I would like to start the new year with an OBOS release. I really believe that we could do this. But it will have to come from you.

Yes, you. We can't count on others making big contributions any more. We did that for years with Be. I did it, too. We waited with baited breath to see what magic would come out of Menlo Park. Rumours flew, debates raged, and we waited. I know that hind sight is 20/20, but imagine if the community working on OBOS now had gone to Be and said "Hey - we want to help. Assign us a kit or two".

The BeOS community can't afford to sit and wait anymore. There is too much to do. Code to write, tests to perform, documentation to write, etc. We have reworked the website to be *far* more friendly to the person who has some time to contribute, but can't make a long term commitment. We are trying to keep small tasks filled in on each team, so that if you have a half day for coding, you can get an item off of a list.

Most of OBOS has been written by 15 people. Yes, really. There are many tasks that are easily understood and completed by an intermediate programmer. Not one of those 15 people ever wrote a real OS before (as far as I know). I contributed to a proof of concept toy, but never the real thing. This is all new to me and to most of us. If you can write an application as complex as BeBounce, you can help.

OBOS is a large project. We knew that going in. But look at the progress. If you have doubts, sign up for cvs notification. Not a day goes by that there are not 10 checkins (or more). Each check in, each improvement challenges and encourages the other developers to do more. Momentum is a phenominal motivator.

So, what happens after a first release? Obviously, bug fixes and patches. But that activity will taper off after a while (especially since we will test it before shipping it). Ever since the conception of this project, I have had to talk people OUT of adding features. That may seem crazy to you. There is a real reason, though. We have a complete, coherent, complex design. None of us worked on it, and none of us understood it completely. With the completion of R1, we will be able to say that we understand the issues very well and we can more reasonably decide what to do from there. I expect that there will be a lot of discussion among the teams about what to do and where to go. Certainly the community will have a chance to give input. You do now, through Glass Elevator. But the ultimate decisions will have to come from the people doing the work.

I would like to thank all of the people who have contributed to the project. Most of you I have spoken with, either email, IRC or voice. I appreciate, more than you know, all of your work. The long hours in front of the keyboard that you spent are worth a lot. Time away from your families, friends and other interests to build something bigger than all of us is a sacrifice. I hope, before too much longer, that your hard work comes to complete fruition.