There's a learning curve to the OSIDs.
Cost of Entry
There are many development frameworks that have a low cost of entry. These frameworks are also limited in their ability to meet specific needs without creating balls of twine difficult to manage and maintain over time.
All design methodologies are pay now/reap later systems. Upfront cost of learning pays off down the road. This is at odds with projects whose primary goal is to demo something today and refactor as you go along.
Something needs to be built that uses OSIDs in order to interoperate with it or reuse it elsewhere. Building an OSID Provider isn't very interesting when you have only one. When you have a few, the cost of building newer ones drops tremendously.
Changes of Mindset
The OSID methodology also requires some different ways of thinking:
- Learning to navigate the OSIDs: There are lots of service packages and many many interfaces. Javadoc is not very useful and figuring out the pattens and what's what is necessary to understand what will go where.
- Feeling the difference between the roles of an OSID Consumer and OSID Provider. Non-service approaches tolerate command-and-control libraries and running all configuration through the application. The OSIDs are brutal by forcing implementation-specific concerns out of consumers to create that perforated line. Someone once barked at me, "That's just separation of concerns, everyone understands that!" Perhaps this is a concept well understand in this day and age but is often ignored. If you can't figure out how to make an OSID do what you want, this is likely the problem.
- Getting comfortable working the service models and understanding the ER notation.
- Learning how to read the specification to slice off what is needed and still be compliant. You don't have control to pick and choose anything. The specification is notched along clusters of compliance and required elements are in fact required. There are creative tricks to save time but ignoring things won't work well.
- Relaxing. OSIDs provide the track and will take you somewhere. It can be fought but that will be tiring. Another approach is to just go with it and see where that takes you. The latter is typically much more efficient, and fun.