I don't think you understand HomeKit, or Apple's view of it.
What's important to Apple is that you have a good user experience. As this applies to HomeKit, there are a few important requirements: battery life, and security/privacy. Keep in mind we are in the early days of home automation, and all it takes is one bad story about the hacker adjusting your thermostat to sour the market.
The only way to achieve those objectives is to exercise some control over hardware manufacturers. Sure, you may lose some compatibility this way, but that is infinitely preferable to a security risk in a poorly-understood environment without good security hygiene traditions. As a software developer who works with Bluetooth hardware, the Apple MFI certification process is the only hardware cert for home automation I am aware of. So even if I was an Android dev, I would prefer to purchase hardware that went through MFI as it gives me a basic level of confidence that somebody signed off on this.
Secondly HK explicitly includes measures for compatibility, including a type of "bridge device" that can translate between HK and a manufacturer's proprietary (or open, as the case may be) format.
Thirdly you have to consider HK's target audience. One of the headline features inside the HK Apis is the support for multiple homes. The people who are early adopters of HK in the near future are not hackers sharing an apartment. It's the Tim Cooks of the world where throwing out the existing automation hardware is not of any concern.
Sure, at some point it will become ubiquitous, and as the market matures news stories about the dangerous thermostat hackers will be less of a concern. But that's not this release, and it may not be within the next five years. That's more than enough time to create HK bridges and poly lingual lightbulbs that speak multiple APIs and so on.
What's important to Apple is that you have a good user experience. As this applies to HomeKit, there are a few important requirements: battery life, and security/privacy. Keep in mind we are in the early days of home automation, and all it takes is one bad story about the hacker adjusting your thermostat to sour the market.
The only way to achieve those objectives is to exercise some control over hardware manufacturers. Sure, you may lose some compatibility this way, but that is infinitely preferable to a security risk in a poorly-understood environment without good security hygiene traditions. As a software developer who works with Bluetooth hardware, the Apple MFI certification process is the only hardware cert for home automation I am aware of. So even if I was an Android dev, I would prefer to purchase hardware that went through MFI as it gives me a basic level of confidence that somebody signed off on this.
Secondly HK explicitly includes measures for compatibility, including a type of "bridge device" that can translate between HK and a manufacturer's proprietary (or open, as the case may be) format.
Thirdly you have to consider HK's target audience. One of the headline features inside the HK Apis is the support for multiple homes. The people who are early adopters of HK in the near future are not hackers sharing an apartment. It's the Tim Cooks of the world where throwing out the existing automation hardware is not of any concern.
Sure, at some point it will become ubiquitous, and as the market matures news stories about the dangerous thermostat hackers will be less of a concern. But that's not this release, and it may not be within the next five years. That's more than enough time to create HK bridges and poly lingual lightbulbs that speak multiple APIs and so on.