Is the Quality of this Forum important to contemplate? Like any public forum, it is as strong or weak as whatever was posted recently, so quality varies and likely always will. Of course, having Jim and Matt and JR team frequently pop up to listen, discuss, and explain is not typical, it is wonderful. But it is not enough.
JR products need structured, current, frequently updated, complete Documentation. The Forum is not it. The Wiki should be, but it seems like a long-abandoned project. The Forum can be Support, but then, whatever clarification or explanation arises should be (promptly) used to update the Wiki. The fact that so many questions get asked over and over is a problem to solve. To a customer trying to use a complex product, critical information provided in a forum format, even with a few pinned posts, is like wandering a flea marketing hoping to find what you need.
Then, when JR staff and "super users" are able to help customers in the Forum, in the big picture it is a (J)River of wasted knowledge. So much valuable and essential information is lost among many posts in many threads for many versions over many years. It can't be found again, if ever, without enormous effort and considerable luck, and then it is never clear whether the info has been superseded or is obsolete. Most critically, there's no way for a customer to know if certain information exists. Not finding it via search can simply mean the wrong word was used, or the resulting list of posts was not carefully read read read read (when do you stop?).
The complexity of MC, plus JR's other innovative products, requires actual documentation, complete, and kept up to date. The Wiki format is fine, but not if it is left up to random volunteers. Every time a user or Matt or someone posts a better solution/explanation/caution/code/whatever, it should be promptly put in the Wiki as an update or expansion.
Bug Tracking is also required. It could be a section of the Wiki, no need to devise a new web site, but it needs to be organized in at least two dimensions -- by date/version as the current Update posts provide, and also by the feature/command/action/whatever of MC (and other apps). A third dimension should state the official app version/build, a fourth the platform/OS.
I can envision product documentation, support, and issues being aspects of the single Wiki, IF it has clean searching (structured forms) and results (structured lists). That would overcome a huge flaw in the Forum being Support: It is possible to search and search and search and never hit upon the right keywords to find the information, because there is no consistency to how all of our comments are worded. (Plus, the messy way Forum results are displayed is no fun to plow through.)
Again, the Pluses are huge: JR is a responsive company, key people are often involved, the products are terrific and sometimes unmatched in functionality, and excellent values.
But the Minuses are too big to ignore, and likely prevent (too many) potential customers from understanding and using the power that makes the rest of us so happy and loyal.
Back when I was a commercial software application developer, the CEO of an accounting software company I worked with said development costs should be 10% or less. 30% should be packaging (the days of physical media and docs) and marketing. 50% should be documentation, because all of the other costs and opportunities are wasted if the customer can't succeed. That left 10% for customer-specific support (telephone support in those days), with relentless focus on improving documentation so support is not needed. (Keep in mind, accounting software is complex and business-critical to customers.) The numbers might be different, but the notions seem to be pertinent to JRiver too. (PS: The accounting software company was bought by one of the huge companies for a huge price.)
But (full disclosure) I recognize that documentation perfection is never achievable. Back when there were computer bookstores, there were endless shelves of How To books on commercial software that presumably was already documented by its makers. I wrote two of those 1100 page books when I got frustrated at the poor documentation of a Microsoft database development platform. While I was happy to cash the (smallish) checks from Que Books, I kept thinking, why didn't Microsoft write these books? I also kept thinking, again and again, I need to make some changes here and there, based on new knowledge and understanding. But I couldn't. If only I had been able to provide my documentation/guidance in a live online Wiki...