When IBM Distinguished Engineer Erich Gamma was helping create what would become the Eclipse development framework, he came face-to-virtual-face with what would now be called global software development. "We never had the luck to all sit together in the same time zone," Gamma told an audience at JavaOne 2006. "So we would always be globally distributed. So we had no choice but to stay in our favorite hometowns and do cool stuff." Gamma's latest project, Jazz, addresses just such a scenario. Co-developed by IBM Rational and IBM Research Labs, Jazz is a work-in-progress collaborative development environment scheduled to debut in 2008.

For Gamma, the name "Jazz" is fortuitous. Like Miles Davis, Gamma has brought out different facets of his talent by collaborating with different people along the way. Gamma's career began back in 1988, when he was one of the "gang of four" authors of the now-famous book: "Design Patterns, Elements of Reusable Object-Oriented Software," which is based in part on Gamma's Ph.D. thesis. "The Design Patterns book is the most popular computer book ever published, with over one million copies in print," wrote Ed Burnette on his ZDNet blog. "It established a vocabulary for talking about recurring themes in software, allowing developers to conceptualize, share, and expand on existing best practices."

In 1997 while on a flight from Zurich to Atlanta, Gamma and his friend Kent Beck came up with the idea that would turn into the JUnit regression testing framework, which is now an open source project administered at JUnit.org. Gamma later joined the Zurich-based company Object Technology International, which was acquired by IBM, where he was the original lead of the Eclipse Java Development Tools subproject. Burnette calls the resulting Eclipse platform source code "a real treat," in which "design patterns permeate the code, lending an elegant power to concepts like plug-ins and adapters. All of this is backed up by tens of thousands of unit tests. It's a superb example of state of the art object oriented design, and Erich played a big part in its creation." Gamma serves on the Eclipse Project Management Committee and, along with Beck, wrote the book "Contributing to Eclipse: Principles, Patterns, and Plug-ins."

With Jazz, Gamma is back working collaboratively on a closed-source project. In the Jazz world, development projects are segmented into "artifacts"-change requests, project updates, project scheduling details, models, and source code-which are then managed throughout the lifecycle through real-time reports. The idea: if you understand the current state of the details, you'll understand the overall "health" of the project. Like Eclipse, Jazz is being used to build itself.

We spoke by phone while Gamma was just leaving the U.S. to fly home to Zurich.

Let's start with your experience in creating Eclipse. What did you learn that has helped you now that you are working on Jazz?

On the technical side Eclipse illustrates the power of modularity and extensibility. In Eclipse, everything is a plug-in and you can teach Eclipse new behavior by adding plug-ins. We want to preserve the power of this approach in Jazz. We do this by leveraging the Eclipse support for modularity provided by its underlying OSGi run-time in Jazz. While doing the technical work, we learned something else: how to grow and appreciate the interactions with an active community. That in itself turned out to be an important lesson.

This may seem obvious, but what you would like to get from a community is feedback. To enable and motivate feedback, there are two key ingredients. First you have to be transparent about what you are doing and second you have to demonstrate continuous progress so that you get continuous feedback. Continuous feedback throughout a release cycle has always helped us to stay honest and let us know if we are building the right thing. The "Eclipse way," that is, the practices we are using, are not only about building software but also about growing a community around a software development effort.

Community input really helped tell us what we should build. The community isn't shy-it is actually quite demanding.

Is that why Eclipse has particularly caught on with Java developers?

Eclipse is implemented in Java, and, being our own tool smiths, we obviously wanted to build the best tools for us. But yes, thanks to the highly demanding community, the Java development tools have become even better. It took us some time to accept that not all ideas have to come from us. That's a good lesson. Combining the good ideas from a demanding community with our own ideas helped us to get something even cooler.

Was Eclipse originally developed as an open source project?

No. Development on Eclipse started in 1998. IBM needed to have a common platform for tools to avoid having the same basic functionality built over and over again, which made both the developers and users unhappy. Then in 2000 it became obvious that we could not build all these tools ourselves. To enable an ecosystem, it was decided to make Eclipse open source. It was good timing because, by that point, we had come up with something interesting enough to be worthwhile. If you give people a Christmas present, you want to include the batteries-and by 2001, Eclipse was a gift worthy of being opened.

When did Jazz come about, and why?

