Oh...I think the griping is more that Flex (for whatever reasons, and your surmise of hardware people learning to do software is probably a big part of it) has been notorious for promising great things "real soon now" over the years. Clearly, they didn't live through the exciting early 80s in the PC software business where terms like RSN and vaporware came about.
Sure, they are responsive, in some cases, but not in others.
Sure, they suffer from the same ills of other software development by volunteers: the fun stuff gets worked on, the not-so-fun or not-so-useful-to-the-volunteer doesn't.
Sure, they have enthusiastic developers who can envision far into the future about cool stuff, but have trouble getting the nitty gritty done right.
However, they have to deliver something, sometime, and historically, there has always been a push for Dayton. New features come out in alpha/beta (working from memory, I'm too lazy to go dredge through copies of archives) in the fall/winter time frame, some work ok, some don't. Some form of informal triage happens, people put their nose to the grindstone to get a decently stable release out by Dayton time.
And that makes perfect sense and is hardly unreasonable. In the government world, you're driven by the Oct 1 Fiscal Year start. Lots of papers and reports get completed in August and September. Proposals are due in the spring. Big design reviews tend not to occur in the first weeks of October, because everyone ran out of money in the month before. Academia has its annual rhythm as well..
As for Flex being open and forthcoming... I'd have to say "it depends on what you're asking for".
Not that they're necessarily deliberately obstructive, but some requests might be real low on the priority list for a small company. Just getting a copy of the source code that matches the V1.18.6 demo .exe you could download from the splash page took a week or so of back and forth emails to find the right version that matched. And that required being VERY familiar with the source code to start with, so you could tell that the source didn't correspond to the .exe version. I suspect that most people would give up pretty quick.
And if it comes to asking detailed questions about how the signal processing works, or the software architecture... you're pretty much on your own, unless you get lucky. They may be open source, but they sure as heck aren't "open explanation", and as for reading the comments in the code.. well... there just aren't that many, and in a lot of cases they're wrong. (When I was looking at the IQ correction algorithms, most recently).
Is this good, bad, or indifferent? It depends on what you're looking for from Flex. If you want a basically turnkey product that does most of what most people want, and fairly well, then you probably are going to be happy. If you want to get into nitty gritty discussions of why certain implementations were done.. well, not so happy. But, on the other hand, it's true that you're not likely to do any better asking customer service at Icom why they chose particular design alternatives. From that standpoint, Flex is certainly no worse than the major mfrs.
Probably what gripes most people is that there's an expectation created (probably from the experimental heritage) that Flex would be more open and explanatory than most. Perhaps in the first couple years.. but when it became a real business..they're pretty much like other businesses.