И еще раз о Mailtux…

Желание нацарапать эту заметку (несмотря на ленивый летний период) родилось после получения информационного сообщения от службы поддержки MailTux (если кто не знает, то Maitux второй версии — один из наиболее продвинутых на сегодняшний день скриптов сервиса рассылки писем). Однако, ближе к теме… цитирую:

«Подписчик, приветствуем вас!

Вчера на нашем сервере произошел сбой и мы подозреваем что у некоторых пользователей могла «слететь» активация скрипта.
Пожалуйста проверьте статус активации своей копии и в случае если активации нет, активируйте скрипт снова.

С уважением к Вам,
… команда MailTux»

В общем-то, не то чтобы меня возмутил факт того, что на сервере поддержки Mailtux произошел сбой: с подобными проблемами у провайдеров мы все сталкиваемся регулярно и знаем, что это неизбежно. Проблема также и не в том, что этот сбой случился там не первый раз… Ибо и это можно понять. Да и вообще, все это мне как бы «до лампочки», так как сам я сравнительно долгое время, а точнее — с конца марта, — уже не использую честно приобретенный когда-то скрипт Mailtux: вынужден был отказаться от него, несмотря на все его достоинства и причина (или повод?) для этого даже описывались где-то в одном из моих блогов.

Так что дело вовсе не в этом. А тогда в чем же? Да просто снова нахлынули рассуждения о выборе правильной политики распространения коммерческих скриптов (с одной стороны, — то есть со стороны разработчиков) и выборе самих скриптов (с другой стороны, то есть со стороны пользователей-покупателей).

Ведь, по сути, что получается с MailTux? Клиент покупает вроде бы скрипт, и платит за него как за полноценный программный комплекс, который устанавливает на своем ресурсе, со всеми вытекающими недостатками этого пути:

  • зависимость от своего хостера,
  • необходимость мониторинга сервиса собственными силами и т.д.

Мириться с этими недостатками пользователь согласен ради чего?

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

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

В результате пользователь сталкивается с проблемами, как минимум, в два раза чаще, потому что находится в двойной зависимости: как от своего провайдера (и его провайдерских проблем), так и от провайдера сайта разработчика… И такая зависимость — даже хуже, чем зависимость от стороннего специализированного сервиса (SmartResponder или Unisender).

А в чем, собственно, причина того, что MailTux-2 так жестко и «неумолимо» завязан на сайт разработчика? Неужели дело только в борьбе с пиратством? Честно говоря, что-то сомневаюсь… Нет, я конечно, тоже не люблю пиратов, ворующих, к примеру, мои инфотовары, и стараюсь хоть как-то от этого защищаться, но нельзя же превращать борьбу с пиратством в «цель жизни»… Представьте, к примеру, что сказали бы обо мне клиенты и читатели, если работоспособность всех своих коммерческих электронных книг (то есть саму возможность их открывания и чтения на компьютере клиента) я ставил бы в зависимость от работоспособности своего сайта. Наверное меня, как минимум, посчитали бы параноиком… Так что корни этого, думаю, все же глубже, и уходят они возможно в тяготение разработчика Mailtux к MLM-ным методам продвижения товаров и услуг, со всей замысловатой и мутной спецификой этого явления: «структуры», «компенсационные маркетинг-планы», иерархия, командная зависимость друг от друга и т.д и т.п. И я думаю, что от всего этого Mailtux-2 только проигрывает.

Как бы там ни было, (между прочим) прошло три месяца с того дня, как я решил перевести свои основные рассылки на Unisender (хотя и продолжаю использовать старый добрый «Дятел» в некоторых вспомогательных проектах) и должен сказать, что за это время пока ни разу не пожалел об этом.

Ничего плохого про Unisender сказать не могу: достаточно «продвинутые» инструменты для анализа эффективности рассылок, полноценная возможность использования в иноязычном (в частности англоязычном) секторе Интернета, и полное отсутствие головной боли по технической поддержке сервиса… И все это при вполне вменяемой ценовой политике.

Кстати, ценовая политика Unisender кажется мне особенно привлекательной для новичков (хотя сам я уже давно не отношусь к этой группе, но все же…) И эта особая привлекательность состоит в возможности пользоваться абсолютно полноценным сервисом (без рекламы, с полным доступом к базе подписчиков и т.д.) бесплатно при небольших подписных листах (до сотни) и невысокой активности рассылок (что обычно, как раз и имеет место в случае с новичками.

Ну а для остальных привлекательность ценовой политики заключается в соответствии затрат реальной нагрузке: любой пользователь может выбрать такой тарифный план, который действительно оптимален для него: к примеру, если нагрузка не очень велика, то можно платить за число отправленных писем, ну а при увеличении нагрузки всегда можно перейти на абонентскую оплату и снова не платить лишнего. Мне кажется это удачным решением, позволяющим достичь максимальной гибкости. Так что пока могу смело рекомендовать этот сервис рассылок…

Ну а тем, кто все же хочет полной независимости, видимо ничего не остается, кроме как ориентироваться на «Дятла», достоинства которого:

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

И всё это при вполне сносных возможностях: не знаю, как насчет десятков тысяч подписчиков, но в пределах нескольких тысяч — все реально работает, проверено; на первых этапах более чем достаточно, ну а что касается более серьезных нагрузок, лично я не уверен в целесообразности поддержания списков из десятков тысяч подписчиков, — которые очень быстро превращаются в «мертвые души», — в такой сфере, как частный информационный бизнес, особенно на начальных этапах его развития, — о чем уже неоднократно писал в этом блоге.

Единственная особенность «Дятла», которую нужно обязательно учитывать: он не поддерживает кодировок UTF-8 (во всяком случае — на момент написания данной заметки) и это может повлечь за собой некоторые ограничения его использования на отдельных движках.

Однако, как же Mailtux?.. Желания использовать его дальше для ведения реальных рассылок пока больше не возникает, но не исключено, что я попробую как-нибудь еще раз установить его на какой-нибудь свой «дежурный» домен, для проведения дальнейших исследований… Заодно можно будет проверить такой аспект, как реакция разработчика на смену «адреса прописки» скрипта. По идее (если руководствоваться здравым смыслом, лицензия на другой домен — при условии снятия скрипта со старого адреса, что уже произошло фактически, — должна выдаваться разработчиком бесплатно… ведь скрипт был честно куплен… Однако, так ли это будет на самом деле — посмотрим… Так что вполне возможно, что это не последняя заметка о Mailtux в этом блоге.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.