TrackStudio 5.0 vs. Atlassian JIRA 6.1

TrackStudio is not limited to just managing the tasks.

First of all, TrackStudio allows managing not only the tasks, but also files and documents. For example, in TrackStudio files and documents can be organized into a tree, like heading in a book or files on a disc. It is possible to grant the user access only to some particular documents or filter the list of documents submitter-wise. One can configure the email notification in case of change in the document or automatically create the documents, and if required the information can be stored in the knowledge base. When the document is viewed, TrackStudio automatically generates the heading with links to the attached documents.

At the same time, Atlassian JIRA doesn’t have the features to manage documents and files, for this purpose one needs to use Confluence. TrackStudio offers an integrated solution, which enables to simplify the installation and you don’t even need to synchronize the systems.

As JIRA doesn’t have the features to manage documents and files, so in this comparative study we will only be discussing the application of Atlassian JIRA and TrackStudio Enterprise concerning management of tasks.

‘Large’ and ‘Small’ Task Management Systems.

Task management systems during the past 10-20 years have developed in two completely opposite directions. On the one hand, ‘smaller’ open source systems were continuously becoming sophisticated and improved. Success of open source systems led to commercial products, which were based on the same architecture, but had more developed features. Simultaneously, in the ‘large’ systems the changes were going on in completely opposite direction – since their beginning the sophisticated and costly systems while retaining their architectural characteristics became more user-friendly and cheaper.

It has been seen that features of ‘small’ and ‘large’ systems don’t have any confluence till date. Products (including the commercial ones) on the base of open source systems have not been able to implement the basic functions of ‘large’ systems, and ‘large’ systems have become similar to ‘smaller’ ones only from the point of view of user, but not the administrator.

