drg_Рассматриваю различные open source framework'и для ERP и готовые системы, которые можно использовать под BSD, MIT, Apache и т.п. license, допускающие последующие закрытие кода.

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

drg_Просто в реальной жизни может быть удобно сначала продать продукт с закрытым кодом, посопровождать его, потом через какое-то время его открыть и т.п. Мне сложно даже предположить все нюансы развития ситуации, а GPL связывает необходимостью открытия исходников сразу (понятно, что возможна корректировка на российские условия).
Никаких более-менее приличных и бесплатных вариантов open source решений с возможностью закрытия кода сейчас нет.

drg_s_ustinov, Чем так плох ofbiz ? Интересует именно технические проблемы framework'а. То, что нужно делать локализацию (как в плане перевода, так и в плане многочисленных изменений под законодательство, в т.ч. бухучет, т.д. и т.п.) - это и так очевидно, но с этим проблемы и у других open source решений. Чем плох ofbiz в качестве основы?
Мне рассказывали про попытку его использовать (выбрали по причине возможности закрыть код). Не получилось - слишком уж он "нерабочий". Речь идет именно о прикладном функционале ERP. Как фреймворк может и не плох.
Я не думаю, что фреймворк как таковой так уж важен для разработки ERP. Пример - та же 1С. Возможности платформы большие, но написать нормальную ерп у них пока так и не получилось.
Тот же адемпьер можно запустить за несколько недель (дописав передачу данных в 1С бухгалтерию) - практически все важные (критичные) для большинства функции работают "из коробки". А писать самому кучу прикладного функционала можно, но экономически невыгодно.

Вы попробуйте проанализировать, почему сейчас возникла задача переписывать существующую самописку, и за счет чего вы надеетесь написать новые модули лучше, чем они были написаны. Сам по себе фреймворк тут особо не поможет...

instant А для отсекания бреда существует бредоотсекатель. Мы же говорим о ERP, а не о поделках для кладовщиков или бухгалтеров. В этом процессе всегда присутствует такой же архитектор, как и при разработке "готовой" ERP
А можно пример такого проекта?
Чтобы и бредоотсекатель был, и архитектор с соответствующим опытом, и чтобы была именно ERP, а не "поделка".
И самое главное, чтобы было экономически целесообразно писать новую систему, а не использовать готовую. То есть существенная часть существующей тиражной системы (естественно, наиболее подходящей) была бы неприменима по причине отсутствия необходимых функций.

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

Разумеется, бывают большие задачи, которые правильно решать не доработкой существующей системы, а написанием новой с нуля. Что-то из подобного: http://www.computerra.ru/80130/walmart-bigdata/
Но для ERP систем почти всегда достаточно или относительно небольшой модификации существующего модуля, или написания небольшого дополнительного модуля, а процентов 90 всего необходимого функционала прекрасно подойдет в неизменном виде из нормальной тиражной системы.