Технологические аспекты выбора CMS

За доклад спасибо

Если затрагивать такой аспект, то, как мне представляется, есть смысл учитывать еще два-три аспекта

- 1) - условия лицензирования - например, у UMICMS лицензия привязывается к IP - если хостер перенес сайт на другой сервер, что случается, то надо обращаться в поддержку CMS за IP - то же, и при переносе на другой хостинг - ну то есть попробовать там-там-там - или перенести и вернуть - целое дело- тк к саппорту надо обращаться IP прописывать

- 2) - требования к хостингу и список хостингов, на которых работает на обычных шаред аккаунтах - тут, насколько вижу, у всех трех дела не ахти - у UMICMS, в основном, в связи с требованиями к базе, у Битрикса - как бы все знают, что это типа не для обычного шаред хостинга, а у NetCat по требованиям вроде бы все ничего, но - см. пункт 3

-3) - насколько жива вообще компания, предлагающая CMS - ну там, видны какие-то подвижки в развитиии - и вообще жизни - ну смотрим NetCat - по двум предыдущим пунктам он вроде бы как мне представляется явным фаворитом. Так вот - демо-версии системы на сайте не вижу (посмотреть прямо на сайте, а не ставить на локальный ПК вместе с веб-сервером), нормальной демки с ограничениями - попробовать на хостинге, а не на локальном ПК - не вижу, форум - скорее мертв, чем жив (ну если сравнить,например, с форумами некоторых пока менее известных коробочных CMS), список протестированных хостингов - малюсенький - причем на половине из них, при озвученных элементарно простых требованиях, например, не функционирует установка патчей через веб-интерфейс системы. Или, например, такой момент - в апреле прошлого года была громко анонсирована выпущенная хостинговая версия NetCat - прошло полтора года, эта хостинговая версия не запущена ни на одном хостинге

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

Да, кстати, поддерживаю такое мнение. Причём Open Source предпочтительнее, т. к. коробочное решение почти то же самое, что "студийная самописка" - разработчики тоже могут забросить проект, и надо внимательно изучать лицензию.

Кстати, сам собой возник вопрос. Раз уж тестировалась Umi, то не имеет ли смысл (хотя бы в рамках данного топика, либо открыть отдельный) поговорить предметно в ключе вышеприведенного анализа о HostCMS? Насколько понимаю - это прямые конкуренты Umi, причем по ряду параметров - конкуренты нехилые.

А по модулям интернет-коммерции - так "и ваще" на корпус впереди.

Вот так, да? Спасибо, надо будет покопаться и присмотреться. Единственное - ценовая политика, прямо скажем, дурацкая (да простят меня поклонники данной системы). То есть, чтобы иметь на сайте такую крестьянскую элементарщину, как опросы, надо покупать высшую версию за тридцатник. Заметим - с кучей ненужностей с точки зрения средне-стандартной задачи. Неправильно это, имхо. Заказчик не поймёт. И правильно сделает.

Спасибо всем за отзывы!

Да, такое бывает. Хотя нету прямого конфликта между удобством GUI и качеством CMS с точки зрения технологий.

Я считаю, что отчуждаемость безусловно является одним из критериев, но важность ее сильно преувеличена. Про злобного разработчика, который "привязывает" к себе клиента - скорее миф, подогреваемый "коробочниками". На самом деле, держать недовольного клиента - почти всегда не выгодно, требует много нервов и времени.

Вопрос отчуждаемости лежит не в сфере технологий, а скорее относится к организации бизнеса разработчика системы. Если система неотчуждаемая - это значит всего лишь, что ее изготовитель не занимается продажей CMS :) Значит, разработчик не хочет держать большой отдел тех. поддержки, придумывать "универсальный" функционал, вкладываться в маркетинг продукта и т.д. При этом система может иметь и полную документацию, и открытый код, и даже поддержку от разработчика.

Я работал в 4х компаниях, где внедряли свою разработку. Помню всего один случай, когда клиент ушел и затем перенес сайт на другую систему (причем новый разработчик даже не пытался получить документацию, хотя мы обещали помочь). С другой стороны, у нас есть несколько проектов на поддержке, разработанных не нами. Есть на "самописках", есть и на "коробках". Поддерживать "коробки" ничуть не проще, а иногда и гораздо напряжнее. Играет роль не система, а квалификация предыдущего разработчика. Поверьте, на "Битриксе" можно сделать такое, что ни одна вменяемая студия поддерживать не возьмется :)

И кстати, еще одна проблема "коробок" - программисты очень любят валить на них все грехи. Особенно если на использовании системы настоял заказчик. Ну, типа "это не мы кривые, это система кривая, не мы же ее писали!". Не имея квалификации, с этим очень сложно спорить :)

kod_ssilki_ru, спасибо за ценный комментарий.

Возможно, это важно для клиента. Большинство студий со временем обзаводится своими серверами, поскольку это сильно удобнее и дешевле.

Вполне себе жив и открыт для общения :) И развивается в правильном направлении, как мне показалось.

Это было бы интересно. Но у меня нет опыта интеграции этой системы, хотя и "ковырял" ее довольно глубоко. Если кто-то готов взяться за анализ - будет очень круто.

На мой взгляд, доклад будет больше интересен заказчику, для понимания и постановки/обсуждения ТЗ.

Для студии, хм.., должны знать уже, иначе ну нафиг такую студию.

Имхо: боле пользы имело бы дать определение/описание каждому пункту в таблице Search (справа) http://www.cmsmatrix.org/matrix/cms-matrix?func=search

Вот это был бы ценный в работе документ и для клиентов и для исполнителей, чтобы "говорить на одном языке".