Ask HN: What could I build to make your life a little easier?
Ask HN: What is the state of support for mutable torrents?
Why Is ReactOS Development So Undervalued?
We’ve seen open-source implementations of nearly every major computing platform — from Unix to macOS, and even obscure or obsolete systems like AmigaOS, BeOS, and classic Mac OS. DOS has multiple open-source implementations (like FreeDOS), and even emulators like DOSBox are widely used and maintained.
Yet Windows — the most widely used desktop OS in history — has no complete, viable open-source alternative. ReactOS aims to fill that gap, but its development moves at a glacial pace, with only a handful of active contributors.
If we consider the sheer volume of software written for Windows, the cultural impact it’s had on computing, and its historical dominance, you’d expect ReactOS to have thousands of contributors. Instead, it struggles to maintain a small team of developers.
What explains this discrepancy?
Is it:
1. Technical Complexity
Windows NT's architecture is genuinely complex, with decades of accumulated compatibility layers, undocumented APIs, and proprietary driver models. But this doesn't fully explain it—other complex systems have been successfully cloned.
2. Legal Concerns
Implementing Windows compatibility requires reverse engineering proprietary APIs and behaviors. While this is generally legal, it creates uncertainty that might discourage contributors.
3. Moving Target
Windows continues to evolve rapidly. Unlike emulating a fixed historical system, ReactOS must chase a moving target while maintaining backward compatibility.
4. Alternative Solutions
Wine provides Windows application compatibility without requiring a full OS replacement. Linux offers a superior development environment for most programmers. The practical need may not justify the enormous effort.
Instead of replicating all known Windows 2003 internals in ReactOS, they should focus on components quality, possibly making some things different than in Windows or disabling some functionality that is proven to be unstable until proper implementation will be done.
Haiku for example had great project management at start, they split development into multiple teams that developed various OS components independently (kernel, GUI toolkit, GUI server, Media server etc.). Each component was initially made independently and tested on BeOS, instead of rushing to make whole OS right now, causing unmanageable amount of bugs. Haiku GUI libraries and servers were initially tested in BeOS before Haiku kernel was complete, creating BeOS window that emulates Haiku screen. Also unlike Windows/ReactOS BSOD, even now Haiku has proper informative kernel panic report screen with stack trace etc., that can be used to diagnose, report and fix bugs. ReactOS has classic Windows XP BSOD with single error message and obscure code, that almost useless for diagnosing bugs. It is quite stupid to not enable detailed kernel panic reports on alpha quality system, it makes much harder to fix bugs that users experience.
ReactOS still have no any journaling file system support or binary registry recovery. This often makes system unbootable after improper shutdown. Haiku implemented Be File System (BFS) from very beginning and it has journaling support. So system can easily survive kernel panics and improper shutdowns.
Linux: 1B EUR budget per year, both direct funding (corporate-sponsored work) and the value of unpaid contributions
Still there exists much Windows documentation and knowledge.