MoroZ.RuИнтересно, кто-нибудь добрался до этапа командной работы над фреймворком? Какие возникли технические трудности в связи с этим?
Командный этап не получается по 2 причинам.

1. В 90-ых хорошо продавалась моя бухгалтерия, оптовая и розничная торговля.
Практически все крупные и некоторые средние фирмы Орла работали на ней.
Продавал я ее от 1 -5 тыщ зеленых, потом сопровождение копеечное и новые фичи за деньги (от 300-500 баксов)
Набралось общих продаж под 100 и единовременно на обслуживание бывало 10-15.

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

Первая причина - надо не демпинговать (а тогда скорее всего и ничего не продашь) и основного разработчика не посылать на обслуживание по возможности (т.е. хотя бы 2 чека должны хорошо разбираться во внедрении и обслуживании).
Т.е. денег должно быть столько что бы можно было бы кормить минимум 3 человек на машинах(+ всякие там бухи и т.д. объязаловка)

2. В 09 году начал писать ВИП.Производство как наемник, но сам себе дирижер.
Команда не набралась, хотя прогеры были.
Многие просто не понимали и не понимают зачем нужен Фреймворк, когда можно быстро накидать формы на экране и сделать прогу "покрасивше".
Грю - тупица в БД 1500 табличек (700+ понятий), ты не можешь знать все связи и т.д. этих понятий, а он - я работаю всего с двумя.
Вощем качественных прогеров трудно найти, а обучить дело долгое и нехорошее (уходят).

А так причина №2 - когда есть реальный заказчик на небольшие проги без требований иметь общую концептуальную часть - никакой Фреймворк не приживется, так как такие проги программисты пишут быстро и обычно "покрасивше".
Фреймворк нужен для большого проекта, где прогер не может разбираться во всем проекте.

А так - что бы что то продать надо иметь деньги, связи, время.

7bitЯ, например, занимаюсь только разработкой программы, написанием документации и поддержкой на форуме. О том, как заработать, я даже не хочу думать, потому что это отнимает слишком много времени. Сейчас, самое главное, довести проект до нормального уровня - запал и интерес есть. Для меня наверное самое трудное - это решиться на командую разработку. Уже получится не свой проект, а общий и придется считаться с мнением других участников. На данный момент меня поддерживают несколько человек - помогают на форуме, создают расширения, делятся своими идеями.
"Нормального уровня" никогда не будет. Это дело кто то должен со стороны контролировать. Сам никогда не остановишься.

MoroZ.RuПервое, что необходимо при командной работе - это принять чужой код, не обсирать его сразу. Глядя, как dbpatch и LSV полощут друг друга, видно сразу, что у нас с этим проблема.
Командная работа - это не всегда командное программирование.
При написании фреймворков и т.д. много прогеров нафиг не нужно, тем более с "собственным кодом" который над почему то принимать.
Я всегда быстрее напишу, чем приму.

LSVНу почему-же ? Простые проги всегда имеют тенденцию к усложнению. Особенно когда есть такая возможность. Именно тут ФВ и выручит: берем готовый каркас (склад, кадры, CRM, лояльность, биллинг и пр.) и допиливаем нужные фичи.
Можно довольно быстро получить готовый прототип и начинать с ним работать при этом допиливая и отлаживая.
У такого проекта не будет финала: всегда будет что доделать, доимпортить и дорепортить.

ФВ жизненно нужен для постоянно эволюционирующих проектов в "стандартных" областях учета.
Для ИТ-команды, занимающейся автоматизацией ФВ тоже жизненно нужен, т.к. он унифицирует разработку и позволяет быстро делать миграцию ф-ла из проекта в проект, иметь 5-10-20 ветвей проекта в похожих областях.

Я видел это много раз.
Пришел заказ. Что бы автоматизировать "все такие заказы" (класс задач) в будущем надо Фреймворк дорабатывать (ну неделя от силы).
Дорабатывать могу ТОЛЬКО Я! Потому что другим это и в голову не приходит - автоматизировать класс задач.
Зато им в голову приходить написать отдельную прогу используя общую концептуальную часть, практически за ту же неделю.
Но, так можно одновременно писать много разных задач! Так как много таких прогеров!
То, что потом все это аукнется всем пофиг, особенно начальству.
Ему второй вариант выгоднее, он отвязывается от меня в плане зависимости и реально быстро клепает до поры времени много "задач".
А когда будет х..во, всегда можно валить на меня! Фреймворк хреновый, базовая часть не дает и т.д.
Вощем люди нашли как объехать камень, которую. не могут осилить поднять.