Username or EmailPassword
I was heavily involved in GEOS development around '96-'02. When I stopped working on it, I was one of the last people hanging on to it. The story told in this article is no different than the story told back in '02, and is why I stopped working on it.
On the GUI vs OS issue - GEOS uses DOS calls to read and write the filesystem. This is done for compatibility - it made it much easier for the software to coexist with DOS and Windows installs. There is a proper filesystem driver interface in place and it shouldn't be hard for someone to write a driver that replaces the DOS system calls with direct disk access. It's never been done because there's no benefit to doing it. Most distributions of GEOS were actually used in embedded systems and shipped with an embedded DOS distribution tailored for it, so you're really grasping at straws to say it's not an operating system.
When looking at the overall picture, there's one key point to remember in all of this. The entire operating system and all of the original applications are written in 16 bit assembly. The vast majority is 8086 compatible. Some of the newer code requires a 286 processor. The only 32 bit code in the entire system is a few memory copy loops in kernel's memory management system - and that's only a build option, not a requirement. So to do any serious work on modernizing the system, you'd have to rewrite the code in a higher level language and completely rework the kernel.
The "we'll build it when they come" attitude is a practical issue. You're talking about an investment of millions of dollars to modernize the core system, and probably tens of millions to modernize the applications. Those are likely low estimates. Those kind of projects don't happen on the chance that someone will want it when you're done.
When it comes to open sourcing the code, there are significant legal issues preventing that. Some are simple - removing some licensed data compression code from the help viewer or removing the spell check engine. Some are hard, like stripping out the font system. Others are a complete nightmare, such as the user interface situation. All the different UIs GEOS supported were built from one shared codebase with build flags to handle the differences. The problem is there's a lot of companies with rights in the process, and it's all intertwined. The core of the UI is the most complicated part of the GEOS code, and you'd need someone intimately familiar with it to sort through the mess. There's not many people that can do it, and of those people, you'd probably have to pay them very well to convince them to sort through a giant 20 year old assembly codebase.
Regarding 3rd party development - the big issue was always memory management. The OS did preemptive multitasking, and every application was multithreaded by default. To make that work with a 640 KB heap meant very complicated memory management, which scared away most people. You'd need a full 32 bit - or really 64 bit at this point - rewrite of the core system to get anyone to consider development.