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.
The OSIDs, like any design methodology, is a pay now/reap later system. Something needs to be built that uses them in order to interoperate with it or reuse it. 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.