Борис Сёмов

Если эта командаmvn -P cargo.run, то ничего не виснет, это и есть запущенное приложение в итоге, и к нему можно достучаться локально через localhost:8080 после этого, собственно куда ей дальше идти? =)
Вот только такой запуск не пригоден фактически для работы, и является не более чем примером или заготовкой. Т.к. при закрытии терминала работа приложения прервётся. Да и снаружи не достучаться.

Надо написать unit для systemd, который будет запускать ваше приложение в фоне, например, и включить его автозапуск при старте системы.
Также, перед приложением можно поставить какой-нибудь nginx, например, который будет работать как обратный прокси, терминировать ssl и.т.п.

В вашем случае, есть только две разумные альтернативы:

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

Есть Drupal для этих целей. Он очень гибкий, но и довольно сложный в освоении. =)

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

Да ладно, там PHP код в БД хранится, что уж там шаблоны... =)
Впрочем, и то и другое стало можно подключать и из файлов. Так что можно теперь, можно нормально работать с системами контроля версий хотя бы...

А вообще, очень странный человек проектировал MODx, и многие решения там крайне не стандартны(если очень корректно описывать ситуацию), вот и всё.

Он вполне хорош. Особенно, если сравнивать с битриксом.
Разработчиков меньше, но они профессиональнее, в среднем, и найти вполне можно, так что это минусом сложно считать.

Тем кто приводит примеры магазинов крупных сетей на битриксе: Вы же понимаете, что от битрикса там только название для маркетологов битрикса, а внутри всё переписано?

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

1. Не секрет, что изначально концепция MODx придумана и воплощена профессиональным дизайнером, а не профессиональным программистом. =) Соотвественно, аритектура неудобна и местами ущербна.

2. Еvolution просто откровенно убог.
- Проблемы с производительностью при большом количестве документов,а это могильный камень для "лёгкой" cms.
- Хранение кода в базе, а это не только проблемы с системами контроля версий, но и громадная дыра в безопасности - впихнув в базу что-нибудь можно выполнить произвольный код штатными средствами.
Да и других проблем там хватает.

Revolution уже лучше, но xPDO на котором он построен это не фреймворк, а тихий ужас.

Ну и комюнити - там только десяток человек, которые действительно знают, как реально всё работает. Соотвественно, за редким исключением, отвратительной качество расширений, отсутствие достаточного количества информации, куцая документация.

Админка, кстати, после того, как стали кешировать дерево, стала не такой уж и плохой, и это в общем-то не особо-то минус - скорее вопрос вкуса... =)

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

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

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

1. Есть — www.gnu.org/licenses/old-licenses/gpl-2.0.html, естественно это не та лицензия, которую надо продавать. =)
2. Действительно толковой интеграции с 1С нет ни в Drupal, ни в Bitrix.
3. Нет, но в таком виде он и не особо нужен — пилить готовое решение до того состояния, которое необходимо клиенту часто более трудоёмкий процесс, чем создать его из блоков, особенно если есть свои заготовки. Drupal очень гибкая и модульная система, а чтобы не повторять свои решения, можно делать и развёртывать заготовки с помощью features. Это, например, может быть готовый раздел новостей, или другая крупная часть функционала. Есть и различные сборки, но у такого подхода есть минусы — во-первых они практически никогда не совпадают по функционалу с ТЗ конкретного клиента, во-вторых вы не участвуете в развитии и обновлении, с и в один прекрасный момент это может выйти боком…
4. В случае Drupal тут всё зависит от вас, как разработчика — админка Drupal темизируется и настраивается не хуже фронтэнда. Можно сделать в точности соответствующей нуждам клиента, можно очень неудобно, можно оставить как есть.
5. Требования к хостингу сопоставимы — и тому и другому нужен хороший хостинг. Bitrix из-за общей прожорливости, Drupal из-за любви к оперативке, и большого количества запросов к БД, которые на хреновых хостингах часто просто лимитируются.

Разрабатывать под Drupal проще, особенно, если делать что-то не стандартное. Ситуация с этим в Bitrix та же, что вы описывали для UMI.
У Drupal нет мощного маркетинга, поэтому найти заказчика и продать ему сайт на Bitrix проще. И это может быть критичным плюсом, который перевесит все проблемы разработки.
Собственно именно на этом маркетинге Bitrix и выезжает — внутри откровенная гниль.

С мысли о том, что для опыта лучше досконально разобраться в паре крупных проектов, и понять, почему сделано именно так, чем пытаться начать писать свойю CMS без понимания с чего начать.