I have not been blogging as much recently, my new position has kept me quite busy. I have received multiple inquiries on how Jazz CLM compares to open source in the past couple of weeks, and I keep pointing people to some of my older blog posts on How Does Jazz Compare to Open Source Solutions and Jazz in the Real World. Both of those posts are quite old, so perhaps it is time to update them.
Comparing Open Source and Jazz CLM
Comparison of open source solutions and the Jazz CLM solution is extremely tough. Where you end up seems to depend on your point of view, and in what you find to be important. Open Source solutions appeal to smaller teams, because of the low cost of obtaining the tools in question (essentially $0 licensing), and the high degree of autonomy that teams have when deploying these tools. In addition, when looking at this from just a software development team perspective, the tools do the job that they are intended for, are lightweight, and considered “good enough”. The standard question is , “Why pay money for additional functionality which you will never use?”. It is a valid point.
The Jazz CLM solution appeals to larger teams, and to people who deal with multiple software development teams. When teams want to be able to share repository information, roll up software development metrics, and have visibility across multiple software projects/teams, then the Jazz CLM solution is a clear winner over open source solutions. The integration of the data elements, and the visibility of information is much better with Jazz CLM.
You might have noticed that I am being very general at this point, and not going into specific functionality. That is because the differences in developer desktop functionality are often quite minor. People tend to like what they are comfortable with, and the relative “ease of use” and “look and feel” types of measures are extremely subjective and based largely on the experiences of the individual.
The broad general statement that you can use to differentiate Jazz CLM and just about every open source tool is that open source is cheaper to obtain, but the Jazz CLM offers more robust integrations and reporting capabilities. This is a broad generalization, since in many cases the overall cost of ownership for Jazz CLM may be lower than open source, and also since a well crafted open source solution can offer adequate integrations and reporting capabilities. The key here is determining the overall cost to your organization. If you are building the infrastructure to integrate open source solutions, you will need to spend time/money both creating and maintaining these integrations. If you are deploying to a large organization you should also factor in the administrative costs, in terms of overall tool administrators, as well as in terms of the amount of “self-service” administration done by each of the individual teams. (see my blog posting Jazz Hands – Administration and Cost of Ownership)
One other cautionary statement. Do your research, but consider your sources. I am an employee of IBM, and I work on the Jazz development team. You can Google blogs and articles on software development tools and get about 2000 different opinions. Some love Jazz, some love open source, some love other commercial products. Always read these things with an open mind, and consider the author. Some of them you can trust to be fair and balanced (I hope that you have me in this category), while others will clearly have a highly biased view of things.
Other Considerations When Comparing Jazz and Open Source
Some of the other things that you need to consider when comparing Jazz and open source solutions can become quite important, and often they go unmentioned. One of the key things that HAS to be considered are the interests of ALL of your stakeholders. Software development environments impact many different levels of the organization, some directly, some indirectly.
Software developers and software testers are two core groups of stakeholders whose concerns need to be addressed. Do the tools in question address their needs for automation, information sharing, and workflow management? How many of their opinions are based on objective measures, and how many are based on a level of comfort with a particular technology?
Software integrators and delivery teams also need to be considered. Can multiple development efforts be tracked and coordinated?? How can I tell the progress of the multiple teams whose software I depend on to deliver particular capabilities to the business? Do I have visibility to the information that I need?
Your Operations team needs to be considered. Can this solution be supported by a centralized service team? Can the solution be easily deployed and scaled as needs change within the organization? How easy is it to deploy and maintain the solution? What SLA’s are expected?
Finally, your Management needs to be considered. Sometimes they will be the driving force behind a decision, since they have to sign off on the purchase of licenses, hardware and network infrastructure to support a software development environment. Will they be able to have the access to the information that they need? Will they be able to satisfy any regulatory requirements? Will they have transparent views and access to see how their development teams are doing? Do they sufficiently understand the concerns of the other stakeholders?
Take all of your stakeholders into account before deciding on a course of action. Weigh the costs and benefits of your approach to each group, and then clearly let them know what these costs and benefits are. Regardless of your decision, and how it reflects the concerns of each group of stakeholders, ALL of your stakeholders will be more open and cooperative during the deployment of your solution if they understand the reasons for your choice, and they feel that their concerns were heard and understood.
Strategic Considerations of Software Development Tooling
The strategic considerations of what types of software development tools that you use, and how you deploy these tools to your organization are quite important. So far in this article I have provided an overview of the things that you will want to consider, and some idea on some of the more common benefits of Jazz CLM and open source.
In my mind I like to look at the tools used to support a software development environment as an investment. You are spending money on licenses, hardware, training, etc., in order to improve your software development capabilities. Are you getting an adequate return on this investment?
The investing angle also helps me frame the entire conversation about if an organization should choose Jazz CLM or an open source stack of tools. I would argue that you should use BOTH. The Jazz CLM solution allows open source tools to be easily integrated into the Jazz environment. This allows teams to choose the tools that best fit their needs, while maintaining the ability to provide reporting and visibility to the efforts of the software development teams. You use the mix of tools that best fit your software development culture.
Like any investment portfolio, you need to be diversified. It helps you avoid the risks associated with depending on a single company, technology, or approach. You need to be free to try new technologies and approaches, without having to scrap your software development infrastructure every 5 years. I recently read an article that talked about how new technologies have disrupted the industry in the past. On Route 128 outside of Boston you can still see the shells of the old DEC and Wang headquarters. During the 1980’s we all assumed that these vendors would always be around to support their products. They are both long gone now. Not relying on a single source for your solution will allow you flexibility in the future, and reduces the risks associated with the loss of support for any portion of your software development infrastructure.
Utilizing the Jazz CLM technologies mixed with open source, you reduce the risks of going with an IBM-only or open source-only approach. If you choose tools that support the OSLC specification, you can also include tools and capabilities from other vendors as well.
I can hear your objections now – “We wanted to consolidate tools, to reduce costs and improve reporting and metrics!”. With a Jazz CLM infrastructure you will get consistent metrics reporting, roll up of data, and transparency to the efforts of the software development teams. Now your administrative costs will increase with more tools (more things to train administrators and end users on), so I would not suggest adopting any open source tool with Jazz CLM. I would select a strategic set of Jazz/open source/other vendor capabilities that will provide some real value to my teams.
Conclusions
So this article has discussed some of the tradeoffs and considerations that you need to be aware of when trying to decide between open source tools and Jazz CLM. My argument is that these decisions need to be made with an understanding of the strategic implications of your decision, and an eye on reducing the long term risks of your decision. The choice between open source and Jazz CLM is not an either/or proposition. Having a mix of open source, the Jazz CLM technology and other vendor solutions (as long as they all are able to integrate via OSLC) allows teams to choose the appropriate tools for their particular task. A healthy portfolio of software development tools and technologies should be diversified to reduce the risks associated with technological obsolescence and support for your solutions.
Dan Toczala's Blog 