Making a reliable OS from the ground up takes a lot of work from a lot of really skilled people. I don't think people give ReactOS enough credit.
It seems a lot of people look at the success of Linux and *BSD and assume that it's easy once people put their heads together, but what they're missing is:
A. Way more people had direct experience with Unix kernels by the early 1990s due to things like source available licensing and Lions' annotated Unix V6 source code being used as a university textbook since the late 70s. In the case of BSD, the code was mostly written already, they just had to get through the AT&T lawsuit and then remove the 6ish files that were deemed to be AT&T's IP.
B. Specifically for Linux, the project got a lot of financial and manpower support from big established companies like IBM and Oracle once it became clear that Linux could be a commercial Unix killer.
ReactOS doesn't get any of this. While there have been source code leaks, Microsoft remains very secretive about NT's internals and protective of its source code. Unlike with Unix, there's no NT-family of operating systems for people to draw knowledge from. There's NT and there's OpenVMS as a sort of distant cousin, neither of which are open source.
For what it's worth, I do think that ReactOS's goals are orthogonal to what people really want, which is the ability to run Windows software without needing to deal with Microsoft. You really don't need the NT kernel in order to do that, you just need a robust userland compatibility layer. I think this is why Wine has been so much more successful (especially now with Proton and SteamOS) than ReactOS.
I still dream to one day have an OSS Windows replacement that's like a Windows 7/XP/2000 desktop but with modern kernel features, APIs, and security patches. But I think the more likely future is compatibility layers for gamers and the continuing death of desktop computers for anyone who isn't an enterprise or enthusiast.
We're so far behind from having alternative OSes that are able to run software that's based on Win APIs that any compromise seems reasonable. Essentially, all we have at present is monopolistic, spying, ad-dropping Microsoft or nothing, so any alternative has to be better.
Linux with Wine is fine in its own right and I use the combination but it isn't a true substitute for the ordinary user who has been used to using Windows for decades. Witness the pitifully small numbers of Linux desktop installations compared with Windows and the even smaller number of Linux users who use Wine. (Yes, I know Linux's desktop share has increase recently, and that's a good thing, but the numbers are still trivial.)
Seems to me pragmatism has to reign in the way that many users install Nvidia drivers on Linux. Granted, it's not the ideal for open source but the compromise is better than the alternatives.
What would a NT-compatable kernel get you that wine doesn't already have, other than the drivers? And my point is that having that is cool, but the drivers aren't open source so a lot of potential volunteers won't care anyways because of that.
Because OSS is a thankless job and _free volunteer_ work. The more niche something is such as Windows kernel clone development, the ridiculously smaller pool of potential contributors that may even want to contribute _their personal free time_ to spend on it.
And I come from the perspective of other large niche OSS projects.
"Because OSS is a thankless job and _free volunteer_ work. "
Agreed, it's why I've advocated a halfway 'house' to overcome the problem and pay for the project's development.
It goes something like this (but no doubt there are many suitable variations): create a nonprofit cooperative organization/society that is revenue neutral to develop programs and pay developers a reasonable wage. Employment could be flexible, the organization could employ both full-time and part-time developers (this would help those who've a keen interest in the project but whose principal job is too valuable to let go etc.)
In effect, this software has a cost but it would be very much cheaper than products from Microsoft, Adobe, etc. Also, licensing would be less restrictive—say make the product still cheaper or even free if one compiles the code oneself. There are ways of releasing the code so someone doesn't release a compiled version (each source could be different, have individual certificates, etc., thus compiled versions would individually identifiable), but I'd reckon the price would be so reasonable that it wouldn't be worth the effort.
By revenue-neutral I mean the price of the product would not only cover wages, administration but also necessary reserves. I've mentioned this concept on HN and elsewhere previously for software such a Gimp, LibreOffice and so on.
I'm somewhat surprised there aren't any software organizations that use this development model.
Because a lot of niche OSS has very little commercial value to even try and be revenue neutral.
Even take ReactOS, why in the world would a org use it when you could just license Windows properly with PCs pre built and have the accountants depreciate them into taxes as they are capital equipment.
If someone needs an old Windows kernel for compat, they'll just keep using that old Windows version they have on a box and not waste engineering labor to migrate it.
Combining a bunch of projects like that under a halfway house increases revenue but does not mean it will be revenue neutral. It'll still be in the red.
End of the day, there are reasons why some OSS stays completely free while others have commerical and free operations ran in parallel. Either it can bring in money or it can't.