Last night I had a chance to attend a Jazz demonstration by John Wiegand at CASCON 07. It is always a treat to watch John speak and yesterday’s session was no different. For those who have not seen John and Erich speak about collaborative development, here is a short video to one of their previous videos talking about open source development.

John gave a glimpse of the current state of Jazz technology. Although Erich was unable to join the demonstration concurrently from OOPSLA in Montreal as planned, judging from the reaction of the standing room only audience the session was well received. There are several cool things that were shown including the concept of personal work spaces that amongst other things let developers see the effects of checkins before touching the main code repository. John ran through a scenario in which two new developers join an existing project. The system configured the tool behavior for these newcomers based on the process definition. Living up to the promise of transparency, these newcomer developers get access to all work items in their project and across different projects. They then get down to the brass tracks by working on their own work items while engaging in adhoc collaboration and sharing changes with others in the team.

I had a chance to chat with John after the demonstration. Since my focus was primarily on understanding the process awareness built into this integrated toolset, John was quick to point out their definition of process in Jazz. Process in Jazz means the policy and configuration settings that govern tool behavior. The process definition such as checkin polices and build management can be customized for individual projects. We then had a candid discussion on the need to have balance between having a process definition that spawns project work items without burdening developers with complicated process terminology. I can’t go onto all the details here but we agreed that over-complicated process models (based on over-engineered meta-models that require a steep learning curve) could be harmful to the concept of collaborative development environments. This is the reason the Jazz team wants to be very careful when they talk about process and their definition of it.

John was also generous to help me with a favour. He has promised to see how can he make the EclipseWay available to the open source community. This will mean anyone can take this collection of best practices and mash them up with their own in-house process description or third party process definitions without getting a knock on their door by a team of IBM lawyers. I know many people in the EPF community had been asking for such a thing and will join me in thanking John for helping us with this.

I am back at CASCON on Thursday to join a BOF session on Jazz.

This entry was posted on Wednesday, October 24th, 2007 at 2:20 pm and is filed under General, The state of the art. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.