Best wishes.

Here's how I would describe it. Let's imagine you use Rational Team Concert for change management. You have a bunch of other tools and they integrate with your change management tool (Rational Team Concert) using the Open Services for Lifecycle Collaboration (OSLC) protocol and formats.

You decide that you no longer want Rational Team Concert. You replace it with some other tool that implements the OSLC change management spec. All of your tools that were integrated with Team Concert continue to work with the new tool because it's using the same OSLC protocols and formats.

Likewise, the goal is that our Jazz-based tools (Team Concert, Quality Manager, Requirements Composer) will all implement the appropriate OSLC specs and this will allow them to interoperate with a large number of tools (if/when others implement the OSLC specs) in a loosely-coupled way.

I would strongly urge you to listen to the podcast I mentioned above. It goes into this topic in some detail.

Sorry, Open Services for Lifecycle Collaboration (OSLC) is an effort that IBM started to produce the standard protocols and formats that are intended to allow integration via data-level and UI-level artifact linking. OSLC would not allow a Bugzilla defect to "become" a ClearQuest CR, but it would allow someone to link a ReqPro or DOORS (or whatever) requirement to anyone who implements the OSLC change management protcols and formats. An analogy is that a feed reader can do useful things with most any Atom/RSS feed.

The Jazz technology platform underlies Rational's products and implements the OSLC protocols and formats. We're trying to create very useful standalone products (Rational Team Concert) that support parts of the software lifecycle and can integrate with other tools that help with other parts of the software lifecycle using the OSLC protocols as the integration mechanism (as opposed to a shared technology stack ala Eclipse, .NET, etc.)

If you're interested, Steve Abrams and Carl Zetie of IBM and Mik Kersten of Tasktop (and Mylyn) just did a developerWorks podcast on collaborating together on the change management OSLC specs: http://www.developerfusion.com/media/16828/abrams-zetie-and-kersten-on-first-fruits-from-the-oslc/ (warning: they get lobbed quite a few softball questions but I think it's nonetheless an insightful discussion).

Thanks for the feedback. Your admonition about not slapping the Jazz label on everything is something we have to be careful about and don't always succeed on. I guess I don't see the contradiction that you do - why can't Jazz be a technology platform and an initiative? Jazz is not a web site, though we obviously have a web site (with a nice short URL). I looked at the About page you referenced (https://jazz.net/about/) and it's basically accurate, though in sort of IBM Professional English.

Here's how I would explain Jazz to another developer if I ran into him or her at a conference:

"I work on a technology at IBM called Jazz. What we're trying to do is make it easier for teams of people to build better software by making it easier for them to collaborate together. We're building a core technology stack ("Jazz") and we're building a bunch of products on top of it that address different parts of the software lifecycle - e.g. requirements, development, testing, build, move to production. If Jazz is going to succeed as a platform, we have to make it very possible to tie a lot of data together. You see, one of the things that we've learned is that it's not physically possible for human beings to build a single tool that solves every problem - the complexity is too great the interdependencies between components is too brittle. We believe that the only way all of these tools are going to work together is to define simple standard protocols and simple standard formats (open service for lifecycle collaboration - http://open-services.net/) built on top of standard Internet and web protocols (like http) and formats like AtomPub. Our Jazz-based products integrate together using this sort of loosely coupled web style and we're starting to integrate with business partners as well. Another thing I like about working on Jazz is the fact that we develop in the open at Jazz.net. Many of the leaders on our project like Erich Gamma, John Wiegand, and Dave Thomson came from Eclipse, and from that experience they came to realize that software turns out better when you open high-bandwidth direct channels with your users and extenders, so we're doing that with Jazz, even though it's commercial software."

That's about as simple as I can make it. I'm not sure if you're trying to understand or just to throw stones. If you'd like to learn more, there's some good info at Jazz.net, we're on YouTube (http://www.youtube.com/user/IBMJazz) or you can find a bunch of us on Twitter. http://jazz.net/community/twitter/. If you still think it's a bunch of marketing B.S. then that's that, but we have quite a few happy users, and we're working hard to make it better.

Did you look at http://jazz.net/ or IBM.com pages? We've tried to eliminate gobbledygook from Jazz.net. If you're seeing it, it's a bug :-)

Disclosure: I am a developer on Jazz and Rational Team Concert.

I can't speak for all of Rational or all of our users, but I can speak as a member of a development team that uses Rational Team Concert. When we were building what became Rational Team Concert (the first Jazz-based product), we made it an early priority (like 2 years before we shipped 1.0) that we would use Team Concert for our day to day development of Team Concert. Since we build Jazz and Team Concert from the ground up (read: from scratch), the early days of self-hosting were very painful, but because of this pain and the commitment of our developers to make continuous improvements, it's turned into a very useful well-integrated tool over the past couple of years.

We've had very good internal grassroots of Team Concert within IBM (I can't speak about customer uptake) and have received very positive feedback from customers and fellow IBMers about what we've done and where we're going with Jazz.

It's certainly not perfect and there's much more to do, but I assure you that Jazz is useful technology. It's not simply a "fancy marketing scheme for Rational products". Maybe try it out and judge for yourself.

Thanks,
Bill Higgins (bhiggins@us.ibm.com / http://twitter.com/BillHiggins / http://billhiggins.us/)