Being united. Those two words have been used a lot lately by many people in the industry. Not just in the post-BeOS community, but in the Linux community, and in the world in general. However, for the post-BeOS community, what do these words really mean, to "be united"?

Being united means preventing fragmentation, the type of fragmentation that has turned the Linux OS into a mess of competing technologies that render it unusable for human beings. We are all here for a reason, we love BeOS, and we don't want to let go of it any time soon. We *know* it is a great way to experience computing, and that it is an elegant and usable design of an operating system. Being united means working together as a community to deliver this OS into a new era, one of open source, where we never become victims of an single companies down fall, or economic problems. To do this we must work together, and be united.

BeOS is now gone, locked away in a vault somewhere deep in the heart of Palm. Can BeOS ever be matched? Can we recreate the OS we love? Yes. Not only that, we can make it even better. The future has been forced into our hands, and we are running with it. And we will have an open source version (a couple, actually) that can never be taken away from us.

Or can it be taken away...?

There will come a day, hopefully in the near future, where we have initial releases of various post-BeOS open source offerings. There will be a lot of hype. There will be a lot of interest. And there will be a flood of people that want to try out these new, user-friendly OSes that are freely available, easier to use than Linux, and have the speed and grace that many have never seen before. And we will see commercial interest.

Commercial interest is both a blessing and a curse for open source post-BeOS offerings. A blessing, as it could bring in returns on everyone's efforts. It could bring us more applications. It could bring us the satisfaction of knowing that Be was ahead of their time, and their game, and we were all right. It could bring us some small amount of success (small in the world of Microsoft is still huge in the world of BeOS).

It also attracts those that want to take advantage of our work. Those that take our freely available code and change it into something we don't want. To call it their own, and to sell it away. Okay, so maybe I'm being a bit dramatic here, but you get the picture. IBM is making their own distro of Linux (along with everyone else in the world). This is all fine, as Linux is under GPL, and they must release the source to any of their OS-level work back to everyone else.

Speaking of OpenBeOS, and other post-BeOS open source platforms to some degree, what if IBM saw the potential of OpenBeOS, came in and changed it dramatically, and then closed their source (which they can do), and sold it, putting millions of dollars of marketing muscle behind it, and called it "OpenBeOS". All of a sudden, the world knows "OpenBeOS" to be something that is truly NOT OpenBeOS, only because the commercials said it was "OpenBeOS". But it's not OpenBeOS. It won't even run OpenBeOS applications. It doesn't look or feel anything like what BeOS did. What can we do? Nothing. Nothing at all. We sit back and watch it all happen in dismay and anger.

Unless we can already be united.
The Linux distributions realized that being united, was in fact, to their advantage but now realize that it is far too late in the game to really have an impact for them. RedHat isn't even participating. They do not need to. They already have market share. They already have customers. They already have clout.

By starting out early in the game, *we* (all the Open Source BeOS-compatible Operating Systems (OSBOS - not to be confused with OBOS) all stay together, united, have a chance. If we already have standards set, have all the key players involved, and the entire community behind us, then the community itself pulls a lot of clout. For a larger company to come in and try to work against us, it would be a "Public Relations nightmare" for them. Our unity would force them to play nicely with us. It is not a guarantee that this will prevent such actions, but it's a better chance than if we don't do anything at all, and do not remain united.

SURPRISE!! we already have this unity! All the major players (OpenBeOS, Cosmoe, BlueEyedOS, and Zeta) are behind this idea and unified. Many of the still existing BeOS-based companies are behind this idea. And most of the community is behind this idea. So how is this idea a reality? Through beunited.org (spelled now without any capitals, btw).

The idea of unity did not originate at beunited.org. It originated in the minds of the users, developers and companies out there that wanted to see OSBOS platforms succeed, and have the success that BeOS didn't. It came from those that had a dream, it came from all of you!. The idea formulated and evolved through beunited.org, over the last year, through discussions with everyone in the community. The result was that it also caused the evolution of beunited.org itself, to what we now see it to be today.

This change has caused some misconceptions about what beunited.org is about today. You know what beunited.org is today. But let me tell you what beunited.org is not...

#1 beunited.org is NOT about making money:

beunited.org is NOT, and we cannot stress this enough, NOT a commercial company. It is a registered, non-profit corporation. There are rules we have to follow, through Legal regulations that dictate that we cannot be in this for profit, and we cannot participate in for-profit activities. We must obey the laws and penalties that enforce this.

This non-profit status of beunited.org was by design. Some of you have voiced your opinions about "where's the 'RedHat' for OpenBeOS?" They are coming along (look towards yellowTab for leadership here). But they are not coming through beunited.org. You see, when we went out and talked with people throughout the community, and within the various OSBOS platforms, we realized that two things were desperately needed:
1) a set of standards to promote cooperation between the various post-BeOS platforms; and
2) a commercial entity that represents these platforms to turn their work into a commercial success. We also realized that one entity cannot be both. There is a serious conflict-of-interest there, and we decided that beunited.org must avoid this at all costs.

