Pull to refresh

Comments 30

Странно, что за все эти годы, таки и не сделали свободную (и не на Перле) альтернативу OTRS.

Их полно (да хоть та же bugzilla).
Другой вопрос что автор о них не в курсе, видимо.
Ну и с перлом — тут да, исторически сложилось. Кроме перла есть на php (в основном) и java (на порядок меньше).

Это был ответ на первый вопрос — свободные трекеры.
А на второй (не перл) — в свое время перерыл большую кучу трекеров (для саппорта своих юзеров), искал на питоне (чтобы проще было в свое одно лицо подлампичивать).
То таки да — на удивление много из них (если не большинство) на перле.
Совершенно неясно почему.
Может они все из багзиллы выросли?

Багзилла — на перле, Mantis — на PHP, Trac — на питоне, Redmine — на руби. Выбор есть :-)

посмотрел документацию bugzilla, там вроде тоже на Perl
Картинка про сыр в мышеловке просто супер!

Сорри, нельзя ли более конкретно описать какие правовые и не правовые (технические) ограничения опенсорсной версии и почему я все же скорее всего перейду на платную версию системы?

Никаких правовых ограничений на использование опенсорсной версии нет. Ведь её надо установить и использовать даже в коммерческих целях, что никак не запрещено.

Тут речь не об ограничениях, а о требованиях того бизнеса, который будет обслуживаться.
1. Если дефолтные воркфлоу заявок (тикетов) в системе вас не устраивают, надо редактировать свои, а это немного сложнее/дороже.

2. Если же речь не о воркфлоу, а о работе с определёнными технологиями, поддержки которых нет в опенсорсной версии, но есть в платных, то тут и появится вопрос — за свои средства разрабатывать эти возможности, либо платить и получить готовое решение. {И ещё — надо обязательно разобраться, поддерживает ли сей провайдер VPS/VDS хостинга с поддержкой того, что вам нужно. Если нет — надо будет искать альтернативу};

3. Если и готовое решение вас не устроит, то — заказывать прямо у разработчиков системы, либо писать самому, либо нанимать своих писателей (на заказ у контор или лично — не имеет значения).

Вот и ответ на ваш вопрос: неизбежная «платность» возникает при некоторых условиях в пунктах 2 и 3. А в пункте 1 можно и самому разобраться и «допилить».
В случае OTRS Community Edition нам нужна виртуальная машина с 2 ядрами и 8 Гб оперативной памяти

Это такие минимальные требования?
Недетские какие-то, однако.

OTRS написана на Perl и чтобы более менее шустро работать, требует ресурсов.
В целом OTRS хороша, но с ней нужно поковыряться, чтобы настроить под себя. А это требует уже наличие человека, разбирающегося в дебрях Perl и времени на это. Что тоже стоит денег.
Так что сравнение в данной статье довольно поверхностное.

8 гигов RAM??? Чтобы только зашевелилось? Оно там Звездные Войны рендерит в фоне, что ли?
Хотя, вероятно, проблема всё же в том, что таки да — не столько статья, сколько подход автора к написанию статьи — на отъ несколько поверхностен.

Разработчики с вами не согласны и считают, что такие требования — это вполне нормально:
"OTRS does not have excessive hardware requirements. We recommend using a machine with at least a 3 GHz Xeon or comparable CPU, 8 GB RAM, and a 256 GB hard drive."

Ну если для разработчиков это "not excessive"…
Прям как в анекдоте — "я вот медка хлебнул — и не жужжу".

В квоте ведь написано «we recommend», это не то же самое как и «только зашевелилось».
Тем более, это наверняка речь идёт про физический хост, где кроме этого ещё запущен web server, база данных, mta и прочее, которые тоже кушают из общего корытца.

Не знаю насчет конкретно OTRS, но вот JIRA на recommended едва запускается. И, конечно, если попробовать запустить там webserver, базу данных или что-то подобное, то вообще перестает шевелиться.
Так что я очень сомневаюсь, что вы правы в данном случае.

JIRA на Java, поэтому там вообще стартовые требования другие.
Для перла такие же требования просто неприличны.

