If you have an existing large enterprise application packaged as e.g. a war file, the first question to ask is "is there any benefit in retrospectively refactoring it?". For example, if the application "just works" and there is little or no maintenance overhead then continuing to deploy it as a war may well be the right choice as there wouldn't be any obvious way to get an ROI on the investment.

If you do need to continue building on that code base - for example to add significant new features - then a payback from investing in increased modularity may make sense. For example an easy first step would be to pull out the third-party dependencies packaged inside the web app and instead using Import-Library or equivalent to manage those dependencies. The second step in moving such a code base would be to go to "shared services". If the application has been built using Spring, the first version of this step (horizontal decomposition) is generally easy too - simply split at the application services layer, pull this into a separate bundle, and expose the relevant services in the service registry. Depending on the features you need to add, this *could* enable them to be developed in a modular manner in their own bundle(s). Much more difficult (typically) would be introducing vertical decomposition after the fact - teasing out different vertical slices of the application functionality. The decision on whether it is worth doing this has to be made on a case-by-case basis.

When starting a new application it is of course much easier to design in modularity from the start. This doesn't mean that you can't take advantage of existing code in building those apps - a simple strategy of wrapping existing code in fairly coarse-grained bundles and using it as either a type library (Import-Package style) or services library (service references) will work. You haven't improved the modularity of the existing code, but you do enable new code to be written in a more modular manner.

Unfortunately for server vendors, most of the user value from a modular server architecture comes from the vertical decomposition (e.g. by system features/capabilities) not the (easier to do) horizontal decomposition!

Exactly.

So what is so different for customers and not just vendors with "large existing code bases" trying to benefit from this newness? Your statement implies that OSGi is not difficult for new greenfield projects but difficult for existing applications.