beunited.org was then restructured to become a unifying factor, not only between all the platforms, but between the people who use then, and the companies that make money from them. beunited.org is structured so that it cannot, in any way, seek to profit from this unification. It is structured to be a place where connections can be made between users, developers and commercial companies. It is structured so that the community is 100% a part of it. It is structured to be the home to all of us that have the dream we won't let go of, and to be united.

#2 beunited.org is NOT a US-only organization

beunited.org, although registered in the state of Colorado, in the USA, is NOT, I repeat, NOT, in any way, a US only, or US-attitude organization. Our President, the leader of the organization, is not even a US citizen! The members of our Board of Directors reside around the world, and the membership in the organization is represented in every continent of this planet. Even myself, Chairman of the Board, has spent nearly one third of my life outside of the USA. beunited.org is *International* and is in the process of filing the paperwork to be an officially recognized as such. This organization represents everyone in the world equally. All you need to do is love the BeOS.

#3 beunited.org is NOT about controlling standards

beunited.org is not about controlling OpenBeOS, or any other post-BeOS platform. The executive of beunited.org has absolutely no say in the standards. You do. You all do. beunited.org will never dictate what will, or will not, be a standard for OSBOS. beunited.org will only facilitate the community in letting it determine this. beunited.org does this by facilitating the discussion between the various platforms to present what they think should, or should not, be OSBOS-compliant.

The Standards Committee at beunited.org votes to decide on these standards. There is equal representation from all three areas of the community on this committee - the users, the developers, and the commercial companies. Each platform will be represented. beunited.org has no voting seat on this committee. beunited.org does not control the standards set by the community, it only provides the services to have them created by the community and serves as a location for them to be published and upheld. The idea of OSBOS is not to create a single operating system. It is not to create an operating system that is the duplicate of another. It is to create a standard platform for developers.

All of you know that one of the biggest disadvantages BeOS has was the lack of applications. Fragment that into 3 or 4 (or more) different platforms. How many applications do you have left for a single platform? Not many at all. So, beunited.org exists to create an easy method for developers to "port" their apps between platforms, and with standards means that they just recompile them.

To do this, you need standards - you need a matching set of Application Programming Interfaces (APIs). But we have this already, you might say, it's called the BeBook - the BeAPIs - they already exist, so why do we need beunited.org? Because the BeBook is just the beginning, it's not the end. As the platforms develop, and they will, they will be creating new and better API's and new and better ways of doing things. It is at this point that unity really becomes important, and why having this unity before the fragmentation has a chance to rip us all apart is even more important. beunited.org brings the platform designers together to maintain this "new" set of BeAPIs, together as one. To keep future applications just as portable as older ones.

What beunited.org is for you

beunited.org has been redesigned, from the ground up, to be the home to the community - the entire community. A place where we both support newcomers and help old timers. A place where we can all come to the dinner table and discuss our activities calmly and collectively. A place where money is not an object. A place where cooperation between family members, no matter how different they seem, is important.

When last we left GUI, he was just learning to create windows. He could name them, set flags, resize them and do all sorts of things with his windows. But nothing more.

I want to talk a little about where he has gone since then (not too far) and where he wants to go. No, opening windows is not enough for him!

