The devil hides in the details: it is all about how much "critical" the set of components is, and what is the core of the pb being reported. Because, as my expe

The devil hides in the details: it is all about how much "critical" the set of components is, and what is the core of the pb being reported. Because, as my experience goes, often the pb lies with the "dev" of the set of components itself, not the issue reporters. Software (open source or not) is plagued with planned obsolescence and software Rube Goldberg machines, and on components where it is accute, there is no reasoning of anybody, the "dev" is a scammer, not to mention the "dev" is often a corpo or an organized network of ppl (pulling the strings in the shadows). On critical, big and/or complex sets of components, and those would be well established ("financing" is kind of "secured", and those components are used a lot), the "dev" knows that hardly nobody will be able to provide real-life alternatives, then "dev" may give you a bit of attention but will send you to hell if you start to threaten their scam (namely the "financing" of their network of ppl). Usually, you will get partially true responses missing out the "disturbing" parts, all that with a ton of "mauvaise foi", like a troll. Fighting this can only by done on case by case basis since we are talking about complex component systems. Not to mention, mistakes can happen because it is easy to be fooled in complex matters. Sometimes, you may have to "follow the money" and go legal.