The Jazz vision and project started about two years ago, but there already was a Jazz research project four years ago. This project was about adding synchronous collaboration-instant messaging-to Eclipse. We liked the focus on collaboration from this project, and we also liked the metaphor of a Jazz band playing together in harmony.

We asked ourselves how we could leverage all this experience with Eclipse. So we started to work on Jazz as an extensible team collaboration platform for seamlessly integrating tools and tasks across the software lifecycle.

So you wanted to move from the individual developer to the team.

Yes. The focus of Eclipse was on productivity of the individual-on producing code quickly. With Jazz, we want to move to a platform which focuses on the productivity of teams, and of teams of teams. We want to help people to work together more efficiently. The goal is not only to produce code quickly but to deliver a software product developed by a team.

This is really a dream project for me, because as tool smiths, we are always asking ourselves the question: what kind of tools would make us more productive and make software development even more fun. Being a tool smith for team tools is a really interesting challenge.

Does Jazz resemble Eclipse in that it is centered on software developers?

Obviously the developer plays an important role in a software development team, but Jazz builds on top of Eclipse and is intended to be a platform where lots of interesting tools for different roles can be built. For example, we are also exploring tools for requirements gathering. Another idea is that Jazz understands the process a team is using and that teams can define the rules they want to follow. This process awareness also helps the team and project leaders. Another goal is to encourage pervasive transparency. That is, everybody should know what is going on without having to ask. This is beneficial to all roles involved in a project.

What happened in the years since Eclipse was introduced that has made team collaboration more important?

Software development always was a team sport. With Jazz we want to take a fresh look at how we can help teams to be even more effective. At the same time, globally distributed development has become more important as well as governance-who can make what decisions and who is accountable for outcomes. The Eclipse project itself is a good example of all this. First it was developed by a globally distributed team and second, it has well defined rules of governance spelled in out in the project's charter.

You guys use the term "governance" a lot. What does it mean?

"Governance" is actually not one of my favorite terms. In fact, I try to avoid it. Who wants to be governed-I don't. But to me, governance in software development is about the mechanisms you follow to achieve more transparency-about how you are going about doing what you are doing. This increased transparency, in turn, leads to more accountability. And accountability leads to responsibility for what you are doing as a software developer. As I mentioned, Eclipse is a good example of this. Using the jazz metaphor again, only a jazz band where all band members know what the others are doing can play in harmony.

Governance also means transparency about how a team works, and the process that the team follows. Our idea with Jazz is that a common platform can make it much easier for a team to follow and comply with a particular process. Jazz is "process-aware." It knows which process the team would like to follow, and even better, it helps you follow the process. For example, say the process requires that before you deliver a change to a source file, you have to run a specified set of tests. In Jazz, you can express such a rule and Jazz will not only alert you when you violate the rule, it will also offer assistance to comply with the rule by offering "quick fixes." So in my example, Jazz offers to run the specified set of tests if you haven't done so already.

But hasn't this kind of change management for large development projects been around for a long time.

You're right, but Jazz is not just about change management. Change management is an important facilitator for team collaboration, but there is more. With Jazz, we want to manage all kind of artifacts in a common repository and have rich support to collaborate on these artifacts, know about when and how they change, link them, etc. Therefore integration of different tools is a key theme of Jazz. Eclipse has addressed a similar integration problem on the desktop. Before Eclipse, there were many different development tools, which were not integrated. Eclipse provided a common platform which enabled seamless integration of tools on the desktop.

We have the same idea with Jazz; only here we are moving a level up, looking at the integration of software lifecycle tools. This not only has to cover the desktop, but the server side. And when you build on a common platform, you get interesting synergies. You get traceability through the linking of artifacts. You can collect data as the team progresses and generate interesting project health reports. So Jazz is really a platform for building collaborative software lifecycle tools.

What are the underlying technologies?

First of all, Jazz consists of a client and a server. On the client side, we leverage Eclipse itself, and on the server side, surprisingly, we also leverage Eclipse, but only its modularity mechanism. Also on the server we support two different technology stacks: an open source stack and an enterprise stack. The idea is that as you scale up, you'll want to shift to more enterprise level infrastructure. The open source stack consists of the Apache Derby relational database and Tomcat as the application server. The enterprise level counterpart is DB2 paired with IBM WebSphere.

Will Jazz run strictly as a client-based app using Eclipse, or also via the browser?

