While attending John Simonds’ and Monical Wells Grace’s very entertaining RSDC Bloggers Meetup, I was asked by Buell Duncan what the news of the show was. As the event being held just prior to the Jazz BOF, I responded without hesitation: ISVs. Would that I could have that statement back, however, because the news of the show was clearly and unquestionably Jazz. The project is important on multiple levels: pure technological innovation, architectural flexibility and heterogeneity, development style, and its broader, non-software development implications.
My initial response can be excused in that the ISV story is indeed an important one for Rational. Dating back to its pre-IBM days, Rational has been a brand about heterogeneity, one that bridged the Java and .NET camps in an effort to market to the widest possible audience (though their overall lack of attention to the world of dynamic languages is perplexing). Despite that heritage, however, and its Eclipse underpinnings, Rational does not have anywhere near the ISV story that it should. This conference, while better attended than it was last year, is dwarfed by its Lotus counterpart Lotusphere. With all due respect to the Lotus brand, there’s no logical reason that should be. The Eclipse project demonstrates quite adequately the vibrancy of the development ecosystem, and yet Rational has not accrued that kind of partnership return.
There’s likely no single reason for this; there are architectural, economic, branding, and logistical components to the problem. The good news for Rational is that this defect, to use their lexicon, has been identified and targeted for remediation. Part of Danny Sabbah’s (Rational GM) mandate, I have no doubt, is to turn around the partnership story – to leverage the network effect in selling a Rational ecoystem comprised of more than Rational products, much as Eclipse does. When not commiserating over the shellacking Josh Beckett took at the hands of the hated Yankees, Rational’s Diane Flis, Mike Loria and I discussed precisely this problem.
With all of that in mind, then, you can perhaps see why I answered Buell as I did. But let me explain what I see in Jazz, so that you can see why I was wrong.
I first saw Jazz, I’m fairly sure, a couple of years ago in a brief demo at the AlphaWorks booth at an earlier RSDC. At the time, it was an interesting but seemingly trivial technology that baked colllaborative technologies such as presence and instant messaging into the application development process. What I saw on stage yesterday, however, was a quantum leap from that toy. Cote’s impressed with what he’s seen and heard, and it would appear that the always sharp Darryl Taft found something of interest in the project as well. For good reason.
Just what was it that I saw yesterday that was so convincing? Well, I hate to say this but it really is one of those demos you have to see to appreciate. Basically, the application development process was inextricably intertwined with collaboration, so that developers could see changes that their colleagues had made – before they hit version control, in real time – and adjust on the fly. Changes are passed back and forth fluidly, bugs can be reallocated dynamically based on severity and those with nothing whatsoever to do with the project can still have visibility into it. If application development had been invented after Ajax, Bazaar/Subversion and instant messaging it would look a lot like Jazz.
The conclusion slide of the presentation described Jazz’s accomplishments with unhelpfully vague terms such as team awareness, process awareness, or extensible team server. I won’t presume to speak on your behalf, but those don’t mean a lot to me. What they’ve actually built, in my opinion, is a truly network aware and enabled development process and lifecycle. For all of the sophistication of some of the more recent vintage application development infrastructure tools such as the previously mentioned Bazaar-NG, they’re still rooted in software development processes that don’t leverage the full power of the network.
In a way, then, Jazz is to traditional software application development and management tools as Zimbra is to Exchange or Notes – a fundamental rethinking of the way the entire process works from end to end. A rethinking that is intrinsically network aware.
Besides the technology, Jazz is notable for its architectural flexibility/heterogeneity, and its broader, non-software development implications. Want proof of the first point? Yesterday’s demo ran on an architecture built on Cloudscape (AKA Derby), Jabber, REST, and Tomcat – and integrated at one point with Visual Studio. I couldn’t ask for more than that.
Beyond the technology, Jazz is important because of its broader implications for IBM. First, Jazz may be tremendously relevant to disciplines well beyond software development. I hadn’t really considered that possibility, but Murray Cantor, an IBM Distinguished Engineer, discussed that with me this morning, and I tend to agree. Jazz, if properly executed and built on an open architecture, would be applicable to problems afflicting a variety of verticals, from healthcare to manufacturing.
It was another implication of the Jazz project that had a lot of people at the show talking, however; their intention to develop Jazz under what they term an “Open Commercial Software development” methodology. This is not to be confused with open source, because they have no intention of allowing for external contributions and the like, but is rather traditional software development conducted in transparent fashion. Working environments, defect tracking, and interim builds will all apparently be made available publically. Candidly, I was slightly less underwhelmed by this news than were some of the other attendees, but that’s at least partially attributable to the amount of time I spend tracking actual open source projects. So while it’s not open source, it’s potentially an interesting half way model for other commercial software development organizations to keep track of. For those that are wondering how they open source community will react to it, my expectation is that they will not be tremendously impressed. You might speak with the folks from Ubuntu about the questions they feel about Launchpad – I expect you’ll field at least some of the same.
If you’re a developer, and are eagerly anticipating a day when you can get your hands on some of the bits, I’ve got some bad news for you: you’re going to have to wait a while. A long while, in all probability. The interim builds might satisfy your curiosity temporarily, but the real thing is years away, not months. Despite the unfortunate waiting period, I think this is a technology to watch. Much will depend on how open they can make it, but if the demo was any indication it would seem that Jazz might be an ideal way to solve the ISV problem described above.