We will now analyze the features of ‘large’ and small’ systems for a particular example.
Let us take JIRA 4 as an example of ‘small’ system. Why particularly JIRA? This is because JIRA was developed as a substitute to Bugzilla, it replicates the architectural features of open source systems ((Bugzilla, Mantis, Trac, Redmine), but it significantly surpasses other ‘small’ systems. If some functionality is required by the users of JIRA and it is not there, then most probably there must be some serious behind this, and other ‘small’ systems will also not have this functionality. We can take TrackStudio as an example of ‘large’ system, as you know our purpose was to create a light, reasonably priced and user friendly substitute to the standard ‘large’ system like IBM Rational ClearQuest.

Since their very beginning ‘small’ and ‘large’ systems were developed in different conditions for different tasks. Large systems were intended for managing the tasks in commercial organizations. Large number of projects, tasks, array of different workflows, and restrictions for information access are characteristics of such conditions. Actually, ‘large’ systems were more oriented towards processing of tasks within the organization and were not intended for communication with the end users.

On the other hand, open source systems were created rightly for communicating with the users in open source projects. In such projects, large number of external users come together with the ease of internal workflows. Team of developers, as a rule, is low-profile and homogeneous, all the tasks are open to all, internal workflows are simple, and one copy of tracker is often used for one project. Architecture of ‘small’ systems was originally developed for working particularly in such situations, but such situations are not specific to commercial organizations, a lot of typical nagging problems arise even when very powerful ‘small’ systems are used.

As a basis for our analysis, let us take the list of 50 most popular, but not yet resolved problems in JIRA. In this list, we can single-out following groups of problems of same type:

• If standard hierarchy of the types of tasks does not suit us, then one can not change it or create a new hierarchy. For example, for ‘requirements management’ we need the capability to create a hierarchy of requirements with unlimited depth. For ‘asset management’ we need a hierarchy like building-room-equipment. These types of situations often arise in practice, but they can not be implemented on the basis of model project-version-task. In this regard, following tasks have been created in JIRA top 50: JRA-4446 (support for hierarchy of tasks is required), JRA-846 (support for hierarchy of components is required), JRA-12241 (support for groups of projects and sub-projects), JRA-5225 (accessibility of components and versions in sub-tasks), JRA-568 (builds are required within the versions), JRA-3501 (versions of components are required), JRA-6398 (inheritance of properties is required in sub-tasks), JRA-5721 (nested categories are required), JRA-1072 (generic sub-projects are required), JRA-2698 (versions are required for some projects), JRA-8663 (generic components are required).
• Many of the setting in the system are global and they can not be changed for a particular group of projects, project, and task. This leads to the necessity for installing a separate copy of the system for each group of projects or users, which significantly complicates the administration and usage of the system (e.g., one can not collect ‘his’ tasks quickly from several trackers). From top 50, following problems belong to this category: JRA-3821 (priorities, status, resolutions must be separated for different projects), JRA-3156 (a subordinate administrator is needed for the project), JRA-6381 (rights are to be indicated for each state), JRA-9997 (subordination of users has to be taken into account while editing the objects), JRA-2364 (access is required to the fields for different groups of users), JRA-5865 (configuration of rights is required for every type of tasks), JRA-161 (different notification templates are required for different projects).
• Many features have been implemented only for some specific types of tasks. Top 50 include the tasks such as JRA-1991 (there are custom fields for tasks, but they are required for projects) and JRA-2764 (there are permissions for projects, but they are required for separate tasks).

You can see that these are not farfetched problems, particularly JIRA users consider them to be most serious problems in the product, many of them were created more than 10 years back and hundreds of users have voted for their solution. In the description of any of the above listed problems, you can find numerous comments on the Atlassian website describing specific examples of usage of this functionality (if it had been implemented).

Reason for these problems is the generic architectural feature of ‘small’ systems – in them the types of tasks and relations between them are inflexibly set at the development stage. It means that the programmers as early as at the development stage specify that the projects will be stored in one table, versions – in another, and error messages in the third one. For every table, they write a separate interface for viewing, creating and editing of notes. This allows to quickly implementing the basic functional of tracker, but when clients need custom fields for projects, versions and tasks, then they need to be implemented thrice. Actually, any of the above listed problems can be resolved, but attempts to resolve all these problems will lead to increase in the volume of code and interface complications by many times.

Why despite all these shortcomings, ‘small’ systems are so popular now?
There are several reasons for this:

• Above listed problems of ‘small’ systems are not visible during formal comparison of systems and do not show up at the time of testing of system on 1 or 2 projects. Problems become apparent when the number of projects increases, or when there arises a necessity to change the configuration of one project, without disturbing the other projects. Generally by this time the tasks management system has got integrated so closely with other systems in the company that the possible ‘shifting’ becomes very costly.
• Due to high price, ‘large’ systems were in the past used only in large scale companies, which means that very few users have the experience of administration these systems (though piracy has rendered this problem less relevant in Russia). Most of the users have experience of working with ‘small’ systems, but architecture of ‘large’ systems differs, intuition leads to invalid solutions, and the system gives the impression of being ‘non-intuitive’.

  It is noteworthy that the problem is not solved by simplifying the interface: in this case more similar situations may arise and the intuition usually prompts invalid solutions. Some other architecture of the system can be hidden from the user but not from the administrator.

• Small system can be run on LAMP-hosting, the large systems are generally written in Java/C++ and required dedicated or virtual server. For many open source projects this criteria plays a decisive role.

The only method for solving these problems is to convert JIRA into a hierarchal tasks management system. But it is just not possible to do that, as hierarchy must be present in the core of system architecture, and it can not be done later. Most of the above listed problems became insolvable within the frameworks of JIRA back in 2003-2004, and further accumulation of votes is hardly capable of changing this situation.

People at Atlassian very well understand this, as Jeff Turner, a JIRA developer, back in 2003 wrote:
There are many cases where it would be useful to have issue-level concepts (type, lifecycle, priority, due date, scheduling, custom fields) apply to projects, and project-level concepts (permissions, notifications, URLs) apply to issues. Effectively treating projects as aggregate issues. [...]
In general, JIRA needs to keep a balance between simplicity for 80% who don't need advanced features, and generality for the 20% who do. Giving users the source (or just JSP source, as illustrated above) lets us err on the side of simplicity.

In TrackStudio all the above listed problems of ‘small’ systems have been resolved as projects, versions, components, errors, requirements are just different configurations of a single entity i.e. task. You can yourself define your category of tasks, possible states of the task and rules for switching between them, specifically set the user rights. Besides, practically all the configuration elements in TrackStudio are not global, but are linked to a particular task and are accessible only for the sub-tasks. For example, so as to create a global filter it must be created in the root task, and to create a filter for the project it has to be created in that project. These architectural features allow configuring and using TrackStudio for managing a variety of workflows, even the ones that are not related to it. Process for configuration of TrackStudio has been documented and can be done by the click of mouse directly from web-interface and it doesn’t require any programming knowledge.

Price and terms of delivery

TrackStudio and JIRA developers follow quite different pricing policies. For some usage options, the difference in price can be negligible, and for others the price may differ by tens of times.

We will assess the total amount of licensing costs depending upon the terms of system usage and number of users (i.e. internal employees and clients):

That way, though Atlassian JIRA is significantly cheaper than TrackStudio for teams of 6-10 users, but for companies with large number of users the cost advantage of TrackStudio can go upto 10 times and even more. This difference can be attributed to the following features of product licensing:

• Price of Atlassian JIRA rises sharply with the increase in number of users, whereas unlimited license of TrackStudio can be purchased only for $995. This gives TrackStudio a great cost advantage for large scale companies and companies with large number of external clients.
• For every Atlassian JIRA one needs to buy a separate license, whereas for TrackStudio the license for unlimited number of servers and users is available only for $2495. This puts TrackStudio way ahead in respect of cost effectiveness when several servers are used.
• Support and renewal for Atlassian JIRA must be purchased separately for every server, whereas for TrackStudio there is a Global license, where extension of license doesn’t depend upon the number of users and servers. This is again a cost effectiveness of TrackStudio when tracker is to be used for many years.

Conclusions

Advantages of TrackStudio are particularly evident in the following situations:

• The system is to be used by different teams within the company. Inside a single system create several independent projects with own teams (departments) and administrators. Usage of a single system enables to significantly simplify the administration, assign the privileges, and improve the integration. Besides, you also significantly cut down the licensing costs.
• The system is to be used for managing the work within the company, as well as for communicating with the clients. Atlassian uses JIRA only for communicating with external users ([1], [2]), but not for managing the software development. More flexible access control rules and feature to block the clients from accessing different fields of the task (time spent, priorities, budgets etc) make TrackStudio certainly a better choice in this case.

  On October 7. Charles Miller from Atlassian said that it is “patently untrue”. You can read the complete articles on the above given links and decide for yourself.

• The company has many major clients, and you want to integrate your work flows with the workflows of clients. Feature for independent configuration of system for each client allows achieving of better integration with each of them. You can use a single system for working with all the clients, and clients will suspect about the presence of someone else’s projects in the system.
• Your company is working on large number of projects. TrackStudio enables effectively manage thousands of projects: projects can be organized into hierarchy, projects can be searched for parameters, files (e.g. with requirements specification) can be attached to the projects, user fields (release date, client, and agreement number) can be created for the projects, and much more.
• You want to automate the frequently changing workflow or some complex workflow, consisting of large number of states. When before executing the task, it has to be approved by several managers? When you require the feature for concurrent approval? When you want to include preparation of documents, forwarding of accounts, or technical supports for users into the workflow? TrackStudio effectively assists you in automating the complex and changing workflow in an optimum way.
• You are planning to use the system for managing the software development projects. TrackStudio supports the hierarchy of tasks (WBS or work breakdown structure), a key elementfor project management systems.
• You want to integrate several services (bug tracking, help desk, knowledge base, asset management, requirements management,...) within a single system. Usage of a single product significantly simplifies the integration of all the departments of the company: you will not need to create accounts for employees, projects, configure the access control rules and email notifications in each system. Transfer of tasks from help desk to bug tracking, from bug tracking to knowledge base becomes significantly easier.
• You are using hourly pay system for settling accounts with employees and clients. In TrackStudio you can take into account time spent not only for projects and people, but also for operations. For example, you can check how much time was spent on eliminating the high priority bugs or errors, and how much time was spent on testing. You can also indicate which of the developers can enter the time spent and whether clients can view the time spent by developers. You can also set any limitations on comment, explaining what has been done (e.g., programmers must write comments of at least 20 characters for every working hour, and managers – minimum 30).
• You need to integrate the tasks management system with internal software. Powerful features for email notification, e-mail import, import from CSV files and complete SOAP API make TrackStudio a better choice, if you are interested in integration with other products.
• You are looking for an alternative to the ‘large’ commercial tasks management system. If you need the features of Rational ClearQuest or Serena TeamTrack, but are not ready to pay $1000 (and even more) for one user – in that case TrackStudio can be a wonderful choice. TrackStudio not only doesn’t yield to these systems, but in many fields it is better than them.