JIRA проявляет себя с лучшей стороны именно в качестве продвинутого форума. Т.е. если мы на форуме сообщаем, что бага будет исправлена в 3.5.x, публикуем список изменений в 3.5.20 или план работ на следующую версию, спрашиваем, что клиентам хотелось бы видеть в следующих версиях - мы именно общаемся с клиентами, а не планируем. И Atlassian использует JIRA именно для общения с клиентами, для организации внутренней работы у них довольно необычный процесс, который описан тут:
http://maximkr.livejournal.com/8942.html
Грабли же начинаются, когда их клиенты пытаются использовать JIRA для внутренней разработки или (что еще хуже) для внутренней разработки и общения с клиентами одновременно. Если глянуть 50 их наиболее серьезных нерешенных проблем, то практически все они относятся к попыткам использовать JIRA для внутренней разработки:
- сокрытие полей нужно именно для сокрытия внутренней информации (которой там вообще быть не должно) от клиентов
- подзадачи нужны для организации внутренней работы, клиенты обычно не готовы вникать в глубокие иерархии и как там все расположено
- проблемы с учетом рабочего времени - аналогично, клиенты не учитывают свое рабочее время, это актуально только для внутренних работников
- пользовательские поля для проектов и компонентов, хранение вложений к проектам - аналогично, для общения с пользователями это не нужно, потому и не было вовремя сделано. У меня, например, никогда не возникало желание прилепить к форуму "TrackStudio Support" вложение с описанием TrackStudio :-)

Аналогично, вещи нужные для общения с клиентами (голосование, RSS, анонимный доступ к базе, генерация "что нового?" и т.п.) были сделаны в самых первых версиях JIRA, жалоб на них мало.

В TrackStudio ситуация обратная: еще в первых версиях была сделана функциональность, важная для управления работами внутри компании (иерархия всего и пользовательские поля для всего, ограничение доступа к полям,  очень гибкий учет времени), а вот голосований, анонимного доступа к базе (без регистрации) или генерации "что нового?" в пригодном для публикации на сайте виде нет до сих пор.

Впервые мы с этой принципиальной разницей столкнулись несколько лет назад, когда пытались забесплатно раздавать TrackStudio open source проектам. Оказалось, что анонимный доступ к базе и багзилла-подобный интерфейс для них просто критически важная вещь, а вот поддержка сложных процессов или ограничение доступа к данным не нужны совершенно - процессы очень простые, а данные открыты всем. Т.к. для коммерческих организаций приоритеты обычно прямо противоположные, то мы на идею продвижения TrackStudio в open source быстро забили, хотя рекламные возможности тут просто огромные. По той же причине JIRA так плохо выглядит в сравнении http://www.trackstudio.ru/products-comparison.html - это повылезали проблемы корпоративных пользователей, попавшихся на слова "issue tracking" и "project management" в описании продукта. Де-факто это не целевая аудитория Atlassian, а задним числом можно исправить далеко не все, даже если очень захотеть (JRA-1330).

Может быть, вместо TrackStudio vs JIRA стоит попробовать интегрировать продукты: JIRA как frontend и TrackStudio как backend ? Ведь bug report и change request все равно должны быть разными сущностями и линковаться между собой (м.б. через permanent URL?), пользователи там и там будут существенно разные (в JIRA - клиенты и саппорт, в TrackStudio - саппорт и разработчики), типы задач/процессы - вообще не пересекаются. Имеет это какой-то смысл ?