So, I'm sure you're all dying to know about the new grand unified CppUnit testing framework we have. What? You haven't heard of it? Color me unsurprised. :-)

Part I - Running Tests

For those of you who are purely interested in helping us out by running the tests on your own computer, this section is for you.

First off, you'll need to slurp a copy of our CVS repository onto your computer. Next, you'll need to build the entire tree (technically you don't need the *whole* tree, but it's easier on me if you just build it all; that way I don't have to list off all the targets you'd need to specify :-). For those who are unsure of how to do this, get a copy of cvs, ssh, and jam off the DevCentral page, do an anonymous checkout of our CVS repository (see Daniel's CVS article if you need help), run ./configure from the current/ directory, run jam from the current/ directory, and go watch The Godfather (possibly all three of them) while everything builds.

Once that's done, head over to the current/tests/ directory. There you should find a shiny new unit testing app appropriately named UnitTester. Running UnitTester with no arguments will run all of the available tests against our OpenBeOS implementations. Running 'UnitTester -r5' will run all the unit tests against Be's R5 implementations (for the sake of reference). Running 'UnitTester --list' will list off all the available suites and tests. You can then run specific tests or suites of tests by passing their names as arguments to UnitTester. And finally, 'UnitTester --help' will list off all the available options, since I'm not going to cover any more of them here.

Currently, the Storage, Support, and App Kit tests have been integrated into the testing framework (note that many other kits have separate tests that you may want to investigate as well; dig around in the /current/test/ directory to see what's there).

If you have any problems or questions, let me know.

Part II - Writing Tests

Now, for those of you developers out there that would like to add new tests to or integrate old tests into the framework, this section is for you.

First off, there's an example suite in current/src/tests/ that's meant to be a simple reference point for figuring out what you need to do. Single- and multi-threaded tests are both demonstrated. You might also take a look at the Storage, Support, or App Kit tests for help.

Second off, all the headers for the CppUnit classes you'll need are in current/headers/tools/cppunit (BeOS specific classes) and current/headers/tools/cppunit/cppunit (stock CppUnit classes). Remember to always include stock CppUnit headers with the cppunit/ directory prefix, i.e, if for some reason you want access to CppUnit::TestCase but not BTestCase, use:

 
#include   

Now, adding your tests to the framework involves two easy steps :-)

1. Add a suite for your kit (or other major chunk of code, if you aren't technically a kit) if you don't already have one. This is done by creating an add-on that returns a BTestSuite containing all of your tests. You'll want to use the CommonTestLib rule in your Jamfile (see the current/Jamrules for lots of helpful instructions on using various rules) to compile and link everything together.

Headers of interest: TestSuiteAddon.h, TestSuite.h

2. Create a BTestCase subclass (single-threaded) or one or more BThreadedTestCase subclasses (multi-threaded) that implement your tests, and add your tests to your suite with a

CppUnit::TestCaller

BThreadedTestCaller

 
Headers of interest: TestCase.h, ThreadedTestCase.h,  
cppunit/TestCaller.h, ThreadedTestCaller.h 

Guest Editorial by Simon Gauvin, President, beunited.org

BeOS is a marvel of software engineering and creativity. We all know it, use it, and love it. We are also re-creating it for the pure fact that we want to see it continue and thrive. But before it can be successful three things need to happen:

1) It needs to work.

Well the first item is simple, that's what all the great people at OpenBeOS are doing - making it work. It needs to work as well, or better than R5, and I'm totally confident that will happen. The progress is amazing, in the year since the project started there are major parts of the OS that have complete replacements. The kernel is running, and Michael and his team are already reporting performance many times that of the present kernel. Networking is also reported to be a screamer, and select() is fixed making this version a real winner for porting UNIX apps. As well, mmap() is fixed and we can now get on with porting WINE. It's amazing, all the nasty little things that prevented R5 from progressing and providing a complete solution are all going away and our dream OS is around the corner!

2) People need to know about it.

Marketing! Marketing! Marketing!

Probably the biggest obstacle BeOS had to success, next to no longer being worked on, is that nobody knows about it. Worse, even less people know about the open source initiatives going on, like OpenBeOS, to re-create it. Marketing is the key. Creating awareness about the product and delivering a story about why people want it, even if they don't in some cases. We need to make people "feel" like they want this! Ever listen to Steve Jobs talk about Mac's? Ten minutes with him and you want to sell your house to get one! It's contagious!

Publicity is important, as it exposes people to the knowledge that a product exists. This can be done through various mediums, TV, newspaper, magazines, radio, Internet news sites, etc. These are what I call 'top-down' marketing channels since they are like going to a high point and shouting your message across the valley hoping that it hits someone. These marketing channels are proven to work. The problem with them is that they are also tremendously expensive. Certainly out of range for an organization trying to make open source operating system standards with no money. No, this is marketing for companies, ones that have millions of dollars like Sun Microsystems. So how does a small organization get access to such marketing? Well, in the words of Newton, "I was able to see further because I stood on the shoulders of giants." Maybe if we ported Java to BeOS... hmm, then just maybe Sun would help us with some marketing....

