This is one instance where that approach probably pays dividends, if they can pull it off. Most macOS-like clones that I've tried fall short, due to there being only so much you can do to paper-over the Linux desktop experience. A sort of uncanny valley that I just can't get over and adjust to using.

To have the full experience they also need to clone the Objective-C and Swift frameworks, and IDE tooling.

The GNUStep project has already done much of the ObjC framework cloning. I wonder if they're using that. Not sure about Swift frameworks, though.

They mention in the faq that they do not use GNUStep's implementation of the frameworks, but they do use GNUStep's implementation of the libobjc2 runtime. There's licensing and goal issues. Apparently their Cocoa implementation comes from "the same source" as Darling's, but I don't know what that means. (Cross referencing with Darling's faq, I guess it's The Cocotron.)

GNUStep is GPL though, and one of the stated goals of ravynOS is to be BSD and MIT licensed. On the FAQ page they address this, even saying they might be willing to use it despite the licensing.

If what you understand by macOS is how Panther used to be.

> If what you understand by macOS is how Panther used to be.

That's a bit old for me (I started with Tiger), but I would definitely be all over an option to go back to OS X (where, I felt, the paradigm was that users should be presented with the best possible default experience, but also should be trusted to tinker if they chose to do so) before they started pushing this macOS = iOS integration (where the paradigm should be that users should be protected, even against themselves, from any need or ability to tinker).

That is mostly what GNUStep managed to be compatible with before running out of steam.

It's hundreds of person-years of work so no, they can't pull it off.

See also Linux, and Firefox, neither of which got pulled off.

Snark aside, sure, it starts small. But it's so much easier to pitch in if there's some code base to work with. It snowballs.

> Oh, the good old "rewrite the world" approach. Good luck to the developers!

Yes, they definitely need some good luck, but sometimes rewriting the world is necessary to one day invent something new, or just eliminate architectural issues that are too entrenched in the old code to be easily circumvented without adding bloat and/or bugs. The price to pay is lagging behind the competition, with a potential bigger payoff only later, for those who persist. I see roughly a similar approach with the PinePhone: they probably went like "the heck with reverse engineering other phones, we make our own one from scratch!"; the result as of today is a ~90% working slow phone that very few among non tech users would want, but we see the much bigger potential if and when they'll reach hardware performance at least comparable to known brands. It takes courage, perseverance, and luck.

I will never understand the people think you can never do a fresh start (in software, but not limited to it). Many very successful projects started as a green field. Sometimes I would even go so far as saying they would have failed if the had tried to build onto the existing code base. Also important to note: there is no "start from 0" most likely the work will be based on existing work, the ideas, code, or parts, modules, graphics can be reused. I see everyday in my job how this kind of thinking leads to code with parts that are over 20 years old, and are not changed because of fear that something could break.

“Write one to throw away” was a concept in one of the tech books I read. Perhaps The Pragmatic Programmer or maybe The Mythical Man Month.

If your goal is to replicate the UI quality of MacOS, then just reskinning the work of others will only result in inconsistent jank.

Sure, a certain amount of good luck is always required.

I've been involved in two rewrites during the past 5 years. While the rewrites were not by choice (one was forced by Flash EOL), in both cases there were multiple, very obvious (after the fact) benefits:

- Better, modern technology top to bottom

- Better dev process, facilitated by the better technology

- An excuse to focus functionally, and rethink. We couldn't possibly reproduce a heap of legacy features and were forced to focus on what mattered, and managed to offer those key features in a far superior way.

Done right, a rewrite can be fantastic. And sure, rewrites often happen for the wrong reasons and at the wrong time.