In a former job, I was a sysadmin at a company that does process engineering for industrial plants, and sometimes the automation/SCADA people would turn to me for help. It was very exciting to me, because a) I got to leave the back office for a short while and actually engage with a customer and b) I got to see firsthand and learn (a little, at least) about industrial plants, which was fascinating.
I find history fascinating, and I have soft spot for retro/vintage technology, so I got to see and touch some interesting stuff. One customer was doing an upgrade in 2015(!!!) from Windows NT 4.0 to Windows XP (!!!). They could not go further, because they were dependent on some piece of hardware whose vendor had gone out of business, leaving behind device drivers that would not work on any Windows after XP.
For this kind of customer, I think, the prospect of an operating system where those device drivers would continue to work while also supporting more recent hardware would be very attractive.
Industrial installations apparently have lifetimes that are far longer than what even "enterprise" operating systems offer, and replacing that Windows NT 4.0 box with a Windows 7 box (let's not even think of anything more recent) is a huge challenge just from the technical perspective. But it gets a lot more hairy when things like certification and compliance to legal requirements come into play, where you cannot just upgrade a box from Windows XP to Windows 10, because then you lose your certification, and re-certifying the installation is a costly and (I assume) tedious procedure.
TL;DR: I believe there could be pretty lucrative market for ReactOS in industrial applications. It would require a fair amount of up-front capital to get going, but if you can provide support for large-scale industrial customer to keep their systems running for twenty or forty years, there has got to be a lot of money in it.
At some point I'd imagine that requiring the source code for such critical components for a long-lived machine is going to be the only sustainable way forward. At this point you'd end up reverse engineering device drivers or using 'unsupported' configurations to keep going.
Of course the fact that a company that no longer exists can't support such a configuration doesn't matter because they aren't there anymore to care about any of it.
At work we have a glovebox running DOS. The software is written in MS/GW/Q basic and only works with a specific set of ISA IO cards. The manufacturer is long gone but one of their techs bought out the remainder and now gate keeps the software. He has the source but refuses to update, sell, license or release it. Last we spoke to him he wanted $20000 to write a new control program in visual basic using a PCI card and refused to release source code. We flat out said no. The plan is once there are no more spare parts on the shelf the whole thing is getting gutted and a modern PLC system installed in-house.
I agree. I thought Stallman was a nut (and in most respects I still definitely do) but since working with proprietary systems of the 80s and 90s I've realized his hardline free software stance is a direct response to companies like SCO.
I got into free software relatively early in my life and it was like watching a parody film before the original.
I really don't think $20k is unreasonable to rewrite something for a manufacturer. Chances are they'd change the scope, make requests and he'd need to modernize it and I can easily see something like that taking 1-2 months.. at which point $20k could be very reasonable vs the time and effort it'd take to find someone completely new to your system.
If I was the company though I would make sure that them providing the new source would be part of that $20k though or an agreement that when he no longer offers his services personally, regardless of whether he sells the company or not, that he will also release the source code to them if they are unable to negotiate for it upfront.
I think that would be fair and fulfill both parties concerns.
I personally prefer open sourced solutions as well, but in business that just isn't always practical.
So he should work for free in order for some company to make money? If that is what FSF is for then it is not very usrful for devs.
He shoulf provide the source code in 3rd party escrow but considering that company doesnt want to negotiate at all, he should not just give them the source for free.
I have a lot of experience in the industrial SCADA domain. I largely agree with you, but I will say that historically most installations have had all the relevant source code available to them, or owned by them.
In most cases, the limiting factors for lifespan were:
1) Inability to get replacement hardware
2) Inability to find anyone who can understand the source code.
There's really no way around issue #1. Having the software source doesn't really help that much because most of the time they'll use "migrations" every 10-15 years to rewrite the code using updated understanding of how they want the plant to work. Kicking off a SCADA upgrade is used as a wonderful convenient excuse to drive a lot of meetings/paperwork processes to define "How can we improve safety, improve reliability, make life easier for the human operators, etc?"
Nowadays, the thing time-limiting many SCADA installations are licensing for Windows LTSB and PLC/DCS vendor software. Often times newer versions will require new Dell/HPE servers for compatibility. It's expensive, but also not expensive enough to focus on changing.
The main point is that while licensing artificially limits "longevity" of a machine, closed-source does not. Instead, unavailable replacement hardware limits "longevity" more than "closed source" does.
If/when Windows Terminal integrates sixel support, any cheap laptop should be able to do that OOB (some of them with a USB to serial adapter of course)
From what little insight I could gain, I agree about the hardware problem. The customer I was talking about was nervously trying to find a reliable supplier of motherboards with ISA slots and parallel ports.
I really love the nostalgia this kind of hardware stirs in me, but I am glad I do not have to deal with that kind of trouble. (A few years ago, I read on another forum about an IT guy getting a call on the weekend from a desparate customer looking for an HDD using some standard that predates non-S-ATA... MFM, I think?)
Luckily for that guy, someone has made a MFM-to-SD-card with arbitrary command and geometry transformation recently, it it has turned out to be great. There are MFM-to-SCSI and even SCSI-to-floppy interfaces. The great thing about SCSI in the middle is that it's the same protocol supported by systems today so you could then just convert using generic hardware and software available right now. The system on the other end is none the wiser and thinks everything is still the old interface with the old parameters.
Does management really understand how long the equipment is going to be used when it is purchased? From what I've seen, upper management has done the cost analysis before purchasing but maintenance is going to ultimately going to be be responsible for keeping the equipment running. By this point in time, those that approved the purchase are likely retired.
I'm not sure what an acceptable time horizon for these types of things is in an industrial setting, but as a middle aged person in management, I'd consider anything that lasts until after I retire a success. I don't deal a lot in mechanical systems, however, but I can certainly see someone who's not fully versed in a technology thinking 20-30 years is a longer lifespan than almost anything they interact with on a daily basis. What is the expected lifespan of system with a microchip that presumably needs to be updated, secured, etc on a regular basis?
The PLCs are great, it’s the damned computers and their operating systems that keep needlessly changing our working system.
That's my gripe these days, long term used to be 20+ years. You can still get DL400 series PLC's from Automation Direct (rebranded Koyo) which are from the 90's. Now I see many embedded micros and processors advertised with 10 year long term supply. To me long term is around 20 or more years, basically someones career span. And dont get me started on all this industry 4.0 PC based control crap. Not everything needs millions of lines of Linux kernel to turn a few io points on or off. And the bloated systems that these platforms utilize is nauseating.
I would find it more likely that old device drivers get decompiled and reverse engineered.
Heck I think there's a lot of value in an emulator for old device drivers. Who cares what the source was when you just execute the black box in a highly regulated sandbox? (Note doesn't work for some medical software). I think medicine and astro / aero are the few places that would require full decompilation of an original driver.
Comments
In a former job, I was a sysadmin at a company that does process engineering for industrial plants, and sometimes the automation/SCADA people would turn to me for help. It was very exciting to me, because a) I got to leave the back office for a short while and actually engage with a customer and b) I got to see firsthand and learn (a little, at least) about industrial plants, which was fascinating.
I find history fascinating, and I have soft spot for retro/vintage technology, so I got to see and touch some interesting stuff. One customer was doing an upgrade in 2015(!!!) from Windows NT 4.0 to Windows XP (!!!). They could not go further, because they were dependent on some piece of hardware whose vendor had gone out of business, leaving behind device drivers that would not work on any Windows after XP.
For this kind of customer, I think, the prospect of an operating system where those device drivers would continue to work while also supporting more recent hardware would be very attractive.
Industrial installations apparently have lifetimes that are far longer than what even "enterprise" operating systems offer, and replacing that Windows NT 4.0 box with a Windows 7 box (let's not even think of anything more recent) is a huge challenge just from the technical perspective. But it gets a lot more hairy when things like certification and compliance to legal requirements come into play, where you cannot just upgrade a box from Windows XP to Windows 10, because then you lose your certification, and re-certifying the installation is a costly and (I assume) tedious procedure.
TL;DR: I believe there could be pretty lucrative market for ReactOS in industrial applications. It would require a fair amount of up-front capital to get going, but if you can provide support for large-scale industrial customer to keep their systems running for twenty or forty years, there has got to be a lot of money in it.
At some point I'd imagine that requiring the source code for such critical components for a long-lived machine is going to be the only sustainable way forward. At this point you'd end up reverse engineering device drivers or using 'unsupported' configurations to keep going.
Of course the fact that a company that no longer exists can't support such a configuration doesn't matter because they aren't there anymore to care about any of it.
At work we have a glovebox running DOS. The software is written in MS/GW/Q basic and only works with a specific set of ISA IO cards. The manufacturer is long gone but one of their techs bought out the remainder and now gate keeps the software. He has the source but refuses to update, sell, license or release it. Last we spoke to him he wanted $20000 to write a new control program in visual basic using a PCI card and refused to release source code. We flat out said no. The plan is once there are no more spare parts on the shelf the whole thing is getting gutted and a modern PLC system installed in-house.
Such stories are exactly the reason why Stallman created FSF.
I agree. I thought Stallman was a nut (and in most respects I still definitely do) but since working with proprietary systems of the 80s and 90s I've realized his hardline free software stance is a direct response to companies like SCO.
I got into free software relatively early in my life and it was like watching a parody film before the original.
I really don't think $20k is unreasonable to rewrite something for a manufacturer. Chances are they'd change the scope, make requests and he'd need to modernize it and I can easily see something like that taking 1-2 months.. at which point $20k could be very reasonable vs the time and effort it'd take to find someone completely new to your system.
If I was the company though I would make sure that them providing the new source would be part of that $20k though or an agreement that when he no longer offers his services personally, regardless of whether he sells the company or not, that he will also release the source code to them if they are unable to negotiate for it upfront.
I think that would be fair and fulfill both parties concerns.
I personally prefer open sourced solutions as well, but in business that just isn't always practical.
So he should work for free in order for some company to make money? If that is what FSF is for then it is not very usrful for devs. He shoulf provide the source code in 3rd party escrow but considering that company doesnt want to negotiate at all, he should not just give them the source for free.
Free software is not about price, it's about freedom. It can and should be paid for.
I have a lot of experience in the industrial SCADA domain. I largely agree with you, but I will say that historically most installations have had all the relevant source code available to them, or owned by them.
In most cases, the limiting factors for lifespan were: 1) Inability to get replacement hardware 2) Inability to find anyone who can understand the source code.
There's really no way around issue #1. Having the software source doesn't really help that much because most of the time they'll use "migrations" every 10-15 years to rewrite the code using updated understanding of how they want the plant to work. Kicking off a SCADA upgrade is used as a wonderful convenient excuse to drive a lot of meetings/paperwork processes to define "How can we improve safety, improve reliability, make life easier for the human operators, etc?"
Nowadays, the thing time-limiting many SCADA installations are licensing for Windows LTSB and PLC/DCS vendor software. Often times newer versions will require new Dell/HPE servers for compatibility. It's expensive, but also not expensive enough to focus on changing.
The main point is that while licensing artificially limits "longevity" of a machine, closed-source does not. Instead, unavailable replacement hardware limits "longevity" more than "closed source" does.
Just look at the price of used serial consoles with Sixel support.
Some hardware can be replaced by software... but not all of it.
My kingdom for a windows terminal emulator that supports both [xyz]modem and sixel and can connect to a physical serial port.
If/when Windows Terminal integrates sixel support, any cheap laptop should be able to do that OOB (some of them with a USB to serial adapter of course)
If TeraTerm would add sixel I'd be really happy since it does almost everything else I need perfectly.
From what little insight I could gain, I agree about the hardware problem. The customer I was talking about was nervously trying to find a reliable supplier of motherboards with ISA slots and parallel ports.
I really love the nostalgia this kind of hardware stirs in me, but I am glad I do not have to deal with that kind of trouble. (A few years ago, I read on another forum about an IT guy getting a call on the weekend from a desparate customer looking for an HDD using some standard that predates non-S-ATA... MFM, I think?)
Luckily for that guy, someone has made a MFM-to-SD-card with arbitrary command and geometry transformation recently, it it has turned out to be great. There are MFM-to-SCSI and even SCSI-to-floppy interfaces. The great thing about SCSI in the middle is that it's the same protocol supported by systems today so you could then just convert using generic hardware and software available right now. The system on the other end is none the wiser and thinks everything is still the old interface with the old parameters.
Does management really understand how long the equipment is going to be used when it is purchased? From what I've seen, upper management has done the cost analysis before purchasing but maintenance is going to ultimately going to be be responsible for keeping the equipment running. By this point in time, those that approved the purchase are likely retired.
I'm not sure what an acceptable time horizon for these types of things is in an industrial setting, but as a middle aged person in management, I'd consider anything that lasts until after I retire a success. I don't deal a lot in mechanical systems, however, but I can certainly see someone who's not fully versed in a technology thinking 20-30 years is a longer lifespan than almost anything they interact with on a daily basis. What is the expected lifespan of system with a microchip that presumably needs to be updated, secured, etc on a regular basis?
I am currently working on a power plant control system that has a modicon 984 plc first released in 1991.
We expect minimum 20 years from PLCs, and unless parts become unavailable or failures too frequent we would generally go 30 years before replacement.
The PLCs are great, it’s the damned computers and their operating systems that keep needlessly changing our working system.
So we virtualize and air gap.
That's my gripe these days, long term used to be 20+ years. You can still get DL400 series PLC's from Automation Direct (rebranded Koyo) which are from the 90's. Now I see many embedded micros and processors advertised with 10 year long term supply. To me long term is around 20 or more years, basically someones career span. And dont get me started on all this industry 4.0 PC based control crap. Not everything needs millions of lines of Linux kernel to turn a few io points on or off. And the bloated systems that these platforms utilize is nauseating.
I would find it more likely that old device drivers get decompiled and reverse engineered.
Heck I think there's a lot of value in an emulator for old device drivers. Who cares what the source was when you just execute the black box in a highly regulated sandbox? (Note doesn't work for some medical software). I think medicine and astro / aero are the few places that would require full decompilation of an original driver.