Coverity makes a shitload of money off FindBugs. It's annoying they don't contribute back while my organisation pays their most expensive license.
While Coverity does incorporate Findbugs results, it also has its own analyzer that does much more interprocedural analysis and tends to be tuned better for fewer false positives and more accurate error messages. Historically at least, part of the reason for incorporating Findbugs was to make it easier to directly compare what Findbugs found with what Coverity's analyzer found. Because every customer wanted to know that.
I have no idea of current figures but historically Java was not a big business for Coverity. Other vendors had much more Java business (and incidentally also incorporated Findbugs results).
Finally, as you can see from the message the Findbugs leadership does not seem unified and easy to collaborate with.
So forgive me but I find your comment and its tone a bit unfair.
It might seem unfair, but you stated that "every customer wanted to know that". So that project has value to you.
There weren't all that many such customers though (again, historically). A more typical customer was developing in C/C++.
Not sure I can comment on the results on your own code, but I will say that volume of results is not always correlated with value in static analysis. There are plenty of noisy rules that basically have negative utility if you factor in the time it takes to review each issue. It's a complex balancing act between finding more issues, having fewer false positives, analysis time, understandability of results, and other factors.
Simple subordination.