The homepage says it caters to assembly developers particularly. Its GUI can be controlled using ASM. This can be a nice tryout for those interested in hacking. Ttruly, hacker News stuff. :)
Looking at the screenshots, this appears to go pretty far beyond the original Mac System software. I mean, it's a full OS with file management, pre-emptive multitasking, networking, Web browser, FTP client, USB with device drivers, multimedia playback and a full GUI with transparency and perspective transforms. The Macintosh had — well, it had primitive file management, at least.
Most of that stuff has to do with improvements in the hardware. The original Macintosh's GUI was somewhat limited by the hardware.
CPU: Remember Cringely's story of how before Apple fired him, the last thing he did was to implement an animation of flies buzzing around the trashcan to indicate that it was full, which took 30% of the CPU. And it's a lot easier to do transparency and perspective transforms if you have a GPU to run them on.
Pre-emptive multitasking: pre-emptive multitasking takes up very little code (you just need an interrupt handler that saves one set of registers and restores another set) but it's more error-prone to program on than cooperative multitasking. Its usefulness is that no task can hang the whole computer. But on a machine without an MMU, like the original Mac, any task programmed in an unsafe language can crash the whole computer, so that's worthless. Even preemptive-multitasking OSes that use the MMU effectively (with locks, facilities for limited shared memory, message queues, and so on) can be quite small.
Oberon was a system more or less contemporary with the Mac with hierarchical file management, networking, hypertext, networked file transfer, and a GUI (although obviously not an FTP client, a Web browser, or transparency and perspective transforms) that was similar in size.
So why are our other systems so much more code? Here are some of my guesses.
• You can always do something better (faster, in a more general way, with better error reporting, covering that last little detail of the CSS standard, whatever) in 10× the code. So people do.
• In big and old systems, in order to keep communication overhead to a manageable level, people duplicate code — either because they don't know it already exists, or because they don't understand the code that depends on it well enough not to break it when they change what it depends on, or just because changing the interface is so much work. (In theory, you could migrate all Motif applications to use GTK, with enough work on them.) I'm not saying this is justifiable in systems of merely a few million lines of code, but in systems like Debian, up in the billions of lines, it's unavoidable.
• Big and old systems also have lots of code of minimal utility. Do you know about Xdmcp? Your X server does. How about X resource parsing? Lots of your programs are still linked with Xt. How about the xbm file format, to say nothing of three quarters of the formats supported by netpbm and ImageMagick? Handling for printing teletypes that can't erase? Handling of terminals with no lowercase? Hardware-accelerated non-antialiased rendering of polygons? Video cards that have separate palettes for the red, green, and blue color channels ("DirectColor")? Xcms? Have you ever looked at the random crap in terminfo? Did you know that Microsoft Windows machines still have fields in struct sockaddr_in for IMP numbers, in case you're on the ARPANet? And when was the last time you needed magnetic tape handling programs? Did you know Emacs still comes with notes on how to port Mocklisp to it?
As I understand it the developer got annoyed with other developers polluting his 32 bit ASM codebase with impure C and decided to focus on a 64 bit version with a more restrictive license. Shame.
He could simply deny their contributions, and make them fork it... The license has little to do with who's managing the project and the decisions they make.
