Erich Gamma: Actually, I guess this was kind of our story on how we evolved from closed to be open and, of course, we hope this will go on, right? As we learn to be more open, we want to apply this to more and more things.
So now we'd like to bring on two leaders who are directing the development of our commercial products on stage to show how open source strategies we just talked about are being leveraged in Rational's strategy and product roadmap, and join me in welcoming Lee Nackman and Martin Nally.
Lee Nackman: Good morning. I'm Lee.
Martin Nally: And I'm Martin. So Lee and I want to carry on from where John and Eric left off and give you a brief overall of the Rational® strategy and roadmap and relate it back to some of the themes that John and Erich described.
Nackman: So we're going to talk first about innovation and processes and their governance. We're going to try to talk to you about how we've tried to take some of the lessons that we've learned from the Eclipse experience together with some of the important business drivers that are happening and how that's affecting Rational and the direction that we're taking. Then we're going to talk about what we've been doing in Version 7, the enhancements we've made in the Rational products to better support governance and to take advantage of some of these lessons. And then finally we'll move to looking into the future. We'll talk a little bit about where we're going in Version 8, and we'll talk about some new platform work that we're doing.
So I think that if you look at open source in general, as a whole, there's certainly fabulous technologies coming out of open source, but I think the great lesson of open source as a whole, the genius of open source, is really this innovation and process and in governance. And some of the processes in open source are a natural evolution of things that we've seen in the past -- the spiral method, the unified process, agile methods. The thing that to me really has made a sea change is this idea of transparency of publishing the whole development infrastructure on the Internet and exposing this to a much larger community and, in fact, blurring the distinction between the user community and the development community.
And in reaction to this, the open source communities have been put in place, or the best open source communities, have put in place significant innovations in governance and process to manage these new communities.
So you hear this governance word a lot, and this is the formal definition of governance that we use. You might have seen this in some of the other presentations that you've attended during the sessions yesterday and Sunday.
I think there are two very important words in these definitions, and those are empower and enable because governance is really about empowering people and enabling people to do their work in a better way. It's not about the pointy-haired manager counting your keystrokes or anything like that.
In fact, if you look at the way that open source really works, open source is not a free-for-all. The successful open source efforts have a very strong governance model. And so I've listed here some of the governance techniques from Apache. Erich and John talked about committers. This is control about who has the right to access, to modify the code. And how the committers come together to make decisions about projects. It's policies like "How are we going to do licensing for the open source projects?" That's a governance issue. It's issues about "How are we going to make decisions with the consensus based process, rather than a very hierarchical process?"
So the point is that the successful open source efforts have strong governance models, and they enable the developers, they enable the people who are using the governance mechanisms, to make good decisions by a specified set of processes.
Nally: And so good governance and process has to cover a range of things. Erich and John focused I think mostly on how development and test works in a community. But there are a number of other higher-order kind of issues that have to be addressed.
And one example is how are projects started and stopped. Who has the authority to do that kind of thing? And how do you achieve architectural consistency if you're managing a group of projects together and perhaps have a common release date? And then how do you achieve that kind of architectural integrity? And how do you plan, especially if planning has to cover a number of related projects or components that contribute into the same project? And how do you manage an overall requirement's process again, particularly if you have a suite of projects?
And Eclipse has a set of innovations in its structures and its processes and its governance over and above the Apache model to cover some of this.
Nackman: So, have you ever been part of a project that's gone through an audit? Was it a good experience or not? Or were you feeling like Charlie Chaplin here, kind of like a cog in the audit machine, if you will.
We think that effective governance has to be done in a way that provides value for your day-to-day activities. The keys are that it's part of the process. It's not something that's outside of your development process. Another key is that much of the governance can be automated. Information that supports decision-making is captured as part of what you do as a developer or as an analyst. It's part of your day-to-day kind of role. And you have appropriate mechanisms that give you feedback that help you make the right sorts of decisions.
So effective governance is not about, you know, an onerous process. It's about being more effective in your day-to-day activities so that when you do have audits, it's a smooth thing, that your projects are successful. As John and Erich talked about, the thing that makes developers happy is shipping, and good governance is all about being part of projects that ship and ship reliably.
Nally: So the visible successes of open source, in particularly of Eclipse as John and Erich described, are great motivators for taking a look at process and governance. And also I would point out that you have to believe that this is an enjoyable experience for many people in open source since for many of them, this is not their day jobs. For many of them this is their passion.
And in addition to those motivations, we see other business drivers that are motivating people to put more emphasis on process and governance. One of them is this issue of strategic alignment -- how in an enterprise, how can I show that my investments in IT are bringing real value to my business? And, in fact, one of the interesting differences between open source development and commercial sort of enterprise-level development is the notion of financial measures and financial accountability, and we don't just leave it to volunteers voting with their time and we actually do resource allocation.
Another major driver, Danny referred to this in his keynote speech yesterday -- geographical distribution is an important thing. And this takes several forms in the form of offshoring, in the form of outsourcing, or in the form of companies around the globe integrating their value chains and supply chains. And Danny also talked about compliance. Compliance is a reality in almost all industries and, in fact, most industries have to comply with many regulations simultaneously.
This notion of flexibility is very important. Danny challenged us to raise the rate at which we can evolve software and improve software, and businesses are looking to be able to evolve their IT systems and to be able to keep up with their need to change in business.
One of the things that people are looking at for this kind of flexibility is service-oriented architectures, and service orientation -- that would be a whole talk unto itself. But one of the interesting things about services is that services are shared property. And whenever you have shared property, like our road systems or the Internet, you need good mechanisms for managing that, governing that.
Nackman: So this is really what we're after: enabling organizations to govern the business process of software and systems development. You've probably heard Roger say that phrase a number of times during the course of the conference. But I think there's some very important words here.
I want to start at the end of the phrase, with software and systems development. So Rational is about helping to develop to develop software, helping organizations to develop software and also to help organizations to develop systems that incorporate software. Many, many of the products that you all produce are not just software. They are systems that incorporate software, and that's a very important part of what Rational wants to help you do.
Another key phrase here is the business process of software and systems and development. Danny talked about the creation of supply chains and software development, systems development -- they are essential business processes just like any other business process that an organization has. And like any process, one of the things that you want to do is to improve that process over time. You want to take feedback and you want to do better and better over time.
So Rational is about helping organizations apply governance in the positive sense of the word governance to improving the business process that they use for developing their software and developing systems that incorporate software.
Nally: So Rational has long recognized the importance of process. In fact the Rational Unified Process is one of the things that Rational is known for and famous for. We're also extremely interested in taking the newer lessons from open source and making those available, applying them, learning how to use those in our product suites and bring that value to our customers.
One way that we're bringing both of these thoughts together is with the Eclipse process framework, and we've donated some process technology to the community, and we're working within the Eclipse community to evolve both the content and the tools for that process. So recognizing the value of what John and Erich described in terms of best practice processes, and governance and transparency, is an extremely important step.
But taking those lessons and applying them even to one project and, more difficult still, across multiple projects is truly an organizational transformation. And that's very, very difficult thing to achieve and very illusive thing to achieve.
And Rational is trying to help bring in support to people who are doing this within their organizations by continuing to provide documentation of best practices and continuing to provide the kinds of tools that allow people to take those best practices processes and to tailor them to their environments. As we saw even with open source there are differences, there are cultural differences and historical differences within organizations that require you to tailor those kinds of things. And we continue to integrate process guidance and process support more tightly within our tools.
And, of course, we have a strong services organization. So you know we don't just have John and Erich here; we have a world-famous services organization, and this specializes in bringing support to organizations to make these kind of process transformations.
Nackman: Another important aspect of doing governance in the enterprise is looking at the bigger picture, looking at a whole portfolio of projects. And how do you align the projects that you're choosing to work on with your business strategy? Because, after all, what you're really trying to do is to deliver value to your business.
So there's the whole question of what kind of information do you use to make decisions about starting and stopping projects? It's a combination of what kind of return do you expect from these projects? What kind of risks are associated with the project? Because there's a balancing that you have to do between return and risk. How do you allocate your finite resources? You have a finite amount of money you can spend. You have a finite number of people with the right skills. How do you make those allocations? How do you understand what kind of business return you're getting on your investment? And how you look at the health of the project as a way of feeding into your understanding of risk.
So a very important part of what Rational is doing is tools like the Rational Portfolio Manager to help you make these higher-level balancing and trade off decisions that you need to do in the enterprise.
Nally: So the way that Rational brings value or the way IBM brings value to our customers is through the products that we sell and the services that we sell. And the products that we sell are around the software development platform. So if we look at what are the desirable characteristics of the software development platform in order to deliver value in this way, and so certainly having a broad set of tools that cover the roles across the whole software development lifecycle is a very important thing.
But the way that we tie those tools together and enable team collaboration process and governance is really the key to providing value above these point tools. The key parts of that integration include tools to support process automation. So automation of manual processes is an extremely important part of how you achieve that collaboration and how you achieve the governance and the auditability surrounding that.
Another key area is the data artifacts themselves. When you go through software development, you build up a very rich set of data, and there's a very rich set of linkages between those data. And you want to be able to carry that all the way from business policies and goals and requirements through the architecture and coding phases all the way to test and deployment. And you want to be able to link those things, so I know which tests test which requirements, which test cases were run producing which test results on which test cycles, those kind of things.
And finally, transparency rests on being able to mine real information out of the data. So having good query and analytics capabilities and good reporting on that rich data set is part of the way that you achieve this transparency, as well as part of the way that you support collaboration.
Nackman: So what we'd like to do now is to talk to you about the enhancements that we've made in Version 7 of IBM Rational's governance platform, basically to improve the ability of the products to support the kind of governance that we've been talking about.
So the challenge really is this historical challenge that development organizations and build organizations and deployment organizations and testing organizations historically they've been separated and they have walls between them. Virtual walls between them. And people use very manual processes to go from one organization across the wall to the other organization. Those manual processes are labor intensive and they're also error-prone.
So a big goal that we had for Version 7 was to start to punch through those walls, knock those walls down and automate the transfer across those different roles in the development organization. So if you look in a little bit more detail, you see different people in different roles working with source code, working with build scripts, working with test environments. And in the typical kind of development cycle, you see these kinds of problems. Why am I the last one to know that the build broke? Why don't I automatically get that information? How am I going to get some testing done if you guys in the build team can't get the builds to work? So these are the kinds of problems that people deal with that our products can help overcome.
Nally: So what would the solution to this problem look like? What would be the desirable characteristics? The first thing is you would like the overall process to be transparent and well documented. You don't want it to be captured in a bunch of arcane scripts. You want to be able to see clearly what's going on. And you want to have support for each one of the roles in that process, and good handoffs, automated handoffs, of the communication and the data between them.
The other thing that you want going back to our platform here is you want the information. You want the activities to produce the results to have those results recorded to be able to record the history of those and to be able to record the linkages between the different artifacts that are produced in this process.
Nackman: So in Version 7 we've taken a number of big steps forward. First of all, one of the capabilities that we were missing across this whole spectrum was the ability to manage builds, manage and automate builds, get feedback from the builds. And as you may know, we acquired BuildForge in May, and BuildForge is now part of the Rational Software Development Platform, and it's a key part to the whole end-to-end life cycle. Another major step forward in this release is the introduction of build records. So information about builds, into ClearQuest, and the ability to connect together those build records with information about deployment.
So we have deployment records also introduced into ClearQuest, and these are linked together. An additional capability is test management integrated into ClearQuest. So you have information about test cases, test scripts, the results of running test cases, put together into ClearQuest. All of these things are linked together within ClearQuest.
And optionally, you can feed the deployment information that you build up in ClearQuest into the IBM® Tivoli® Provisioning Manager and that can take your code, your builds, rather, and provision those builds onto various kinds of servers that you can use either in test environments or in preproduction or production.
Now, another important aspect of this that we've been talking about is compliance with various regulations. A key part of compliance tends to be capturing approval. Who decided that this code was ready to be deployed into the production server? Well, since all of this is managed by ClearQuest you can take advantage of the electronic signature capability of ClearQuest to capture an audit trail for essentially no work just by capturing the electronic signature of whoever does the approval.
So what we've done in Version 7 is we've brought together within ClearQuest a linkage between the artifacts that you manage across the whole life cycle.
Nally: And so another challenge that we've improved our support for in Version 7 is that of geographic distribution. So key challenges in this area are performance over wide area network, tools deployment costs and manageability remote manageability of tools, and language support, both support for people in other geographies, but also how you coordinate the language issues and when you have people working in different, in geographies that have different languages. And then the whole business of team communication and visibility. Visibility of the information and artifacts.
Nackman: So part of the solution to the challenges of the geographic distribution are improvements that we've made in the various clients. So we've improved the scalability and the functionality of the Rational ClearQuest remote client. We've improved the performance, scalability of ClearCase Web, as well as enhance the functionality of ClearQuest Web. And the same thing with RequisitePro Web. So in general, we've made significant improvements to our remote capabilities with both the remote client for ClearCase and the Web clients for ClearQuest and RequisitePro.
Nally: So another area we've made improvements is around the support for language. ClearQuest now has parity with ClearCase, supporting all the group one languages sort of the nine sort of major languages. And ClearQuest is also better positioned to support teams that work with mixed locales. And so you can now set up teams using their own locales. Collaborative teams that are collaborating together, where each one has a different locale. In this release you'll pick a particular code page for the database. And so, for example, if you had a Sino American team you might pick Latin one as being the common code page for the database that allows people to share data. In a future release, we'll allow you to support Unicode, thereby allowing the Chinese team to put information in there that the American team can read thereby improving collaboration and cooperation.
New translations are available. The Rational ClearCase client is available in simplified Chinese. And the Rational ClearCase for Microsoft® Studio as well as all the Eclipse-based Rational, Rational ClearCase clients are supporting the Group One languages, the nine Group One languages.
Nackman: A very important part of what we've done here is we've started to unify the process infrastructure. The traceability across the life cycle is now based on ClearQuest. So the whole life-cycle work flow is tied together across the multiple roles using ClearQuest. What this does is it gives us a number of benefits. We take advantage of the ClearQuest multisite capability for global support. We get the globalization that Martin was just talking about. It scales to large teams. And you have fewer repositories. You have a single repository where you capture all of these linkages.
Nally: And so one thing that John and Erich talked about was their own internal deployments. And so we also, we are one of the heaviest users. We have heavy internal usage of both ClearCase and ClearQuest around the globe. And we've been using our own internal betas and release candidates for several months now in an attempt not only to harden our own stuff and to improve the quality that we deliver finally to our customers.
Nackman: There will be additional enhancements to the Version 7 products coming in the fourth quarter focused on design and construction and software quality. We will move up to Eclipse V3.2 and JDK V5 support, the latest WebSphere® versions.
We will be changing our componentization, we'll be improving our componentization as Danny talked about getting a finer granularity in the products. And we'll be able to take advantage of that in providing a much more flexible install capability that will allow you to choose from amongst some of the finer-grain components what you install. This will help address some of the footprint issues that people have talked to us about.
There will be further improvements in your ability to deploy the products to your practitioner's desktops. You'll be able to make choices about which components get deployed to people in different roles. We'll also be making further enhancements in our model driven development model-driven architecture and support and introducing SAP support in the Rational Functional Tester.
There's lots of information available about Version 7. You can see it in action in various places throughout the conference. There was a lot of it yesterday and more available in the solution workshop and technical workshops, there's a lot of partner solutions available on Version 7. So we encourage you to take advantage of the solution center demos, the Birds of Feather session, etc.
Nally: So we'd like to change gears a little bit at this point and talk a little bit about longer-term futures. So we want to talk about beyond Version 7 and what are we planning for the rest of 2006 and 2007, and even beyond. An important thing here is, like most successful innovative companies, Rational invests on multiple time horizons. And the bulk of our development resources go to this sort of continued improvement and enhancements of the technologies that we have. But we also have significant investment in innovative new technologies that we believe may form the core of our products in a longer-term horizon, perhaps the two- to five-year horizon. So we'll talk a little bit about both of those.
Starting first with Version 8, which is our evolution, how we take our current product suite and improve and evolve it. We're not here today to talk about features that we're going to deliver. But we can talk to you about some of the major themes that we think will form the basis for defining those features. One of them is further improvements of the life-cycle management. So this is better integrations between the products, as well as widening the scope of the products, continuing to work more with our Tivoli organization to extend into deployment.
And another one is continuing to improve our support for global development, including improving WAN performance and bringing all the Web based clients up to full functional parody with the native clients. And also bringing the Eclipse plug-in, the RCP, both RCP and Eclipse plug-in clients up to parity with their native counterparts. And generally improving Web infrastructure.
The motivations for improving Web infrastructure are multiple. One of them relates to security and better support for LDAP, etc. And a more consistent approach to Web infrastructure and security across our team based products.
Consumability remains a huge focus. Consumability has a number of aspects, goes from everything ease of use, installation, administration, performance, these are all aspects of consumability. And finally total cost of ownership is something that we continue to hear from you as a priority and that we continue to invest in.
Nackman: As Martin said, in addition to our substantial investment in moving forward to Version 8, one of the things that we're doing is we're starting to take a look at if you were to start with the ability to take advantage of all the new Internet technologies and put together a new architectural approach for supporting governance across the life cycle, what would you do? And so we've been working for a little while on something that we call Jazz, and you can take Roger's metaphor and apply all that to the choice of the name Jazz. So we've started working on a new architectural approach that's driven by the notion of let's simplify by being more consistent across the lifecycle. We want to focus on improving productivity of distributed teams.
We want to take advantage of Internet technologies like instant messaging and RSS feeds and wikis, all kinds of capabilities that now exist for forming collaborative communities. We want to foster the construction of communities in your organizations. We also want to have what we call scalable consumability, where you can start small and scale to the largest possible team sizes in large enterprises. So these are some of the motivations for what we're doing in the work on Jazz.
Nally: So this is talking a little bit about the scope of Jazz. So our history within Rational is building out a governance platform starting with the best-of-breed tools we have, most of them leaders in their segment, and building integrations that allow this to be built out into a whole platform. Jazz is taking the opposite approach of and thinking about integration and life-cycle integration process and governance, and from the beginning and building up to that, building up from that and building out to the actual tools.
And so what are the key -- so one important thing here is the separation between the platform and the actual product. So we intend to deliver two things here. One is a fundamental platform that enables the kind of support for collaboration process and governance that's so important to us. And then to deliver a set of products hosted on top of that platform that create the function in the particular roles, the particular life-cycle roles of support for, and support for processes for those practitioners in those roles.
Key technical capabilities of the platform includes the ability to create an artifact, an overall data model, an overall information management system where you can store artifacts and where you can store the links between artifacts and where your full history and versioning available for all kinds of artifacts in one integrated model. And then to support rich searching and reporting on top of that to give the kind of transparency and traceability, which are the things that we value.
And process automation is another thing. You know, from building out our current platform, we've learned that this artifact storage and then process automation on top of that is a key way to bring value to enable this process and governance. And also building guidance, process guidance and process customization and definition into the platform. And integrating the build. So we talked about the importance of rapid iteration and transparency. So integrating build tightly into the platform is important. And project health, being able to trace what's happening in the build, what's happening in defect trends and so on. And requirements and tests are key control points in the overall process and built directly into the platform. And the ability to do project planning.
On top of that, we would expect to build out a rich set of tools hosted on the platform that cover the major roles and the roles that we're looking at initially cover the analysts, architects, developer tests and deployer. This gives a little diagram. It's important to have an architectural diagram here. It's very traditional. As Lee said, so a couple of key points here. First of all, Jazz covers both client side and server side.
On the server side, it will have an extensibility mechanism analogous to the one that we have in Eclipse today. So an idea of having a platform with a well-defined extensibility architecture and integrated into this is support for some of the modern and innovative collaboration techniques that have grown out of the Internet.
So we have the Internet as a backbone enabling this kind of collaboration. But we also have things like wikis, blogs, instant messaging which I guess predates the Internet but has been significantly popularized by the Internet, RSS feeds and so on. Exploiting all the modern infrastructure of the Net. We expect this to be scalable from a lower-end solution based on standards, open source middleware infrastructure, scaling up to the highest-end middleware, provided by IBM through our WebSphere, DB2® and Lotus® divisions. Integrating with full Lotus Workplace capability at the high end.
And so this is the sort of general, sort of scope and ambition of the platform part.
Nackman: Another very important part of what we want to do with Jazz is to establish an ecosystem around it. It’s very important to us that as we build out this platform that we establish key standards and de-facto standards so that we can have a large ecosystem not only with Rational and IBM but with other vendors throughout the industry. So what we intend to do is we certainly are going to build on top of Eclipse and other open technologies. We're going to take the core infrastructure of Jazz and make that open source to help foster growth of the community around that core infrastructure.
And then Rational will build products, commercial products, on top of that core open sourced infrastructure, and we expect that there will be other Jazz-based tools and frameworks that are produced by third parties, by customers, etc. And, of course, we want to have an ecosystem of partners who are able to augment and provide additional capabilities to our products and to the platform.
Now, we talked quite a bit -- John and Erich talked quite a bit -- about the benefits of transparency. So one of the things that we want to do is we want to get those benefits in the commercial software that we develop on top of Jazz. So we're going to do two things. One of them, as I said, is we're going to open source the core infrastructure to establish those standards, and then we're going to develop the Rational products on top of that in a way we call open commercial development. What that means is we're going to do the kinds of things that John and Erich talked about to get transparency with our commercial products. So customers will be able to participate in providing the kind of feedback loop that leads to the high quality software that we've seen from Eclipse.
So we think this is a very important innovation in the development of commercial software, this complete transparency that we're going to use as we develop the products on top of Jazz.
Nally: As I said, Jazz is innovative and exploratory technology. We don't want to leave you with the impression that Jazz is a product you can buy today. And Jazz is something in the further out future. Nevertheless, Jazz is being developed in the open iterative style that we've described and espoused. So there's very interesting technology already demonstrable in Jazz. And so to communicate some of this we've set up a buff, those that are interested tonight at 7:30, John and Erich and we'll be leading a buff where we'll demonstrate the current state of the technology. And I think this is a very spectacular demo. And I think it will give you a flavor of where we expect and hope that this will go in the future.
Nackman: So to summarize, we think that good governance is a really important part of bringing business advantage to development organizations. Good governance is an empowering thing. It enables the practitioners. But to really be effective, good governance has to be part of process that's part of your day-to-day culture. It's not something extra, it's part of the way you live, the way you do your development.
And the key enabler for this is the kind of process automation and the information that we've been working to integrate into our productivity tools in the Version 7 release. As Martin said, we're investing heavily to continue to evolve the products that you're using to make them better and better every release. We are also investing heavily in the technology revolution to take advantage of the new capabilities that have been brought to us in the Internet world. So it's a good combination of driving forward in the evolutionary way that's so essential but also in creating new capabilities and new technologies that are important to our continued future.
So we've had some folks backstage collecting questions that you've been texting in e-mail. I'd like to ask John and Erich to come back up and help us answer questions. I'd also like to ask Bill Philbin and Beth Friday to come up to participate in the panel. Bill is our VP of engineering. He's responsible for getting all those bits shipped. Shipping, Bill? And Beth is responsible for customer support. So please come on up, all four of you, and join us in the panel session.
So open source. Let me start with this one because I think there are really two issues. One of the issues is the incorporation of open source into commercial products. So we do this all the time. Lots of our products in IBM incorporate open source technology. Again, this is a governance issue. How do you decide when an open source project is managing the intellectual property issues well enough that you can incorporate that technology into a commercial product?
Well, in IBM we have something we call the open source Steering Committee. We have a whole set of processes, where we have experts in intellectual property (we have lots of lawyers in IBM) -- we have these people who help us go through and understand the characteristics of the open source technology that we want to incorporate in our products to make sure that it really does pass muster. So the other part, of course, is as people contribute to open source projects, you know, how do the open source projects themselves decide whether to accept that code. So maybe John you could talk a little bit about that.
John Wiegand: There's a few things that come to mind here. The first is all the committers on a open source project, Eclipse in particular, sign a committer agreement so that they understand what it means to make contributions, so they do the right things in their day-to-day development. But the next thing that happens in open source projects is you leverage other technologies and other components. But we don't want that to happen in an uncontrolled way.
So, Eclipse has established an IP process and a policy that's basically applied. So our team, we'll look at the Eclipse platform team, if we're interested in tapping into some new technology, let's say a new version of the Apache Ant project, what we do is we express that interest. We write up why it's important. We then run that to the project management committee for the project, so to make sure there's a technical reason for it. And then after that, it actually goes to the Eclipse Foundation and they do the due diligence and assert whether or not it's a reasonable technology to be used and whether that technology is something that makes sense. So all these steps are in place before the technology is actually adopted into the project.
Nackman: Thanks, John. Next question: Where did the name Eclipse come from. Hmm, who wants to do that? John, do you want to do that? Do you want me to talk about that?
Wiegand: There's lots of fun stories about this one. And in fact for me, sufficient time has passed that the muddling between the stories and the reality are always entertaining. But what we were looking for was an interesting project name that we could leverage back at that point the "e-excitement" that was going on with several e-related names. And there was this riffing going on where people were trying out name A, B, and C and different ones. And Eclipse came up. And it just got a lot of traction. We used it in the development team as a code name for some period of time. And I remember explicit instruction that we don't let it get into the code. But we were pretty excited about the name, and it really stuck with us. And we gained support over time, and the rest is history.
Nackman: Thanks, John. Next one, please. Bill, how about maybe you and Beth can share this one somehow?
Bill Philbin: This is a great question regarding regression tests and providing that level of information to our customers. So, in the last several months we've been actually working with several of our larger customers on comparing notes, if you will, what are things we're testing versus what are things that our customers are testing. We're very cognizant that many of you as you deploy our products you have your own sort of internal metrics and milestones you walk through to make sure the products are ready for deployment in your environment. I think what you'll see is a couple things. One is we ought to be more transparent about how and what we test, as well as starting to work with you on publication of our own suite, such that you'll be able to take advantage of them, but more importantly know in areas where we don't test as well, that are very specific to your environment, such that you can continue to do that testing.
So I think the answer to this question is we're very interested in sharing that level of knowledge with our customers and making sure that we're both benefiting from the joint testing we're doing between us. Beth.
Beth Friday: The only thing I would add is this year we're expanding our advocacy programs. We have the design partner as well as our lab advocate programs. We'll try to get code bits out to people earlier so we can find issues earlier in the cycle and get them addressed before they’re delivered to you in the GA product.
Nackman: Next question, please. Oh. Will we be more open?
I can answer this one very simply. Yes. In fact, Beth is already working on a project to do this. One of the things that I found very interesting when I first took this job was I went around and met with all the support teams. And not only do the customers want this but the support teams want this, because they're the ones, you know, who end up talking to the customers who are frustrated with this process. Maybe you can say a little bit about some of the thinking you're doing.
Friday: Absolutely. Guilty as charged. I think the thing that's going to be most challenging in moving this thing forward was the timing issue. We get lots of good requests and we get all kinds of great ideas. Depending on where we are in the development cycle, it's going to be either easier or more difficult to provide an answer. What I would say to all of you all is that's a platform for discussion. When the platform is provided we need to have the right discussion. I think to date, when no answer is given you just can't get to the right level of detail to be able to have you be able to meet your business needs.
So I'm looking forward to it but I'm going to need the help of all of you in this room because, again, this timing issue is going to be quite challenging.
Nackman: I think one of the things that would help us is, as you see us and see Beth around, let's have some more discussion about this because we very much want to do it and we have to figure out what "doing it" really means, and and how we execute. Because I think part of the transparency has to be this whole discussion. It's better for us to say "No, we're not going to do something" than for us to not answer, which I think is one of the complaints that I've been hearing a lot as I've talked to many of you. So this is something we're definitely going to improve.
Next question. So I'm told this is the last question. Where are the 2006 pins? Maybe they took a detour and went and saw Mickey someplace. I'm not sure. The real answer is that we hope to have them at the registration desk sometime shortly. And I guess Roger is going to give us the stick.
Roger Oberg: I think that's a great answer. I didn't know if you knew the answer. They're at the registration desk. That is the last question. That's all the time we have this morning for questions. I want to thank Bill, EricH, John, Martin, and Beth and Lee for their time this morning and for their presentation. Thank you very much.
-
developerWorks Rational zone
-
IBM Rational Software Delivery Platform
-
Related webcast series
-
The Rational Edge e-zine
-
developerWorks podcasts

Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. Prior to IBM, he was an award-winning reporter and director for news programming featured on Public Radio International, a freelance writer for the American Communications Foundation and CBS Radio, and a songwriter/musician.