Значит, на JIRA указано «minimal» под видом «recommended». Это не одно и то же. Не знаю почему они так сделали. Возможно, есть какие-то особенности.
В любом случае, JIRA не показатель остального софта.
JIRA в этой области считается чуть ли не эталоном. Но да, для Java приложения много памяти не бывает никогда, а вот мало — практически в любом случае.
Эта же виртуалка должна ещё SQL сервер держать, что в совокупности — вполне разумные требования. Но вообще для тестовых целей для пары человек я OTRS подымал на гигабайтной виртуалке и одном ядре от атома (ценой что-то типа доллара в месяц), ничего, в принципе нормально работало. Небыстро, но и не критично медленно.
В документации OTRS указан рекомендуемый размер RAM 8 Гб. Это связано с тем, что структура базы данных оптимизирована под высокую производительность с активным использованием индексированных полей. При меньшем размере RAM база данных создает нежелательную нагрузку на диск при существенном замедлении работы.

Могу предположить, что решение не слишком масштабируемо хотя бы в одну сторону.

У OTRS с масштабированием вообще проблемы. Там есть большой, просто огромный задел вверх, но он всё равно однажды заканчивается, и вот тут начинаются проблемы. Особенно когда база уже в десятки гигабайт.
(разово заплатив программисту Perl)
А потом многоразово за фикс багов.
Имхо: тут влияет наличие/цена специалистов для бизнеса по данной системе, поэтому сравнение цены хостинга и системы (сюда же войдет и хостинг, и поддержка, и обновления) не совсем корректно.

Зашел сюда почитать про один из любимых продуктов с открытым кодом и узнать чем OTRS так "уделала" всех. Но кроме "бла-бла-бла, она бесплатная!" никаких других аргументов не нашел.


Я сам с ней работал лет 5-7 назад: устанавливал, настраивал, допиливал. Есть у неё свои преимущества и недостатки. Открытый код и масса опций конфигурации позволяет настроить систему под любые нужды. Но в этом же и недостаток — количество настроек зашкаливает, в них легко потеряться неподготовленному специалисту. Скорость работы тоже не её конёк. Как я ни пытался улучшить этот показатель, всё равно (особенно с некоторым количеством дополнительных модулей) скорость работы оставляла желать лучшего. Но функционал нас радовал — тут тебе и ITSM модуль, и интеграция с системами мониторинга и встроенная CMDB, широкие настройки по контролю доступа…
Насколько я знаю, отдел в котором я работал, до сих пор использует OTRS. Правда не знаю обновляли ли они её с тех пор.
Было бы интересно почитать что изменилось за последние несколько лет в лучшую сторону.

вы можете допились себе всё, что нужно для вашего экземпляра OTRS (разово заплатив программисту Perl)

… и в итоге стоимость владения подскочит до небес, легко превысив стоимость лицензии для 10 пользователей на последующие 5 лет.

Считать нужно не затраты в месяц на лицензию, а стоимость владения — сюда (как минимум) входит время ваших сотрудников, которые систему устанавливают и поддерживают. Впрочем, если они у вас за еду работают, то можно и сэкономить (хотя еда тоже не бесплатна).

К тому же, OTRS по интерфейсу (и удобству его использования) отстаёт лет на 10, а перегруженность этого самого интерфейса (и функционала) просто зашкаливает — в обычной жизни нужно в лучшем случае около 10%.
В OTRS ужасный редактор, постоянно верстка ломается. Вставлять текст та еще проблема. В итоге для специалиста тех. поддержки больше времени уходит на то, чтобы отформатировать сообщение, чтобы ничего не сломалось.

Еще большая проблема с Reply window, которое конечно можно увеличить поле для ввода, но совсем не гибко (потому что Perl и куча legacy кода и вообще не понятных решений). Поэтому все вышесказанные замечания про человека, который все это будет настраивать — правда.

Странно, что никто не упомянул RT tracker.
И да, он тоже на перле, и может даже старее, чем otrs. По сути системы весьма схожи по фичам. При сотнях тысяч тикетов могут вылезать всякие сложности. Еще RT недавно обескуражил таблицей sessions на пару десятков гигов. Выяснилось, что они НЕ удаляют из бд токены веб сессий. Типа, запускайте скрипт по крону сами. Так написано где-то на вике…
Такой вот бай дизайн.

Возможно ли продавать собственные плагины для OTRS?
Sign up to leave a comment.