I'll add my 2 cents to this interesting topic (which I admittedly didn't read through completely).
Pet:
I get (and agree with) most of your points, as a user. However, consider that switching from an Open Source project to a business does drain a lot of effort, and definitely distracts you from development in the first place. This usually rocks the boat for several months, or one year.
Hopefully, after this is settled, some focus on product development will be restored. Otherwise, FengOffice may decide to discontinue the open source version and move to a purely Software as a Service strategy. Arguments for keeping the OSS distribution are mainly: let OSS users beta-test code before deployment in production; much better feedback on the product: broader, more responsive, "collaborative" rather than "critical", and from people with technical competences; offload of some development work, but this requires very good practices, fantasy and organization.
Conrado:
I still find OpenOffice great. As team leader of several OSS, I know it's hard to keep the pace with feedback from users. However, when missing offers of code contribution, you are really missing labour opportunities. MySQL does not have a community because their code is nasty crap, but you have some growing and proving willing to talk and contribute.
One great way to leverage it, helping OG as well, would be for you to define a strategy to handle it.
For example, you can periodically define and clearly publish to the community a bunch of broader "open items" that they're welcome to contribute to. Now a problem is that users often submit low quality code, often because they have no background on other architectural choices and practices you do; so invite developers to contact you to book work on them, for tipping or discussing quickly the right way to go about them. Do not require "committable" code, require generic implementation of something (converters, algorithms etc) that *you* can then embed in the code cleanly. Once you have a contribution, make sure you commit it reasonably soon (< 2 weeks); if you don't, users will be annoyed and you risk to forget about them. Make extensive use of branches on your repository if you need to.
Feel free to "hide" the community a bit behind the curtain, some customers turn their nose if they see it (so people do it/have it for free? It must be not as good as other commercial ones), but keep lively releases to keep the community hot -- release early, release often.
And good luck with the business.