OSNews

Now consider the disadvantages of binary compatibility:

- The BeOS APIs are showing their age. There are design flaws, naming inconsistencies, outdated implementations, etc. For example, pointers are commonly used where references would be better. You SetEnabled() but you MakeFocus(). BFont does not derive from BArchivable. BWindow and BApplication both have pulse functionality, so why isn't it in their common base class, BLooper? And what exactly does BView::SetDiskMode() do? (Hint: it's not in the Be Book) The freedom to make these changes while retaining 99% source compatibility is well worth it, not to mention not having to deal with maintaining virtual function ordering, padding to maintain object size, etc. There are also BeOS classes which do not have enough reserved space for fragile base class protection - this is a good chance to fix them.
- Binary compatibility ties you to gcc 2.9.x, since the 3.x series tool chain broke compatibility for C++. So first of all, you're stuck with a compiler that will not evolve or get bug fixes. It will not generate optimizations for the Pentium 4 or future CPUs. But worse than that, it's buggy. As I recall, turning on -march=pentiumpro will generate wrong floating point code in some cases. Using -O3 often produces slower code than -O2. And the STL implementation is horrible. Bitset is broken. Using += on a string trashes memory. Calling operator== to compare a string to "" returns the wrong result. OpenBeOS proposes to use STLport instead, but I don't see how this can be done and maintain binary compatibility. The inline nature of STL means that all the header code of the R5 STL has been compiled into existing applications, yet still depends on libstdc++.r4.so. So you can't change the contents of this library, and you can't remove the old STL code from the apps out there. Would you simply ship this library in binary form only, then have a new name for the STLport lib? If someone knows a way to make this work, I'd be interested.
- How will you achieve binary compatibility with Be Inc. apps that use unpublished APIs? Perhaps you can reverse engineer the magic flag which Workspaces passes to the app_server in its constructor (the entire contents are drawn by the server into an empty view). But what about kernel support for bdb? What about DriveSetup? What about the dozens of private header files that were in the BeOS source tree which could be used anywhere? As a data point, consider that the OpenBeOS team tried to reverse engineer the protocol between the app_server and input_server, and gave up. All of the extra effort it takes to remain binary compatible will be wasted when the important apps fail to run.
- Conversely, many of the Be Inc. apps that would run aren't worth it. Take some of the preferences apps for example: Fonts, Menu, Mouse, etc. First, they're all out of date. Second, they either save their settings in obscure ways that would be inconvenient to use, or they interact in private ways with the system and aren't usable (how does the Network panel restart the net_server?). Very few of them would be hard to rewrite. Plus apps like BeMail, CodyCam, Pulse, and Magnify are already open source, and of course Tracker and Deskbar. The only significant app that came with R5 that I would miss is BeIDE, which I admit I like alot.

I believe that in order to attract quality developers and to get them to build large, full-featured applications, you must provide modern development tools and a well-documented, clean API. Being permanently stuck in 1999 does not get you there.

4. I think source management and licensing are important. I think any project would greatly benefit from using Perforce, which is free for open source projects. (I don't know anyone who switched from cvs and wants to go back). But whichever source management tool you choose, the source needs to be available to the public. Not necessarily with write permissions, mind you, but at least in read-only form. I won't pretend to have the experience managing large projects to tell you how this should be done. But I feel that letting anyone check code in on one extreme is just as bad as not showing the code to anyone outside your group on the other extreme. The most successful projects out there (Apache, the Linux kernel, etc.) seem to have a model where contributions are encouraged, but checkins are closely scrutinized for quality.

Licensing seems to have divided the largest two projects, OpenBeOS and BlueEyedOS. I'm happy to see that both reject the GPL as an option, due to its viral qualities and the fact that it discourages commercial development and contributions. OpenBeOS has in a noble gesture gone with MIT, also known as the "truly free" license. I admire this, and have no problem with it personally, but as Michael Phipps points out, it provides no protection for the authors in the form of requiring changes to be submitted. BlueEyedOS has adopted an as-yet-unnamed license due to concerns about code forking and commercialism. Again, I understand and can sympathize, but I think the fact that the code isn't available to the public feels closed to many people. What I haven't heard is a strong objection to the LGPL license from either side, or for that matter the Mozilla license. Both reject the viral aspect of GPL, and while LGPL requires all changes to be submitted, Mozilla only requires changes to existing files to be released, thus allowing proprietary extensions. Perhaps the two sides could consider one of these as a middle ground, where the source is available but also well managed.

As for code forking, I don't know if it is absolutely preventable if you wish to be open source. However, many successful projects out there don't suffer this problem. Perhaps the best defense against it is to keep the project active and open to input, so that it neither stagnates nor causes excess disagreement (obviously you can't please everyone all the time). It's also possible that a project of a certain size and complexity becomes pointless to fork, since it's just too hard to take it in another direction without a large team. Given the dwindling number of BeOS enthusiasts out there, this may not come up.

5. I understand that the number of people who have joined these projects and the work they've done already is cause for optimism. But I prefer to be more realistic about how hard this task is. Take the app_server, for example. I worked at Be, and I've seen the code, but I am not remotely qualified to rewrite it. I would guess that maybe ten Be employees are. Yes, it's that hard. My advice, and I don't like to say it, is to consider not supporting certain features of both the app_server and BeOS in general, at least in the first version. For example, BWindowScreen and BDirectWindow probably don't make sense. Maybe drop 15 and 16 bit graphics mode support (code size can be seen as colorspaces ^ 2, since a bitmap in one colorspace must be able to draw into a bitmap of any other colorspace). I agree, it's a compromise, but v1.0 will always be just over the horizon if it must contain everything. As interest in BeOS and the community both shrink, time to release becomes more and more important (many people think it is already too late).

CONCLUSION

Writing a BeOS replacement is a huge task. But it's only worth doing if you plan a strategy that gets you to your goals. If you make the same mistakes as Be Inc. then you've just wasted several years of effort. There needs to be one united project that developers and users can get behind. Hardware support is critical to making the platform succeed, and that means leveraging all the work that has gone into Linux. Binary compatibility sounds tempting but ultimately has too many downsides. The source code needs to be available but well maintained. And lastly, some pieces may need to get left out in order to succeed.

In closing, let me put my money where my mouth is. If we as a community can work these issues out, I will donate the source of GIFTranslator and ImageViewer to the new OS. I will also recompile Anime and my other apps for the new platform, and encourage other developers to do the same. For those unwilling to open source their work or recompile, we could set up a service to rebuild their apps and make binary-only releases, guaranteeing the privacy of their source code.

I'm eager to hear your thoughts. If you don't want to comment below, you can write privately at software@switkin.com.

1. "Part I"
2. "Part II"