GUI is a "little language" project. Not a full fledged application building language with loops and all, but a simple language designed to ex press how a BeOS GUI can be built. This has both positive and negative implications for its future. Many things like looping, decision points and typical "traditional" constructions are probably not in GUI's future. You will never be able to write an app in GUI. That isn't the poin t. The concept behind GUI is that it is a simple language that a non-programmer can use. For the most part, order of things doesn't matter. Y ou can define your controls in any order. GUI should have some dynamic placement tools so that you don't have to know which pixel a button sh ould start on. Instead you should be able to say "This button should start at 25% down and 25% across". Or "this slider should be 17% of the window wide".

Ok, so we have dynamic sizing of contols. That is pretty cool. But it doesn't help me to have a nice looking GUI that we can't *DO* anything with. How will I use GUI to make an app? Good question. The idea is that you can register an application (optional) and message name for whic hever control or window virtual function that you choose. This means that your application need do nothing more than loop on messages and res pond to them. OK - so that explains how my application can hear from GUI. How can my application respond to GUI? Well, one way is certainly b y sending messages back. You can send a message to GUI to have functionality run.

In effect, GUI makes writing a user interface into a simpler, more seperated task from writing an application. One advantage to this is that others can do this. If GUI were to become popular, non-programmers could use GUI to build the interface while developers made the functionali ty behind it. Another possibility for GUI is in non-C++ languages. Say, for example, you wanted to write an app in AWK that used a GUI user i nterface. The easiest thing to do would be to build your own version of AWK that could send and receive messages, treating them like lines of input. As onerous as this sounds, it is still far better than trying to port the entire Interface Kit to another language. The person choosi ng to port deals only with one class, not 30.

Another advantage to using GUI is that one can move controls, change them in many ways and never have to recompile. This is good for the deve lopment process when you are trying to get everything to line up. It is also a feature that other operating systems don't generally have - th emers would love to have this. Not just customize your desktop, but customize your apps.

There have been a bunch of details that have been going on that have consumed a lot of the admin team (and especially my) time. It seemed lik e a good time to bring everyone up to date on a few things.

The first (and most) exciting is that we are going to become an entity. Most likely a not for profit organization in the U.S. There are a num ber of reasons for this. One of them is to allow us (OBOS) to accept donations. A number of people have contacted me about this. When it all comes about, it will be a good way for those who want to help but can not code to help out. What would we do with this hypothetical money? To start with, not a whole lot. There are a few developers who could use books or systems. A prime example is the Kernel Team, who often need t wo PCs to debug kernel issues. The possiblity has also been discussed about moving our web site away from SourceForge and onto our own server . This would allow us more flexibility and freedom. Finally, the thought had crossed my mind that we could trade money for time and code in s ome cases. Whether this is paying code bounties or paying someone to write code, I am not sure. But this could facilitate some of the areas t hat are not moving. This is not really decided - these are just some ideas. But becoming an organization is a definate.

The second (and most tedious) is our name. As many of you are aware, we have been looking for a new name for nearly 20 years now. ;-) Let me tell you - I have a whole new respect for people in marketing. This is *FAR* harder than I knew. You, our loyal readers, submitted more than 3000 entries. We (Stuart McCoy of CDT and I) have filtered this down to what we believe are the 75 or so most usable names. Some names are ju st lawsuit magnets. Some were repetative. Some had obscene or unacceptable meanings in other languages. The admin team is, collectively, narr owing the 75 down through a voting process. Soon we will be having a poll for you, the users, to enter your input. And we will get this new n ame process over. Believe me - if it has been annoying and painful to wait, it is no better from this side of the fence.

So. What took so long? Well, the short version of the story is that we were looking into keeping our current name. We (the admin team) looked at all of the names and decided that we like OpenBeOS or BeOS better than any other. I went out and got some legal advice on this and after some thought and consideration I decided that the personal legal risks were greater than I was willing to assume. The possibility of damages against me personally was the final factor. So we revisited the list and argued each name for a while. Yes, it has been a long time. It turns out (to my surprise) that these is a good reason that companies pay big dollars for good names - they are few and far in between. On the oth er hand, many names that are not so great become common usage. One example - the laundy detergent Tide. I grew up with that name, But if you really think about it, what does the rise and fall of a body of water have to do with laundry? For that matter, what does Smucker's have to d o with jelly?