[charukiewicz]

I've been working on a web application that has a bar code code scanning component and I will say that while the apparent performance of this library is impressive, I am not a fan of this pricing model, and that alone pushes me to use alternative libraries [1]. As an aside, the library I'm thinking of is based on zxing-js and seems to have perfectly acceptable performance scanning the bar codes in your OSS comparison [2] using the demo implementation [3] (it scans bar codes despite the name being "html5-qrcode").

For a library like this, the only really appealing pricing model is a flat fee that buys unlimited use of the version I buy in perpetuity (even if that fee is several thousand dollars). I'm not, however, going to pay monthly forever for code that (1) you wrote once and is now static, (2) that you aren't hosting, and (3) that I need to integrate into my application myself. That feels like paying my car manufacturer a monthly subscription for heated seats [4].

If I need support I will happily pay you a support fee. Moreover, I cannot take on the liability of my app's bar code scanner ceasing working because you decide to close your doors and then the license won't reactivate.

[1]: https://github.com/mebjas/html5-qrcode

[2]: https://strich.io/comparison-with-oss.html

[3]: https://blog.minhazav.dev/research/html5-qrcode

[4]: https://www.theverge.com/2022/7/12/23204950/bmw-subscription...

[alex_suzuki]

Fair enough. The library you are using is based on ZXing and if it works well for you, then great. I did not manage to scan those damaged codes using ZXing but perhaps I did not fully explore all possible tweaks.

It's a bit disingenuous to claim that I wrote the code once and it is now static (I wish!), but I see that you are not a fan of aubscription models and I understand that.

[charukiewicz]

> It's a bit disingenuous to claim that I wrote the code once and it is now static

Unless the library code were in some way self-updating or had some server side component, I think it's disingenuous to call the library code embedded in my app anything other than static. I assume by "not static" you are referring to decision to continue improving it, which I think is great and affords you the ability to sell me a newer version.

[alex_suzuki]

The problem is that unlike „server-side computing“ the web browser and also mobile platforms like iOS and Android move pretty fast. Things change, and things break. Having a „stable version“ is great until a browser vendor decides to update/break an API an the library breaks. Now you have feature updates and hotfixes for an infinite number of „stable“ versions.