So top-down marketing is possible, if not inevitable for BeOS. What about other forms of marketing? How about bottom-up? This is where the message travels from the bottom, the users, to other users, without the need for the traditional channels. That's what is generally known as 'word-of-mouth'. This also is a proven method for publicity. It has many advantages to top-down since the person you are hearing the news from is generally someone you trust, unlike the talking head in the TV. In the bottom-up approach people are the key, which means everyone in the BeOS community has the responsibility to tell everyone they know about BeOS. Great business models have been created around this principle, where telling, or selling, the idea/product to someone brings each person a little income. Ever heard of Amway? It works. Be, Inc. originally tried this approach to marketing through the use of developer conferences and BeOS User Groups (BUGs), but the focus shift towards BeIA also shifted focus away from user groups to corporate entities, thus pulling all the fuel from the fire.

3) It must be a solution to a problem.

As a recent friend told me the other day "BeOS has to be a part of a solution. It is not a solution by itself." 80% of all new products introduced each year will fail. Why? Because marketing was not done. Marketing is not only about publicity, it's also about knowing your market, go figure... Marketing tries to answer questions like:

• Who is the target user of the product?
• What is the potential market size?
• How much will it cost to built it?
• Who can afford it, and how much will they pay?
• How are they going to use it?

Even if the product if free, as in no monetary cost, it is still not a reason enough to have someone want it. In fact nothing is for 0$ since the time you take to learn the product is actually a cost, and as they say, 'time is money.' What is free is only the ability to see and change the source, so this is not a monetary freedom, it's just the freedom to do it.

So why does a product succeed? Because it is a solution to a problem. It has worth beyond it's dollar cost to someone in that they can use it to do something faster, easier, make money with it, lower costs they currently have, or just plain do something they could not with any other solution. So where is this opportunity for BeOS then? I'm glad you asked...

The opportunity before us:

There is a tremendous opportunity before us with the development and release of OpenBeOS. This opportunity is based on three simple facts that have given us the present state of the desktop OS market today. These facts are:

1. Open source UNIX clones (Linux) make a poor desktop OS for the average user.

The clones currently have a 0.1% share of the desktop market. Developers are trying desperately to make these clones easy to use based on X (KDE, Gnome) but have not succeeded in providing the level of simplicity required by today's average user. The main reason is that Linux does not solve a problem on the desktop that is more compelling than the cost of Windows. It does solve a problem on the server, which is why it's successful there, but that's a different story.

2. Mac OSX not to be released on x86 hardware any time soon.

Microsoft would not stand still if Apple were to challenge Windows with OSX on x86 since OSX would then compete directly with Windows. Microsoft would most likely stop development of Internet Explorer and Office for OSX, which they have recently threatened due to lack of OSX software sales. This would be a fatal blow to Apple and its plans to increase its desktop market share. Only when Apple is sufficiently separate from its dependency on MS products could this happen, which does not look like any time soon.

3. A vast majority of Windows users would not remain with Windows if they had another reasonable choice.

As a result of item 1 and 2 above Windows is currently the ONLY choice of desktop operating system for 99.9% of the x86 users. It does not take a genius to estimate that some percentage of these users would like to use an operating system that is simpler, more stable, faster, and cheaper than Windows to run on their x86 based applications. After all, why would MS still be developing and trying to improve Windows and contunue to charge for updates?

When you add these three facts together you come to the conclusion that there is a huge need waiting to be filled because:

     There is no choice for another OS on x86 for 99.9% of users!

Therefore, if OpenBeOS = Mac + UNIX + Performance + x86 + open source + 0$ then,

     OpenBeOS has the opportunity to fill this HUGE untapped market!!!

When you take into account the millions of computer users yet to use computers in Asia you can see that there is tremendous potential for OpenBeOS. So here we are, at the enviable position of being at the begining of a new era in desktop computing, creating a version of an operating system that has the potential to change the world.

So where does beunited.org fit into this?

First off - Read my lips "BEUNITED IS NOT A COMPANY." I hope everyone understands this. We are a NON-PROFIT ORGANIZATION. We plan to distribute OpenBeOS for free to anyone who wants it, we will never sell OpenBeOS. Here at beunited.org we are driven to promote and develop markets that will make OpenBeOS work. We are doing that by:

