I was immersed in the BeOS community for a few years, writing various little apps to put on BeWare and then later BeBits. Besides the obvious market and competi

I was immersed in the BeOS community for a few years, writing various little apps to put on BeWare and then later BeBits. Besides the obvious market and competition reasons: - BeOS wasn't really that good. A lot of the hype was aspirational. Yeah, great, media OS! But I still have to use some SDL-based app from the command line to get MPEG videos to play with audio actually in sync. I have to restart media_server every few hours because my audio driver is buggy. Their approach to networking was ill-considered (not compatible with POSIX sockets) and they had to rip it all out and replace it for Dano, the last major version in development that was never released. All this stuff was stable in Windows of the era. - The choice of C++ for all APIs caused them to start seriously hitting the fragile base class problem: https://en.wikipedia.org/wiki/Fragile_base_class https://en.wikipedia.org/wiki/Fragile_base_class . At the end of Be's life, "libfoo2" libraries started popping up as they had to break ABI compatibility in order to modify a base class. They thought C++ was a forward-looking choice but in hindsight it was a poor choice. NeXT didn't have these issues with Objective-C. - The Application Kit sucked. It was, essentially, just the Win32 API model. Your window has a message pump and you decode messages in your MessageReceived function. It learned nothing from other UI toolkits and it contributed nothing. Just kinda meh. Even at the time I reached for a third party UI library (liblayout). There was nothing special or good about BeOS's UI toolkit at all. - BeIA was a terrible pivot. I'm not sure we could have expected them to see it coming, but they were dead as soon as they pivoted. I remember getting access to some kind of BeIA beta and it was just a crappy port of Opera, which actually was still the best web browser available on BeOS at the time.