I have talked to a few customers since the turn of the new year, and they have been very honest and open with me in what they see, and what they perceive in the current marketplace. We discuss the future of software development, as well as industry trends. One interesting discussion revolved around the issue of support for vendor tools, what our customers expect, and what they actually get. It was particularly interesting because I realized that I have had this same conversation many times over the past 18 months, in different forms. Maybe one of the best points of an investment in Jazz is not being well communicated by IBM to our customers.
The main issue revolves around the differences between open source and commercial tools for software development. I will not get into a discussion on differences in capability, there is already a large amount of information out on the web and on Jazz.net (and in my own blog entries on differences between RTC and Subversion). What I want to look at in this article is the differences in how these are supported, and how easy it is to get help and get issues resolved. First I want to set some context, and go over a little bit of recent history.
In the past, our customers would buy licenses for software development tools, and would also pay a fee for support of the product. This support fee helped to pay for the ongoing upgrades to the tools, as well as any patches or bug fixes (GASP!). Yes, our software does have bugs. It also helped support an on-call support team that would help out customers with issues that might not have involved bugs, but may have been tool usage issues. Customers were not particularly impressed with customer support, for us or for the support from any other vendor for that matter. I almost always heard complaints about how it was difficult to see the status of their open tickets, a pain to get through the phone prompts, and tough to get quick responses from support engineers. Support bashing was (and remains) a common thread among many software tools customers.
Many of our customers have been contemplating, or actually moving, to open source tools. One of the reasons for this is the reduced cost of acquisition, or perhaps mistakenly for the cost of ownership (see my earlier blog post on Jazz Hands – Administration and the Cost of Ownership). Customers have pointed out that some open source tools have large communities of users that actively fix bugs, and that in some cases these communities are more responsive and quicker to react than existing commercial solutions. I will not argue the relative merits of paid support and community support, since I think one could find good examples on either side of the argument. It is just important to understand the context and the landscape of the software tools environment with respect to support.
Jazz solutions acknowledge this divide, and they attempt to bridge this divide. The Jazz tools are developed with what I would call a “Jazz mindset”. This is a robust adoption of Agile principles, with a focus on making the development teams both transparent and accountable. You can see our dashboards, iteration plans, bugs, enhancement requests, and just about EVERYTHING out on Jazz.net. This level of transparency is unmatched in the commercial world, and it attempts to model (and improve) the best aspects of many open source projects. Our development teams are responsible for monitoring the Jazz.net forums and customer bug reports can be seen immediately by everyone, our development teams, our executives, and our customers. It allows us to provide an environment where there is a focus on quality (nobody wants to look bad and have a large pile of bugs), and where customer issues are addressed in a timely matter, by the team members best suited to solve these issues.
Coupled with this are a series of forums on Jazz.net. The answers to customer issues aren’t secret, you can search for them and follow usage issues and best practices conversations out in the Jazz forums. These forums are a place where customers, thought leaders, and IBM developers can all come together to solve issues and discuss future product directions and enhancements. This is a key component to having a transparent development effort, where all voices can be heard, and we are able to respond to the issues that are important to our customers right now (not 6 months ago). There are journalists and analysts that make a living getting this kind of information from our competitors, and then guessing at future directions and features for their products. (Note: I was dying to put a link to one of these articles in here, but I hate to single any one competitor out.)
So you get the responsiveness of an open source community, with a corporate commitment to continue to grow and evolve the Jazz technology. This is critical, since many open source projects will have some initial momentum, but then seem to fall out of favor when the “next best thing” comes around. IBM has made a significant commitment to Jazz, and continues to improve the Jazz foundation, as well as provide new capabilities that leverage this architecture.
Don’t trust me on this, go out to Jazz.net and check this out for yourself. Choose a couple of random bug reports from the Rational Team Concert project work item area. Look at the discussion associated with the bug. Check out the time stamp for when the defect report was created, and when the first response was created. Look at the time stamps on subsequent discussion entries. Often the “turn around” time will be 24 hours or less, and the discussion immediately will move to the technical issue at hand. Look at our development dashboards, iteration plans, and check out the forums. It may not always be flattering for IBM, but you will be able to see exactly what is going on in Jazz development.