One of the fundamental reason (other than the financial one) for such a split is that supporting all the community releases do not work in the long run. Some customers want 5+ years of support on a product line and it is simply impossible to support every single community release for 5 years.
There are two main strategies from here:
- slow down the release cycle and freeze innovation to match the 5 years customers
- leave the community projects release early, release often, innovate like crazy and fork them to do an Enterprise pace version
In the second model, an enterprise version is created every n community versions. This is where the support, packaging, service and advanced QA is provided. Packaging and QA are the ice on the cake, the five year support is really the meat (assuming a meat cake with ice is good :) )
Speaking of QA, yes deep internal QA is important and leverage bugs upfront but I trust the community QA more than any internal QA (more hands, more eyes, more time). I wish good luck to MySQL on their enterprise only features (semi-closed or closed source) but I think that will lower the quality of these particular features (less eyes, less hands, less time): my bet would simply to use the MySQL Enterprise version but not the "select" features. As Sacha like to say, in the JBoss Entreprise versions we remove features, we don't add them: unstable or experimental features are removed from the enterprise version. It's about less not more.
Generally speaking the support problem is interesting and usually kicks a company around its 5th birthday. The wannabee Platform as a Service contenders will face the same problem... in 5 years. "What do you mean the cloud where my data lives is too old??? Which version of the Cloud are you at?"