Actually, Jazz will support many different clients. Eclipse is an important one for developers that live and breathe in Eclipse. However, we also provide Web access via an Ajax interface to the repository-so you don't need to have Eclipse installed to get at information in the Jazz repository.

What sorts of projects do you see Jazz as ideal for? Are you thinking international collaboration within a huge corporation, or smaller projects as well?

Scalability is an important theme for us both when it comes to performance and the development process used. To achieve scalability in terms of performance, we support both an enterprise and an open source technology stack, as I mentioned. The Jazz vision is to scale from small agile teams up to high ceremony [i.e. more formally structured] enterprise processes. To do so, Jazz allows you to associate your project with a particular process that will then define how the tools behave. Of course, the Jazz technology is still young and we do not have proof of the full coverage yet. But we are working hard to make this vision real.

Would Jazz benefit a workgroup of two?

Definitely. As soon as you have to collaborate, then I think Jazz gives you value. For example, when I worked with Kent Beck on JUnit I would have loved to use Jazz.

Where is Jazz now in development?

We are strong believers in "consume your own output" or "eat your own chocolate." We started out by defining the components, and as components matured, we then gradually adopted one after the other for our own use. And right now, I can say that we are self-hosting on Jazz, that is, we use the Jazz bug tracking system, continuous build system, source code control, reporting, and the supporting collaboration infrastructure like RSS feeds and chat integration. We have also started some internal pilot projects, and our partners have access to our development work. Throughout the year, we will open up the internal pilot. Going forward into 2008, the first Jazz-based products will be available.

Is this an international development effort?

Yes. The Jazz team itself is a globally distributed team. We are about 50 developers working from seven different sites. We have sites in the U.S., Canada, Switzerland, France, and, at times, India.

Is it open source or closed source?

Jazz is a commercial effort. We are thinking about open sourcing some of the core framework, but we haven't decided where this line is. As I mentioned, we are using open source practices to develop Jazz. We call this Open Commercial Software Development.

There's been some concern on the Web from Eclipse users about where IBM is going with this project. They worry that IBM will put its resources into developing Jazz, while ignoring Eclipse.

We are still strongly interested in Eclipse; it is just too important to us. We are building both the client and the server on top of Eclipse. While it is true that some IBM Eclipse developers are now focusing on Jazz, there is still a strong team working on Eclipse and new developers have joined the effort. In addition, I'm also convinced that Jazz helps to improve Eclipse-Jazz imposes new interesting requirements that help to improve Eclipse, and sometimes these enhancements are also contributed by developers from the Jazz team. That said, at the Eclipse development level, we are always interested in getting others to help us on the platform and to increase the diversity. That's an ongoing desire that is naturally growing over time. The more successful Eclipse becomes as a platform, the more products are built on top of it and the more users will use it. This leads to an increased maintenance load.

But is IBM is still committed to Eclipse?

Absolutely. IBM has over 200 products shipping on top of Eclipse. There are on the order of 70 Eclipse projects, and IBM contributes to more than half of these projects. In fact, the number of active committers has increased from 2006 to 2007.

Any thoughts about Eclipse and Jazz in Japan?

Eclipse is translated into 60 or so languages, including Japanese. So I hope that Eclipse is as intensively used in Japan as in the rest of the world. I got invited several times to talk about Eclipse in Japan, but it has never worked out. I really hope to touch bases with the Eclipse community in Japan sometime in the future.

How does your background with design patterns and JUnit tie into your work on Jazz?

I can spin it as a natural progression along the lines of improving the way we develop software. I guess the first thing I thought about is: what's the most important thing needed to succeed in software development. The answer is: you have to have good design; design is everything-that's step one. So I began to understand what are good designs, and from there came design patterns. But realistically, good design isn't enough. Your stuff should also work. Kent Beck then opened my eyes with regard to unit testing, and that's where JUnit came along. Software developers need good tools and I always worked on IDEs [integrated development environments] and development tools. That's how Eclipse came along: it was another dream project for me because I have worked on several IDEs, and it was my hope to finally get it right. Of course when you tell stories about yourself, you always make it more beautiful, more interesting. So keep that in mind.

So what is the next big thing in successful software development? My answer is making teams more effective. So that was the natural next step.

And possibly the toughest. Dealing with people is always harder than dealing with code.

It's true, this is a challenging project, but we are realistic and understand that software is built by people and not all people problems can be addressed by tools.