Het punt komt dan neer op de vraag, wie is er verantwoordelijk voor drivers, de OS maker, of de hardware bouwer. Persoonlijk was ik er altijd vanuit gegaan dat die in elk geval in eerste instantie bij de HW maker lag. HW maker hoeft maar een beperkt aantal drivers voor zijn product te maken, zeg 3 a 4 Windows versies, terwijl de OS bouwer enkele tientallen drivers per HW categorie zou moeten creëren. Dus puur pragmatisch zou ik zeggen dat de HW maker verantwoordelijk blijft voor de drivers. Maar aan de andere kant ben ik geen IT'er dus misschien l*l ik wel uit mijn nek

.
Het moet een beetje van twee kanten komen. Als het OS verandert dan moeten de drivers soms ook worden aangepast.
Die gedachte dat drivers puur een aangelegenheid is voor de hardwarefabrikanten is heel logisch en het is in praktijk ook hoe het ongeveer werkt onder Windows.
Dat model ziet echter één dingetje over het hoofd, namelijk dat de meeste hardware helemaal niet uniek is. De meeste hardware is gebaseerd op een paar standaard-chipjes die door alle fabrikanten gebruikt worden. Denk bijvoorbeeld aan grafische kaarten met een NVidia-chipset. Alle fabrikanten gebruiken dezelfde chips. Als ze zelf drivers leveren dan bestaan die voor 99% uit code die ze kant-en-klaar van nvidia hebben gekregen.
Bij grafische kaarten is het vrij duidelijk, veel gebruikers halen hun drivers direct bij nvidia en niet bij de leverancier van hun hardware, maar bij veel andere hardware komt het ongeveer op hetzelfde neer. Ook geluidskaarten/headset/audio-dongles/etc, camera's, nics etc zijn allemaal gebaseerd op een vrij beperkte set moderne chips.
Momenteel is de relatie onder Windows: chipfabrikant -docs-> OEM -code-> MS.
Maar dat dan 100 keer opnieuw, voor iedere OEM een keer, terwijl de onderlinge verschillen meestal vooral cosmetisch van aard zijn.
Onder Linux wordt de OEM stap overgeslagen: chipfabrikant -docs+code-> Linux
Je hebt één driver die alle hardware aanstuurt die een bepaalde chip gebruikt. Als er een nieuwe OEM bij komt die z'n producten baseert op bestaande chips dan werkt het waarschijnlijk out-of-the-box.
Het nadeel van dat model is dat er weinig ruimte is voor OEM-specifieke aanpassingen. Als een OEM bv ledjes op z'n grafische kaart zet dan worden die waarschijnlijk niet ondersteunt door de generiek driver.
Het voordeel is dat er veel dubbel werk wordt uitgespaard en alle energie zich kan richten op één generieke driver.
Voor bovenstaande is Intel alleen niet zo'n best voorbeeld omdat Intel zelf ook chipfabrikant is, maar in weze is het probleem hetzelfde. De documentatie en de code liggen bij Intel en niet bij MS.
En tuurlijk Kan MS dan wel zelf drivers creëren voor HW die niet meer door zijn maker ondersteund wordt, maar in dit geval vallen de kosten baten analyse denk ik behoorlijk uit richting kosten met weinig baten.
Als ze daar nu nog aan moeten beginnen dan is het inderdaad een erg dure grap. Als ze echter vanaf dag 1 hadden samengewerkt met Intel aan een gezamelijke driver dan zou MS nu het beheer van die driver kunnen overnemen.