• в первом случае мы имеем большие проблемы с нагрузкой на сервера и администрированием. Легко подсчитать, что даже если каждый день на live demo регистрируется 30 человек (реально - значительно больше) и учетные записи действительны в течение 45 дней (как у FogBugz), то через 45 дней у нас будет 45*30=1350 экземпляров системы и столько же экземпляров БД. Как с этим справляются разработчики этих систем - понятия не имею, но мне идея держать одновременно 1000+ экземпляров системы в памяти, бекапить и апгрейдить их кажется довольно сложной задачей.

• во втором случае для разработчиков все сильно упрощается, но пользователи не могут почти ничего, как-то поменять "свою" конфигурацию нельзя.

Если взять hosted-багтрекеры - там ситуация аналогичная: либо для каждой компании отдельный экземпляр со всеми возможностями конфигурирования за большие деньги (ведь масштабируется этот подход плохо), либо большое количество пользователей делят один и тот же экземпляр и конфигурацию задешево. Когда мы начинали писать TrackStudio, то именно на эту проблему и нацелились: мы хотели создать систему, в единственном экземпляре которой тысячи команд разработчиков из разных компаний могли бы работать независимо, при этом все должно было работать на одном сервере, а с администрированием такой системы должен был справиться один человек на part time :-) Тогда (2001 год) эта идея "не пошла" по разным причинам, но продукт остался и разделился на TrackStudio Host и  "скачиваемый" TrackStudio Enterprise.

Как оказалось, для многих компаний проблема специфического конфигурирования багтрекера под каждую внутреннюю команду или крупного внешнего клиента весьма актуальна. Ведь обычно как бывает: разработчики багтрекера пишут, что поддерживают конфигурируемые категории/процессы. При этом отконфигурировать-то можно, но если в таком проекте нужна одна конфигурация, а в этом - другая, то нельзя. Многие поддерживают настраиваемые группы пользователей, но добавить еще одну группу пользователей именно для данного конкретного клиента - уже нельзя. Многие поддерживают настраиваемые шаблоны e-mail оповещений, но посылать разные уведомления разработчикам, менеджерам и клиентам опять нельзя.

Чтобы получить примерный список, что пользователи хотят настраивать для каждого проекта, пользователя или баги,  наберите в jira.atlassian.com в строке поиска фразы типы "per project" (204 баги), "per user" (87 багов) или "per issue" (86 багов). Задним числом исправлять эти проблемы для разработчиков багтрекеров весьма сложно (см переписку по JRA-1602), а для пользователей -  практически невозможно (даже при наличии плагинов и исходников). В такой ситуации пользователи обычно плодят экземпляры системы с индивидуальными конфигурациями, становятся важными клиентами и сурово мучаются с администрированием. Ситуация до смешного доходила - разработчики Seapine TestTrack в white paper гордились одним своим крупным клиентом, который на 200 пользователей и 20 проектов завел 60(!) экземпляров TestTrack.

В общем дело кончилось тем, что мы эту проблему решили, но TrackStudio стала не "просто багтрекером", а чем-то вроде виртуальной машины для багтрекеров (аналогично vmware или даже virtuozzo для операционных систем) - в рамках TrackStudio множество команд могут гонять самые разные процессы, при этом настройки конкретного процесса - это просто настройки, они не так интересны, и это не самое главное. Но как сделать Live Demo такой системы ?

• можно сделать простую и понятную конфигурацию TrackStudio и давать доступ в Live Demo к ней с точки зрения админа. Собственно, в таком виде у нас Live Demo и существовала длительное время, но у пользователей было массовое непонимание относительно возможностей и ограничений такой Live Demo по сравнению с полной версией. В итоге нам надоело отвечать на вопросы типа "а в полной версии можно будет поменять имя корневого проекта?", "а почему номера задач такие большие ?", "а я пользователя с логином john создать не могу, хотя в системе такого нету".

• можно сделать простую конфигурацию и давать к ней доступ в режиме пользователя, но работа в таком режиме не демонстрирует практически ничего.

• можно все объяснять и предлагать пустую конфигурацию, но тратить время на настройку удаленного экземпляра не имеет смысла, гораздо быстрее скачать и настроить свой.

Что бы вы стали показывать в live demo vmware, если бы такая была ? У меня хороших идей нет:

• если просто доступ к одной из виртуальных windows - это никому не интересно, обычная операционка со странными драйверами - что там смотреть ?

• если доступ к админскому интерфейсу, то проще скачать триал локально, чем ставить windows по internet-у через этот админский интерфейс.

И, самое главное: чтобы потенциальный клиент стал настоящим клиентом, он все равно должен будет скачать TrackStudio и настроить ее локально. Чем меньше времени у клиента уйдет на игры с live demo - тем быстрее он получит работающую систему. Зачем ему мешать ?