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

Далее, каждый разработчик пишет свой блок в соответствии с техзаданием и АПИ. Обычно сначала делаются только заглушки на каждый элемент АПИ, чтобы можно было хотя бы получить модули.
Окончив очередную работоспособную версию, разработчик отдает готовые модули, которые сразу же получают остальные разработчики.

В идеале повторяется только последний пункт - я пишу пару функций, которые реализуют некоторую функциональность, отдаю всем промежуточный результат, и продолжаю писать дальше. Также я получаю время от времени чужие модули с возрастающей функцональностью. Каждый разработчик имеет только свой код, чужие готовые модули и АПИ. Работать можно, а узнать, что там внутри - затруднительно.

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

И еще: Вы хотите доверить написание проекта по кускам людям с улицы, которым не доверяете и которых никогда не увидите. Это значит отсутствие лояльности и заинтересованности в проекте у разработчиков. Плюс, разработчики не представляют себе полных масштабов и часто будут по незнанию принимать ошибочные или неоптимальные решения. Все это очень сильно снижает шансы на успех. Для более-менее крупного проекта шансы на успех ниже 50%. Рискуете задушить свою мечтуДаже если нанять за копейки несколько толковых студентов и контролировать их работу, надежд гораздо больше. Вряд ли они сопрут ваш результат: они без опыта в таких делах не найдут, как реализовать украденное.

Думаю хорошей идеей будет разделить исходный код на публичную и непубличную части.
Как правило, в любой программе есть относительно небольшое ядро, некоторая центральная функциональность, которая и представляет наибольшую ценность. Остальное - это вспомогательный код, по большому счёту никому не интересный.
Поэтому ядро программы можно сделать закрытым, например вынести в отдельную DLL со своим интерфейсом. А остальная часть кода станет открытой, то есть полностью доступной фрилансерам. Поддержку ядра придётся оставить себе, либо найти человека, которому можно доверять.
Для командной работы в любом случае придётся организовать репозиторий. Разделение кода в нём можно реализовать через права доступа или просто не выкладывать закрытую часть в общий репозиторий.

Пока бюджет планируется 15-20к рублей в месяц, поэтому более чем на одного человека рассчитывать не приходится

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

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

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

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

А что Вы под билд-системами понимаете? Я имела дело с CMake, например, но он, в принципе, не особо связан с разделением кода. У нас на работе, например, репозиторий svn и cmake для сборки, но там, понятное дело, не надо ограничивать доступ.

например, сервер hudson связывается с SVN, пользователь редактирует доверенный ему исходник, комитит его в SVN, пинает хадсон и получает на выходе исполняемую программу, чтобы проверить рабочесть нужной функции. Я то могу и заглушек наделать и все остальное, только специфика моей программы такова, что там так или иначе надо будет делать соответствующие изменения в ядре, в некоторых частях его. Головной боли будет столько, что сам не порадуюсь что затеял это. А это доверил какие-то новые вещи отрабатывать в каком нибудь имровизированном диалоговом окне, потом разработчик когда уже уверен, что функция работает, комитит в реальный проект и дальше смотрит, как программа в целом работает. Наверняка будут и люди, которым я доверюсь, но для этого нужно время. Я вообще не жадный, предпочитаю заплатить побольше, но чтобы покачественнее было. Пусть лучше не в фултайме, а сколько там их стоит рабочий день, соответственно этот бюджет времени пусть и будет + я еще сверху чуть добавлю "на хорошую погоду" так сказать.

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

Кто будет заниматься вырезанием-возвращением кода и тестированием после возвращения?
Ведь нет никакой гарантии, что доработанная версия после возвращения кода заработает нормально. Рано или поздно это выльется в конфликт с разработчиком, что в вырезанной версии всё работает, а в полной - нет.

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

Я работал с hudson как пользователь. Думаю, то что вы описываете можно сделать, но непонятно зачем.
Разработчику будет очень неудобно постоянно протаскивать все изменения через SVN + buildserver. При работе с незнакомым кодом редко получается сделать даже простые вещи с первого раза. Во время отладки часто бывает необходимо проверить какое-то предположение, или просто получить ответ на вопрос "что будет если я напишу вот так?". При наличии локальной сборки это можно сделать за минуту, а через билдсервер придётся полчаса курить бамбук :)

Рано или поздно это выльется в конфликт с разработчиком, что в вырезанной версии всё работает, а в полной - нет.

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

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

Некоторые так и делают а ещё даже копируют сопутсвутющие блоги и форумы, вставляя там новые названия и ссылки на склонированный софт!
Пользователи зачем лицензии подписывют при установке? Про то что "не разбирай, не декомпилируй, иконки и текст не меняй" и т.д. Именно, чтоб не воровали. Я давно в софтопроизводстве, код тырят очень запросто. Что касается DLL, если она уже отлажена, то с ней всё ещё проще, посмотреть таблицу экспорта, написать оболочку - и всё! А если exe-файл то его ещё править придётся.

Ага, поэтому всё упирается в правильную архитектуру приложения

Конечно, с хорошо спроектированным приложением проще решать какие вопросы. Но в реальном мире приходится иметь дело с тем, что есть. Выделения ядра - первый шаг к правильной архитектуре.

Некоторые так и делают

Это ничего не меняет. Кто захочет склонировать продукт на бинарном уровне, тот сразу возьмёт дистрибутив.
Идиотов, пишущих оболочку для чужой DLL, не так много

Но в реальном мире приходится иметь дело с тем, что есть.

Ага, вот как раз автору ветки и предстоит улучшать реальный мир

Ну что, продлевать вопрос или пусть закрывается?

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