Hacker News Reader

> I've never figured out why the inordinate delay given that millions are unhappy with Windows and Microsoft generally. You'd reckon open source developers would be falling over themselves to join such a project but it seems not.

I think there is a strong misconception that there is this massive pool of open-source devs twiddling there thumbs just itching to jump in on some project were they can pour time and effort for nothing more than the "good of the community". I don't have any sources for this, but it my strong suspicion that the vast majority of "open source" contributions are actually done by contributors that are compensated either by a company that doesn't mind paying their employees to work on open source projects, or by a foundation behind the open source project. Take Go-lang for example, originally created by Google, then opened up. I am sure there are Google employees that still contribute (on Googles dime) to the project. Why would Google do this? Why not keep the Go just for themselves? Simple, if they open it up and can get other people/companies to use it, then they can make future hires where they don't have to train everyone on a proprietary language.

ReactOS doesn't have a large foundation behind it, and it doesn't make sense for companies to allow their employees to develop and contribute to it on their dime.

Development is skilled labor, especially for an OS. Dev's need to eat, need a home, etc. I don't know a single dev that is itching to give away their skills for 0 compensation. The only time devs really do that is when it is a personal passion project.

> I think there is a strong misconception that there is this massive pool of open-source devs twiddling there thumbs just itching to jump in on some project were they can pour time and effort for nothing more than the "good of the community". I don't have any sources for this, but it my strong suspicion that the vast majority of "open source" contributions are actually done by contributors that are compensated either by a company that doesn't mind paying their employees to work on open source projects, or by a foundation behind the open source project.

I actually think this is a wider societal issue. People love calling for work to be done in some abstract sense ('someone should really...', 'they should make it so that..'), but who is this 'they'? Or this 'someone'? You? Because you're either volunteering yourself, or you're 'volunteering' someone else for the job, there's no third option.

There's this general sense that everything will be (or is) documented; every tool made, every itch scratched. But unless the incentives (money, fame, prestige, personal fulfilment, love, curiosity, self-expression, etc.) are there for someone to do it, it won't get done. Most things will never be done.

So if someone says "I don't understand why X hasn't been done", I feel like an appropriate response is to ask why they haven't done it. And generally, whatever reasons they give, those reasons will be a good explanation why anyone else hasn't done it either.

"I feel like an appropriate response is to ask why they haven't done it."

The average user can't program let alone build an operating system. The same way the average driver cannot build a car. Or smartphone users cannot build a smartphone.

Users have requirements of their tech and the more experienced they become the more they reqire of their tech. The trouble is that with the monopolies that run Big Tech their monopolistic practices give them little incentive to provide features that benefit users, instead the new features benefit them.

I could give you numerous examples of software that requires new features but no attempt has been made in decades to add them. Take Windows, whatever happened to the WinFS file system? It's sorely needed but MS and Big Tech generally want users to use Cloud storage and that benefits them, WinFS would help sidestep that. Windows and Windows Explorer need major extensions to the file attributes sysyem, Explorer needs major ergonomic enhancements to make file manipulation easier, and that's just for starters.

Without real competition none of this will occur, not even Linux and Apple can fix this because of their differences, they too are moribund in their own ecosystems for the sane reason.

Meanwhile, users like me have unfulfilled needs that are quite technically within the means of existing computers and well within the capabilities of tech companies to provide but these needs still remain unfulfilled after decades.

That we are nearly 80 years into the computer revolution and users still cannot perform simple basic tasks on a PC that have been straightforward commonplace operations in a paper-based filing system for hundreds of years just isn't good enough.

The fact is it's impractical for users of modern tech to start from scratch just because Big Tech doesn't fix bugs or add much-needed features. Unfortunately, attitudes like yours do not help.

Marx once said workers need command of production, these days I'd alter that to users need command of production so they can get the necessaries to do what they need to do.

>Marx once said...

Why anyone, reads, or cares at all about Marx, is beyond me. The guy was the biggest fucking loser bum to ever exist. He was constantly hitting up family for money, never had a real fucking job, was an absolute slob of a human being, treated is children like dog shit, and in general was too impressed by his own "intelligence".

>ReactOS doesn't have a large foundation behind it, and it doesn't make sense for companies to allow their employees to develop and contribute to it on their dime.

It's also a solution to a problem that largely doesn't exist. The people working on it do so for fun, not because they need Windows but not made by Microsoft. The parent comments says "having no alternative O/S to Windows is a real pain" but it's not a real pain to any significant amount of people.

> ReactOS must take the record for software with the longest gestation in history.

May I introduce you to GNU Hurd? First release happened 34 years ago.

https://www.gnu.org/software/hurd/

OK, thanks, I've learned something new, GNU Hurd has the edge over ReactOS by eight years. :-)

*Google*

https://en.wikipedia.org/wiki/Tandem_Computers: 1974 (50y) (semi-dead)

https://en.wikipedia.org/wiki/QNX: 1982 (42y)

https://en.wikipedia.org/wiki/VxWorks: 1987 (37y)

https://en.wikipedia.org/wiki/GNU_Hurd: 1990 (34y)

https://en.wikipedia.org/wiki/4690_Operating_System: 1993 (30y) (these run the self-service touchscreens at Costco's food section, IIUC)

