Hacker News Reader

Comment by SteveNuts | Hacker News Reader

My question then is why is windows not just open source entirely?

Be like Red Hat where the OS is open but you pay for support, I don't know why that model wouldn't work for MS.

One of the most challenging things Microsoft has faced when open-sourcing projects is the auditing stage. Windows is huge. Lots of code in Windows are not written by Microsoft or even by third-parties contracted by Microsoft. Some parts of Win32 code (that is backwards-compatible sensitive) are owned by third parties that are already long gone or absorbed by other third parties. This is the reason Microsoft cannot even release a binary version of Space Cadet Pinball even when they want to because it is now owned by EA (Surprise! Also see https://devblogs.microsoft.com/oldnewthing/20181221-00/?p=10...) and the same reason why they have removed the pre-2007 equation editor on their Office suite (https://support.microsoft.com/office/equation-editor-6eac7d7...). At one of its previous audits (for IE 7), they have to check if it was Spyglass code and replace the offending code which allows them to terminate their contract with (at the time) AOL.

Windows has many of these components, and they are even attributed when you know where to look. For example, the code for parts of the disk management utility, the spinning-disk defragmenter, and NTFS quota management were based from code provided by VERITAS Systems (which I am not even sure if the company still exists). The MP3 codec is provided by Fraunhofer (which still exists, but I'm sure that they will not agree to open-sourcing that codec). On the other hand, some of them are under permissive licenses or even the same code as other counterparts (while the BSD TCP/IP stack story ranges from code removed by Windows 2000 to simply an apocryphal tale) for example, the code by IJG for JPEG support is used extensively in Windows. The only built-in (L)GPL code used ever was the BRLTTY system (https://mielke.cc/brltty/index.html) and LibLouis (http://liblouis.org/), which was used for Braille accessibility (WSL2 used the Linux kernel, but they are arguably a different application with separate instances).

Edit: Microsoft's third-party disclosures: https://www.microsoft.com/en-us/legal/products/notices/win

Strong case against using proprietary software in your code base, isn't it. What a mess.

Using proprietary software in their code base, they made billions and dominated ther market, crushing all competitors. Right now they charge people for access to the code.

On the other hand, they can't freely release the code, something which is of little benefit to them anyway. How is that a "strong case" against?

Because the parent poster suggested they in fact wanted to open source more stuff but couldn't for these reasons. Therefore, it is a strong case against.

Sure, but at the time they were creating the mess they were actively opposed to open-source software.

Maybe we're using different definitions of "strong case", I'm imagining it in a court of law, a case for going one way is "billions of dollars and market dominance" - that's a strong case. The case for changing direction is "in 30 years, giving your stuff away will be less legal trouble". That's true, but it's not a strong case for changing direction, it's a minor shrug. Strong meaning enough to overturn the competing arguments and push a different decision, not just "isn't wrong".

only if you believe that future open sourcing of your code base would bring greater benefit than the proprietary software itself, which seems very unlikely.

I've gotten the impression Microsoft is taking a "open source new stuff" approach... After enough years and refactors and replacements, hopefully most of Windows will be open source. Things like the Windows Terminal project and Windows Calculator going open source seem to suggest this is the case.

But is there such third party owned code in the NT kernel? Open sourcing the kernel would bring the most benefit both for security and publicity.

OSSing a major decades old codebase is a huge undertaking and it's hard to see how it would drive additional Windows or even MSFT revenue at this point.

They do share source code if you're big enough that the revenue matters to them: https://www.microsoft.com/en-us/sharedsource/

You'd then have forks pretending to be "secure" wrt things like Protected-Video-Output-Path, widevine etc. Sort of like Magisk for Windows. Disney, Netflix and many others don't really like that.

And you'd have versions with configurable update servers. And LE probably really enjoys the fact, that they can ask "Hey, next time SubjectX downloads daily defender updates, please add-in the Remote-Adminstration-Toolkit" for any of a billion computers. I'm expecting MS to get a big list soon with maybe several dozen million new "people of interest" that need tracking.

Microsoft does do that already. They do both, so dropping the licensing revenue would strictly be a decrease in revenue.

Offering support contracts for open source code is an extremely difficult business model. It happens to be one of the few that actually can work, but the margins are just not great compared to the proprietary software industry. 90% of the kinds of customers who really "should" be paying you simply won't do so if they think they can scrape by without doing so.

Windows includes code from a lot of different companies and places. Sorting out all the licenses would be a major headache (especially as code is refactored/edited) let alone getting agreements from everyone for a new license.

Not taking sides here, but I don't get the comparison. RHEL is based on the oss Linux kernel, whereas microsoft is closed from the bottom up.

That being said Microsoft is slowly "getting" open source. We'll see how far their gut will let them take it.

Not OP (and not Microsoft), but I would say it's a complicated road to get there.

I do believe we will see open source Windows in... the next decade?

Anyone want to take a longbet with me? ;-)

I am willing to add to the pool, I am also betting core components of Windows will be open sourced soon.

I'm betting more on "replaced". E.g. When they switched to Webkit, they didn't opensource Trident. How many people would notice, if the next version of windows used CUPS running on the WSL2 backend with a nice small GUI in Windows-Land? The very informative comments from @zinekeller and @ChrisSD highlight the problems with opensourcing mixed-vendor heterogeneous code bases. Also open-sourcing code rarely means it becomes "maintenance-free".

I think you're right in that the road to MS open-sourcing Windows will be slowly starting to adopt other existing subsystems (and hopefully giving back) so that they are managing less and less proprietary code over time.

Psst! They technically released the ECMAScript/JScript (definitely not JavaScript®)* interpreter, Chakra (https://github.com/chakra-core/ChakraCore).

* Trademark notice: JavaScript® is a registered trademark of Oracle America Inc.

WebKit? Edge is using Blink, unless I’m misunderstanding?

Blink is the name they gave the fork of the webkit core.

The fork was years ago at this point. Blink and Webkit certainly share a lot of code, but I think it's inappropriate to completely lump them together.

Component by component, it would look like. And it makes sense to replace components with tried and tested open-source solutions to reduce internal maintenance burden for components with low visibility/profitability.

When was the last you heard somebody say: "I bought windows (server) because of the print subsystem"? I could see them adopting CUPS, for example. That way in 10 years they can stop maintaining theirs when current versions EOL.

But for "intimate areas" that may take time, or may never happen. Or they move into the hardware. So I remain skeptical wrt a 100% auditable (modern) tech-stack.

In the case of the browser-engine I wish though, that they had not picked webkit. What were the reasons against Gecko? Not "embedable" enough?

In fact, I think most companies buy Windows Server in spite of the printing subsystem. I still wake up at night mumbling “net stop spooler; net start spooler”

Windows' print subsystem was one of the ways it became so dominant, by having a standard hardware abstraction layer desktop software like word processors and spreadsheets could advertise "compatible with Windows printing" and buyers wouldn't have to shop around for software and printer models which were compatible with each other, and developers wouldn't have to . Jeffrey Snover talked about this as part of his design for PowerShell, to have a standardised management interface that admins could learn for scripting and automation, and third parties could present an interface to for managing their products and services.

The print subsystem is one of the backwards compatibility limits on redesigning parts of the classic control panel - I'm fairly sure Raymond Chen has written about it - because so many print drivers depend on the way it works to hack in pages and popup dialogs for specialist configurations for their printers.

It also integrates decently with Windows' granular permissions, file and printer sharing on networks, logging, has tons of specialist printers like label printers, receipt printers, etc and is used by a ton of 3rd party management and configuration tools. I would be hugely surprised if it's unsupported in 2031.

> "*"I bought windows (server) because of the print subsystem"?"

When was the last you heard somebody say: "I would buy Windows server, if it had CUPS printing support in it"?

Thank you for taking the time to write this!

When using CUPS in my previous posts as an example of "Standard OpenSource component that could be a drop-in replacement in a vast majority of deployments/installations", I was hoping, that somebody knowledgeable would reply with some details about the (speciality-use) features/use-cases of the Windows Print-System.

You mentioned a few points, that I'll try to itemize, and respond to:

* Specialty hardware setup, and UI's for that: In these times(for non-ancient devices/deployments), is that not easily solved by the [WEB-]UI of the printer?

* Speciality hardware runtime control for printjobs (staples, binds, folds, glue, mailing, ...): I thought, all of these are commonly abstracted into "verbs" in the PCL/PJL, and just need to be "included" in the PrintJob.

* Decent integration into enterprise setups. In what ways do you find CUPS lacking here? I find CUPS+AD-Auth_to_Samba4AD works great, and all the RSAT tools are functional from a domain member workstation

* Driver support: Is that really still a problem these days?

* Availability of paid support for Windows Printsystem for X amount of money in 2031: If commercial interest is there, I have no doubt, that MS will offer something like for WinXP and Win7 years after the normal EOL of Srv201{6,9}. I just thought, It was already visible now, that the "commercial interest" for this was going to be small, but then again I might be underestimating the (future) size of the "Seriously large-scale paper printing" market.

> "When was the last you heard somebody say: "I would buy Windows server, if it had CUPS printing support in it"? "

Admittedly, never, but I can probably count in years the paid time, that I have worked helping clients with their Windows Print problems, many times calming them down to get the screaming and crying under control. So maybe a replaced print-system (In WinServer) could (by some) be seen as net positive, while the average Windows Home user wont notice/care. ;)

Reply on news.ycombinator.com