Getting other developers to use your code in their products is surprisingly difficult. A lot of this applies to open source development in general:
1. "Nobody's ever been fired for choosing IBM."
The codec is perceived to be "too new" (i.e. less than 5-10 or whatever years old), and the developer is just afraid to adopt it.
2. Inertia: The developer just has a super favorite codec they believe is useful for every scenario and they've already hooked it up, so they don't want to make the investment into switching to something else.
3. Politics: The developer irrationally refuses to even look at your codec because you work for the same company as they do.
4. Perceived lack of support: If the codec fails in the field, who's gonna help us debug it?
(I believe this is one reason why Rad's compression products are perceived to offer enough value to be worth purchasing.)
5. Linus hates C++: The codec is written in C++, so it's obviously crap.
6. Bad packaging: It's not wrapped up into a trivial to compile and use library, with a dead simple C-style API.
7. Too exotic: The developer just doesn't understand it.
8. Untested on mobile: It's been designed and tested on a desktop CPU, with unknown mobile performance (if it compiles/works at all).
9. Memory usage: It's perceived to use too much RAM.
10. Executable size: The codec's executable size is perceived to be too large.
11. Lacks some feature(s): The codec doesn't support streaming, or the decompressor doesn't support in-place decompression.
12. Performance: The thing is #1 on the compression ratio charts, but it's just stupendously slow.
13. Robustness: Your codec failed us once and so we no longer trust it.
14. Licensing issues: GPL, LGPL, etc. is the kiss of death.
15. Patent FUD: A patent troll has mentioned that your codec may be infringing on one of their patents, so the world is now afraid to use it. It doesn't matter if your codec doesn't actually infringe.
1. "Nobody's ever been fired for choosing IBM."
The codec is perceived to be "too new" (i.e. less than 5-10 or whatever years old), and the developer is just afraid to adopt it.
2. Inertia: The developer just has a super favorite codec they believe is useful for every scenario and they've already hooked it up, so they don't want to make the investment into switching to something else.
3. Politics: The developer irrationally refuses to even look at your codec because you work for the same company as they do.
4. Perceived lack of support: If the codec fails in the field, who's gonna help us debug it?
(I believe this is one reason why Rad's compression products are perceived to offer enough value to be worth purchasing.)
5. Linus hates C++: The codec is written in C++, so it's obviously crap.
6. Bad packaging: It's not wrapped up into a trivial to compile and use library, with a dead simple C-style API.
7. Too exotic: The developer just doesn't understand it.
8. Untested on mobile: It's been designed and tested on a desktop CPU, with unknown mobile performance (if it compiles/works at all).
9. Memory usage: It's perceived to use too much RAM.
10. Executable size: The codec's executable size is perceived to be too large.
11. Lacks some feature(s): The codec doesn't support streaming, or the decompressor doesn't support in-place decompression.
12. Performance: The thing is #1 on the compression ratio charts, but it's just stupendously slow.
13. Robustness: Your codec failed us once and so we no longer trust it.
14. Licensing issues: GPL, LGPL, etc. is the kiss of death.
15. Patent FUD: A patent troll has mentioned that your codec may be infringing on one of their patents, so the world is now afraid to use it. It doesn't matter if your codec doesn't actually infringe.