It's surprisingly hard to query for "graph intersection between earliest first release date and most recent release date" :(

I think the parent’s point was that Hurd is still unfinished. All of the others in your list shipped releases that met their intended goals in a much more compact timeframe.

edit: clarification

"gestation period" != age

At least Hurd is making better progress than TempleOS these days.

I would say that TempleOS was complete considering Terry's goals.

To not get cease & desist'd to hell, great effort is spent to make sure every bit of code introduced to ReactOS has been properly clean-room engineered. The Windows source code leaks specifically have made a great job to stall ReactOS development. Also the potential legal issues and making an enemy of MS makes it hard to get sponsors. Hence project is entirely developed by unpaid volunteers.

"Windows source code leaks specifically have made a great job to stall ReactOS development."

What you are in effect saying is that Microsoft has essentially killed the ReactOS project off. Are you reasonably sure about this? The reason I ask is that I was under the impression that to overcome any MS code issues that ReactOS was porting Wine code (this ought to be clean).

A supplementary question, as ReactOS is using Wine code what parts still have to be coded that might be in conflict with MS's proprietary code? This question relates to my earlier point about how little info developers are providing potential users. The lack of info doesn't doesn't sound good nor does it offer users much hope.

I've been waiting about 20 of ReactOS's 26 years, unfortunately it seems to me I'll be dead before it's ready.

If I remember correctly, Hartmut Birr, a developer from early times had suspicions (at the time of v2.8/2.9) that a new and very productive developer had disassembled MS code. His code used the MS calling convention to the kernel, before that Reactos used interrupts to access the kernel.

The other developers disagreed and Hartmut Birr quit the project.

Right, I'd read something like that but without the specifics. If that's over-spooked developers then it's a shame. Microsoft has what it wanted—an almost halting of the project.

> Perhaps there's something about how the ReactOS project is run that I'm unaware of that puts people off.

My guess is that the intersection of people who don't need need bug for bug windows compat (so aren't are stuck on real Windows) and those who really care about the NT compatibility at the kernel level is about zero.

> having no alternative O/S to Windows is a real pain.

That really depends on what you count as an alternative, doesn't it? As far as regular applications are concerned Linux + Wine is a pretty good alternative.

I think the main issue is that there's just not much money in it.

Let me explain. I don't have hard numbers on this, but I'd venture to guess that a vast, vast majority of funding/code-time-donations towards Linux is specifically for making server infrastructure more stable. Fortunately for the community, these changes get pushed upstream and also fortunately a lot of them end up also benefiting the desktop environment as well.

Windows does have a server presence obviously, but I think if you're using a Windows server, you're not going to drop it and replace it with ReactOS (even if it were less unstable); you'd probably move to Linux with .NET Core. I don't think any company is going to fund the development of ReactOS on server, or as any key part of infrastructure, and so the only thing that React has is consumer desktops.

I don't think there's a lot of funding going towards consumer products; I'm not saying it's zero, but even for Ubuntu and Canonical or Fedora and Redhad, I always kind of figured that the desktop OS's were effectively loss-leaders for commercial clients. I think the final nail on the coffin is Valve and Proton; for awhile Microsoft still basically had a monopoly on games, regular Wine was hit or miss, but Proton keeps getting better and better, to a point where I almost never have to worry about a game not working on my Steam box. Valve can continue to work on SteamOS specifically because they have funding in the form of people using their platform to buy games.

I was rooting for ReactOS for quite awhile, but nowadays I'm not really seeing the point of it. Linux driver support is actually pretty decent nowadays (particularly with AMD GPUs), it runs reasonably fast, and most applications have moved to web-based stuff anyway.

It’s because all of the early React developers now have incredibly successful careers and don’t really have time to support it

As I said, why then aren't other/new developers rushing in to fill the void? Again, this is still a mystery.

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.

Add to that that finishing the remaining 90% of a project is a lot less exciting than designing the first 90% of a new one.

"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.

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.

I really like this answer.

It is cool that ReactOS can run windows drivers natively, though that seems to go against the values of open source

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.

Actual complete compatibility, which wine doesn't have.

> ReactOS must take the record for software with the longest gestation in history

I think that would be Project Xanadu, started in (depending upon what you consider as "starting") in 1961 or 1965.

You successfully answered why you would make a project that you haven't made, but that doesn't really answer the question, and the author already answered in the same subthread 30 minutes before your post.

Not answered to my satisfaction.

I'm pretty confident is that a core problem is that people who develop OS's realize that linux or unix-like systems are plain superior, and end up just building on that, being well versed in their structure and syntax.

This is great and all, except that the linux experience is about a 3/10 for people who are trying to leave windows. Especially when the core of using linux is still so incredibly CLI heavy.

It's kinda like having professional race car drivers build cars. They end up being fast, efficient, nimble, and easy to repair. But driving them is difficult as hell, the drivers seat looks like an apache helicopter cockpit and the clutch is so stiff and throttle so sensitive that you almost always stall or lunge. But it does have an automatic "beginner" mode, never leaves first gear and the throttle becomes slush, but it will get you from A to B around town, mostly. Great for grandma.