Just as O-O programmers create instances of their classes, the OSLC community has been creating instances of its specifications. As more and more implementations become available, more and more of the promise of OSLC comes to be a present reality.
So what is some of that promise?
For tool users, whether they be the actual users, or the business leaders making the purchasing decision: increased choice of software for each role (developer, tester, business analyst, service engineer, ...) that integrates "out-of-the-box". This helps workers achieve their best, helps the business maximize its existing investments.
For integration providers, whether they be the tool vendors themselves, third-party specialists, or end-users with custom software: predictability and re-use, of both code and skills, when developing integrations.
To see how you can realize some of that promise today, take a look at the updated OSLC software page. While it still takes some manual effort to extract specifics, if you do nothing but look at the products listed in the first column of either table, you'll get a sense of the software choice that is possible because of OSLC-based integrations. (If you have an OSLC implementation that is not listed on the software page, please follow the instructions for submitting it there.)
To further illustrate, lets explore some examples.
Lets assume you're already using HP Quality Center for test development and execution. By using the Kovair Omnibus OSLC Adapter, you should be able to work directly with those HP QC records, through the OSLC Quality Management specification, from within any of these products: IBM Rational Asset Manager, IBM Rational ClearQuest, IBM Rational DOORS, IBM Rational Requirements Composer, IBM Rational Rhapsody Design Manager, IBM Rational Software Architect Design Manager, or IBM Rational Team Concert. That is, an OSLC adapter for HP QC makes it possible to integrate with seven (7!) different IBM Rational products.
Before going on to another example, it is important to note that Kovair (like any OSLC implementer) may, or may not support all those possibilities. If they wanted to, however, instead of writing and testing seven different integrations, their effort would only be to test seven different integrations (and handle any special cases for variance between implementations). Further, going forward, they'll only have to maintain a single integration, and the same skills they used to implement the QM spec will be transferable to other OSLC specification implementations.
To help make it less likely that implementers will need to handle special cases based on quirks in specific OSLC implementations, Eclipse Lyo developers are working hard on test suites. As implementers start assessing their OSLC implementations using the Lyo test suites, there will be more consistency across implementations. At present, Lyo test suites are available for the Core and Change Management specifications. The Lyo project is looking to increase the test suite coverage across specifications as well as improving the existing coverage within specifications. New contributors are welcome and should visit the Lyo test suite wiki for information on getting started.
Given the advantage CM implementers have, thanks to the available Lyo test suite, lets take our next example from that perspective.
Lets suppose you're a tool vendor, and a customer has requested that you integrate with Atlassian JIRA. You now have a choice: you can do a one-off, point-to-point integration between your tool and JIRA, or you can enable your tool as a CM consumer. As a CM consumer, users will be able to integrate your tool with IBM Rational Change, IBM Rational Quality Manager, IBM Rational Rhapsody Design Manager, IBM Rational Software Architect Design Manager, IBM Rational Team Concert, and Mantis Bug Tracker without any additional software.
But JIRA isn't in that list! That is why adapters, like IBM Rational OSLC Adapter for Atlassian JIRA, Kovair Omnibus (mentioned above), and Tasktop Sync, play such an important role in helping users realize the value of OSLC today. Through Kovair Omnibus, in addition to integrating with JIRA, it should be possible (same caveats as above) to integrate with five (5) other products. Through Tasktop Sync (with the same caveats), users should be able to integrate your software with JIRA and twelve (12!) other products.
That said, there is nothing stopping you from creating your own OSLC CM adapter for JIRA. You'd have to learn the JIRA custom API to create a point-to-point integration anyway, but now instead of just integrating one product with your tool, you make it possible to integrate many products with your tool (there are 23 products that are CM providers natively, or through an adapter). Further, you give yourself the option of selling your JIRA adapter (just as Kovair and Tasktop have done) to anyone who wants to integrate JIRA with one the CM consumers listed on the OSLC software page. Even if you really only want to have JIRA integrate with your product (as is the case with the IBM Rational JIRA adapter), doing so using OSLC keeps the door open in case you need to reverse that decision in the future.
As far as realizing the OSLC vision, we're still in the early days. As far as realizing value from OSLC, software users and creators can, and have, done so already.