4 ms·

Yep. ANSI and ISO emerged because it was mutually beneficial for all. Just like the Khronos group. It's also important that following the standards should be v

Yep. ANSI and ISO emerged because it was mutually beneficial for all. Just like the Khronos group. It's also important that following the standards should be voluntary so innovation can flourish without being hindered by the committee. With the hope that the good ideas will make it back into the open standards.

yuhong 11y ago
Yea, reminds me of the original Altair and IBM PC and how both was cloned with profit margins on the boxes falling over time. Unfortunately I think ANSI/ISO and other standard committees was probably poorly suited to setting standards in this area. The right way back then would probably be to design a reference system and release schematics and other design information.
- AnthonyMouse 11y ago
  > The right way back then would probably be to design a reference system and release schematics and other design information. The interesting choice is to release a fully open design with a solid implementation for your own hardware but also one for the competitor's hardware that meets every part of the spec but you've spent no effort to optimize. Then everyone starts with your API because it gives support for the largest variety of hardware out of the gate and only supports the competing proprietary API if the project has the resources and the performance difference can justify it. Which puts the competing hardware vendor in a tough spot. Either they do the work to optimize the open API implementation for their hardware, essentially guaranteeing that the open API wins, or they don't and users of software that supports only the open API start to avoid their hardware.
  - yuhong 11y ago
    I am not talking about APIs.
  - wallacoloo 11y ago
    This doesn't happen for the same reason that open source developers have such a difficult time implementing open standards for closed, proprietary hardware - how do you add support for a low-level protocol to a competitor's product when their product is essentially a black box?
    - AnthonyMouse 11y ago
      Create an abstraction layer on top of their public API. This is the part where you don't really care if the performance is great.

yuhong 11y ago

Yea, reminds me of the original Altair and IBM PC and how both was cloned with profit margins on the boxes falling over time. Unfortunately I think ANSI/ISO and other standard committees was probably poorly suited to setting standards in this area. The right way back then would probably be to design a reference system and release schematics and other design information.

AnthonyMouse 11y ago
> The right way back then would probably be to design a reference system and release schematics and other design information. The interesting choice is to release a fully open design with a solid implementation for your own hardware but also one for the competitor's hardware that meets every part of the spec but you've spent no effort to optimize. Then everyone starts with your API because it gives support for the largest variety of hardware out of the gate and only supports the competing proprietary API if the project has the resources and the performance difference can justify it. Which puts the competing hardware vendor in a tough spot. Either they do the work to optimize the open API implementation for their hardware, essentially guaranteeing that the open API wins, or they don't and users of software that supports only the open API start to avoid their hardware.
- yuhong 11y ago
  I am not talking about APIs.
- wallacoloo 11y ago
  This doesn't happen for the same reason that open source developers have such a difficult time implementing open standards for closed, proprietary hardware - how do you add support for a low-level protocol to a competitor's product when their product is essentially a black box?
  - AnthonyMouse 11y ago
    Create an abstraction layer on top of their public API. This is the part where you don't really care if the performance is great.