The FAQ explains how both LiPS and OHA are similar in that they attempt to seek unity. However, LiPS is doing this through open standards, while Android/OHA is approaching the problem through ad-hoc standards…
LiPS argue that interoperability requires well-documented, stable API sets and semantics. Open source and proprietary code can change over time and both can fork. Hence, they argue that implementations (code) makes poor standards. This is demonstrated by the following diagrams…
However, there’s more to it than this. It’s not just about having an open standard, it’s also about the standard allowing for variability in hardware capability.
As we know from Java ME, a specification doesn’t necessarily translate to stable API sets and semantics due to ambiguity, human error and implicit differing capability across hardware when implementing solutions. LiPS is different in that it has extendable standard APIs and dynamic discovery that may at least solve some problems.
However, will LiPS be acceptable and flexible enough for all parties? Also, how good will the standard actually be at coping with extension and adaptation to include features that not only vary across phones but also features not thought of yet?
Some might even argue that the realms of extendable standard APIs and dynamic discovery are close to (OHA/Android) ad-hoc specifications. I suppose it depends on how the extendable APIs and the data underlying dynamic discovery are themselves controlled.
I think we can only answer these questions when we have seen some LiPS implementations on varying hardware and the steps we have to go to to program against variable hardware capability.