• Establishing appropriate relationships with other agencies and bodies with the purpose of ratifying OpenBeOS specifications as international standards.
• Educating the consumer and business communities about the value and benefits of the OpenBeOS platform, products and services through publicity, publications, trade shows, seminars, conferences and other programs.
• Maintaining relationships and affiliations with educational institutions, governments, research institutes, technology companies, and other organizations that support and contribute to the development of OpenBeOS specifications.
• Fostering the competition of new products, services and distributions based on the specifications developed by the community in conformance with all applicable standards tests.
• Representing the community for the purpose of creating relationships with Original Equipment Manufacturers (OEM) that will allow the restricted sharing of technical information with developers seeking to further the development of all Open Source BeOS platforms, products and services.

beunited.org has already spent thousands of dollars on a trial brief to help educate the US courts on options it has to punish Microsoft for it's established illegal activity of monopolizing the OS market. This was critical because without this knowledge the courts could not have made decisions to help alternative OSs like OBOS. What the trial brief has accomplished is to not only educate the US courts of the issues, but also made OpenBeOS an issue to an entire 'elite' group of rich and powerful individuals who would never have heard of OpenBeOS otherwise. This is publicity that would have cost millions to have the same visibility and effect. As a result, many of these same important people are now watching OpenBeOS, waiting, calculating, and planning for opportunities to invest time and money into this amazing venture.

We recently received a donation of code that read something to the effect of "here you are, just don't put it under GPL". Other people within the BeOS community insist that GPL is the only way to go, that we are absolutely dead wrong for not choosing it, and so on. I want to talk a little bit about GPL, why we didn't choose it and how that impacts developers, users, and what the business world calls VARS - value added resellers - people who will make OBOS distros.

In case you have been living under a large mossy stone, the GPL (Gnu Public License) is a license for "free" software. The long and short of the license is this - you may use this software as you choose, so long as you make public the source code for anything that you give to someone else. So I could take a piece of code under GPL and sell it. Even if I didn't write it. Much like what RedHat and others do, although to be fair, they do "give back".

The license that we chose for OBOS was the MIT license. Which says, in essence, that you may use this software as you choose. Period. No requirement to give away the source code. That is the key difference. That means that someone could come along and change OBOS to be radically different (say, embedding it into a multi-media microwave or something) and sell it without giving away the source. Or someone who wants to build a killer media app could take the OBOS source, super optimize some drivers or some part of the Media Kit and sell the bundle as an integrated package without distributing the source.

Both of these approaches have good and bad sides. The good side of the GNU license is that it forces such modifications to be made public. That means that everyone gets better software, since the people who maintain the GNU software has the option of rolling the changes into the baseline of the code. The good side of the MIT license is that commercial developers can develop without releasing their intellectual property. If they put $500,000 into making a piece of code better, they do not have to give that code away. Companies very much like this approach, for obvious reasons - they can use copyright law to force you to pay them for their work.

The bad side of the MIT approach is that someone can come along and change your code and keep it for themselves. There is no promise that the code will be made better. Better code can exist and you may never see it unless you pay for it.

The bad side of the GPL approach is two fold. The first issue is that many companies will shy away from it. They see their development dollars as a competitive advantage that they do not want to give away. The second issue is what is commonly known as the "viral" aspect of the GPL. In fairness, this "viralness" applies to every piece of code out there that has any restrictions on what is done with it. That is to say that if a portion of the code for a particular program is licensed under a particular license, the application must be licensed with a compatible license, or the code user is in violation of the license. Huh? Simply this - the license of the whole must be compatible with the license of the parts. If a portion of the code is under the GPL, then the application must be compatible with the GPL, or you have violated the license under which you found and used the code.

The GNU folks have an interesting take on this (taken from GNU.org):

     If we amass a collection of powerful GPL-covered libraries that have no parallel available to proprietary software, they will provide a range of useful modules to serve as building blocks in new free programs. This will be a significant advantage for further free software development, and some projects will decide to make software free in order to use these libraries. University projects can easily be influenced; nowadays, as companies begin to consider making software free, even some commercial projects can be influenced in this way.

[snip]

   But we should not listen to these temptations, because we can achieve much more if we stand together. We free software developers should support one another. By releasing libraries that are limited to free software only, we can help each other's free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition.

I believe that this quote makes the whole GPL vs non-GPL issue quite clear. The intention of the GNU project and the GPL is to cause more open source software to be written. And this is a fine goal.

It just doesn't happen to be our goal. OBOS is not a project to encourage free software. I think free software is a fine thing. But getting free software (other than OBOS) written is not our goal. Our goal is to continue on with the BeOS. One might argue that by *not* choosing GPL, we are limiting the base of code that we can use to put together OBOS - we can't reuse Linux code, for example. This is completely true. On the other hand, we are making our code more "corporate friendly". More companies can use our code without violating their business practices. Without changing their business plan. And that removes one more barrier from companies who are interested in BeOS. That is our goal. More users and more companies interested in OBOS. >