Comparison of TrackStudio Enterprise 4.0 with Redmine 1.0

Redmine is considered to be one of the most popular, modern and advanced open source task management systems. In our opinion, features of Redmine are significantly powerful than the systems like Bugzilla, Mantis, and Trac. Redmine supports the hierarchy of projects and tasks, has the features for managing the access control rules to the projects and even supports customizable workflows. However, generally speaking Redmine doesn’t differ much from JIRA and other open source task management systems, which means that its architecture doesn’t solve many of those problems, which have been described in Jira’s Top 50 issues and our comparison with JIRA. The most fundamental problems with Redmine are related to the storage of files, documents, user permissions, and processing of workflows.

• Redmine has very limited features while working with files and documents . In TrackStudio files and documents can be arranged into a tree, like headings in a book or files on a disk. User can be given access only to the required specific documents or list of documents can be filtered for the submitter. There are features to configure e-mail notifications in case of change in the document or automatically create documents if data needs to be stored in the knowledge base. Not only the projects, but different versions of the project can have their own documentation, and when the document is viewed TrackStudio automatically generates header with references to the attached documents.
• Redmine doesn’t have the feature to manage access controls at the level of separate task fields, whereas in TrackStudio you can. For example, you can’t hide from client the time estimates of the project or information about spent time. In JIRA this issue was once very popular and it even gathered 440 votes, but, still Atlassian was withdrawn. Moreover, it would be very difficult to implement this functionality in Redmine.
• In Redmine one can manage the access control rules at the project level, but it is not possible to assign the permissions to the version of project or separate task. It means, if a user needs access to one task, he will have to be given access to the entire project. In TrackStudio, one can configure the access control rules for each task and every employee or client will only see the necessary information.
• If Redmine user gets access to the project, it is not possible to restrict his activity with some other types of tasks (trackers) . For example, you can’t allow the viewing of only “own” tasks (this is often required in technical support organizations) or allow him to create tasks only of some particular type. In TrackStudio, user permissions can be assigned for each type of task.
• In Redmine all custom fields are accessible by all the users. In practice it means that you can store critically important information in custom fields, as all the members of project can view and edit it. This limitation leads to many complexities if the team is heterogeneous, like when the project is accessed by one and all such as managers, developers and even clients. In TrackStudio, access control rules for each custom field and user can be configured individually.
• In Redmine there are no permissions for separate types of steps in the workflow, and they don’t even have the names. For example, when someone finishes the bug elimination you can not specify that he must select the tester and must indicate the build number. Similarly, you can not keep back from client the internal messages between the programmers. In TrackStudio you can indicate specific permissions of users for each operation (change in task status).
• In Redmine administrator has a global role, you can not delegate the management of separate project to someone else, without opening the access to the entire system. This significantly makes it difficult to use the same package of the system for integrating different departments and types of businesses. In JIRA the corresponding task is very popular and has gathered more than 440 votes. TrackStudio has feature to support local administrators (and generally users with any role) for different projects or tasks – these users have all the permissions of administrator, but only for “their own” projects and users. This is very important, particularly if the system is used in several departments of the organization, at the same time the management needs access to stats not only for the departments, but entire stats for the organization. Similarly this feature is used quite often if the company has many major clients which are dealt with by different employees.
• In Redmine the priorities and states of tasks are global for all the workflows and projects. As of now similar problem in JIRA (it also has the same problem) is first among the Top 50. It gathered maximum number of votes (more than 600), but was postponed for unspecified period after a wait of 8 years. In contrast, configuration of priorities and states for each workflow was implemented in the very first version of TrackStudio many years ago.

Very interesting feature of Redmine is its capability to create hierarchy of tasks with unlimited nesting depth, which is absent in other open source bug tracking systems including JIRA. If we analyze the users’ comments (e.g., on the basis of this page) then we can clearly understand the following application variants of this capability:

• application of product for Project Management or for Integration with MS Project. In this case, hierarchy of tasks is not stored for programmers, but hierarchy of objectives (results) of the project are stored.
• application of product for Requirement Management. In this case we group the requirements into a tree, which later leads to the generation of requirements specification.
• application for Test Management. In this case the upper layer is ‘test suite’, and lower layer is ‘test case’.
• application of User Interaction. In the task of upper layer, the user describes the problem, and so as to solve the problem sub-tasks are generated for the executives (“edit the code”, “write the documentation”, “prepare the forwarding”, and “update the site”).
• application for Document Management. Hierarchy enables comfortably organize the documents into sections and chapters.
• application of the system for solving business tasks. In this case the components of tree can be the products being produced by the company, and departments, clients, or assets of the company.

You can notice that nobody needs hierarchy of bug reports. Task hierarchy plays a role only in that case when the system has a provision for user to create his own tasks like ‘objectives’, ‘requirements’, ‘products’ etc. But at the same time these types of tasks don’t have much in common with bug reports. For this purpose we need other states and other user rules, as these objects are to be created and changed by other people like analysts, testers, translators, and managers. Besides, practically speaking in all these cases we need hierarchy of not similar, but heterogeneous tasks. In bug tracking, we have projects, error messages, components, and versions. In test management we have ‘test case’ and ‘test suite’. For business-tasks these can be departments, products, and clients. Hierarchy support is very vital component which allows considerably widen the scope and features of task management system, but one hierarchy is not sufficient. Features are required for user friendly navigation and search inside this hierarchy. Then we need the feature to set the limitation of access of users to any component of the hierarchy. Often we need the feature to limit several associated hierarchies in one system (e.g. for project management and for user support), so the settings of hierarchies must be delimited: when the user creates a bug report, he must not be thrown over with a mess of various tasks, priorities, and filters from different fields. All these features have been integrated in TrackStudio, whereas Redmine doesn’t have. Many of the ‘genetic’ features of Redmine are a proof that it is unlikely to have such features implemented in the future also:

• In Redmine there are projects, tasks, documents, and files. This is quite suitable for bug tracking, but for application of system in other fields, it is necessary to shift to a unique object i.e. task, which is configured by the user. What is the use of ‘Project’, if inside the task one can create sub-tasks, they can be easily searched, and permissions can be assigned for them. Currently two parallel hierarchies are implemented in Redmine viz. hierarchy of projects and hierarchy of tasks, but hierarchy for files and documents is not supported at all.
• In Redmine, permissions are configured for the projects, but in this case there must be features to configure the permissions for any task. Support for such system of permissions together with the hierarchy of tasks leads to huge build up of overloading on SQL-server (as permissions have to checked for each task and for each field), meaning complete rechecking (and rewriting) of system kernel. There are user plug-ins which can improve the system, but these changes can be extremely expensive for the users.

There are many more other problems in Redmine (complexities involved during management of tasks having large number of sub-tasks, transferring of tasks between the projects, search for history of change in the task, configuration of email notifications and so on), but these problems can relatively be solved very easily and most probably respectively functionalities will appear in Redmine in the near future – only time can be better doctor here. But problems with access control rules and hierarchy support are result of faulty architecture of the system, and it becomes very difficult to fix these problems after first version of the system has been released. So, we think that Redmine can be a very good choice for small teams, but for large scale projects it can be a Herculean task to set things right without commercial task management systems.