Short answer: Because this is my experience over the long term.
Long Answer: I didn't say that only open source can fix bugs in 24 hours but, in order to get your bug fixed in 24h in a closed source software, you need to pay some top dollar for that service. Otherwise you'll most probably wait for the next point release which may or may not contain a fix to your bug.
In most closed source software, the process is completely opaque after your bug report is acknowledged. You don't know when will it fixed or ever be fixed. That's not a joyful wait sometimes.
OTOH, you're absolutely right. Not all bugs in OSS is fixed in 24h straight. Some got never fixed or fixed out of the tree. Also, an awful lot of software dies. OSS projects probably die more because they are one man shows most of the time unless they get a loyal following and they are very very good. However, you can compile and patch a dead open source project. You can't revive closed source software once it's dead and bit-rotten.
I want to give a couple of fresh examples, from Intel.
I have an HP Spectre X2 detachable tablet PC which runs Windows 10. This PC has an embedded Intel Wireless Dual AC 7265 card. Out of the box, thing works great. Rock solid. Windows updated its driver in some point and that driver which, has WHQL seal and everything, crashes that wireless card. You need to reset the card every time the card goes low power mode and comes back.
Intel has an even more recent driver, which does not fix the issue. The PC has a full fleet of updates too. BIOS, ME firmware, board FW and what not. Nope. The problem is still there. What's the best solution? Roll back that driver to initial version. Now it works. Can Intel fix this? Of course! In 24h? Why not? Will they fix it? Of course not! Why? AC 7265 is EOL, so no incentives. However, on paper all of these drivers support 7265.
2nd example is e1000e Linux driver, again from Intel. This is an open source Intel Ethernet card driver which supports whole fleet of cards. From lowish-end to top end silicon. Intel added a new feature to this driver and some cards started to crash, incl. mine (relevant bugzilla is [0]). Patch is isolated, distributions rolled it back relatively quickly and many people are back on track. Kernel people are still looking at it without rush since, everything is working without the latest patch.
Who wrote the last crashing patch? Intel. Can they fix it? Of course! Even in 24h? They may if they really want to. Will they fix it? Of course not! Why? Not enough incentives.
Bonus: While unrelated to both, I've waited a company to change a string comparison to case insensitive mode (or just capitalize the first name of the file they bundle) for a software that I bought for over a year. I reported that thing 10+ times! They didn't fix it ever. I changed the name of the file on every update. Over and over.
Long Answer: I didn't say that only open source can fix bugs in 24 hours but, in order to get your bug fixed in 24h in a closed source software, you need to pay some top dollar for that service. Otherwise you'll most probably wait for the next point release which may or may not contain a fix to your bug.
In most closed source software, the process is completely opaque after your bug report is acknowledged. You don't know when will it fixed or ever be fixed. That's not a joyful wait sometimes.
OTOH, you're absolutely right. Not all bugs in OSS is fixed in 24h straight. Some got never fixed or fixed out of the tree. Also, an awful lot of software dies. OSS projects probably die more because they are one man shows most of the time unless they get a loyal following and they are very very good. However, you can compile and patch a dead open source project. You can't revive closed source software once it's dead and bit-rotten.
I want to give a couple of fresh examples, from Intel.
I have an HP Spectre X2 detachable tablet PC which runs Windows 10. This PC has an embedded Intel Wireless Dual AC 7265 card. Out of the box, thing works great. Rock solid. Windows updated its driver in some point and that driver which, has WHQL seal and everything, crashes that wireless card. You need to reset the card every time the card goes low power mode and comes back.
Intel has an even more recent driver, which does not fix the issue. The PC has a full fleet of updates too. BIOS, ME firmware, board FW and what not. Nope. The problem is still there. What's the best solution? Roll back that driver to initial version. Now it works. Can Intel fix this? Of course! In 24h? Why not? Will they fix it? Of course not! Why? AC 7265 is EOL, so no incentives. However, on paper all of these drivers support 7265.
2nd example is e1000e Linux driver, again from Intel. This is an open source Intel Ethernet card driver which supports whole fleet of cards. From lowish-end to top end silicon. Intel added a new feature to this driver and some cards started to crash, incl. mine (relevant bugzilla is [0]). Patch is isolated, distributions rolled it back relatively quickly and many people are back on track. Kernel people are still looking at it without rush since, everything is working without the latest patch.
Who wrote the last crashing patch? Intel. Can they fix it? Of course! Even in 24h? They may if they really want to. Will they fix it? Of course not! Why? Not enough incentives.
Bonus: While unrelated to both, I've waited a company to change a string comparison to case insensitive mode (or just capitalize the first name of the file they bundle) for a software that I bought for over a year. I reported that thing 10+ times! They didn't fix it ever. I changed the name of the file on every update. Over and over.
[0]: https://bugzilla.kernel.org/show_bug.cgi?id=205047