Прибыль и передача прав на ПО. Какой из вариантов лучше?

Давайте обдумаем все возможные варианты зарабатывания на софте:

Сейчас прибегут фанаты «свабоды!» и начнуть тебе доказывать, что прибиль от ПО - фигня, и кодить надо только во имя луны! ради свободы и всего такого прочего.

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

3 - почему бы и нет?

Разве нет таких желающих, чтобы было свободное ПО?

4. Программист устраивается на постоянную работу со стабильной и фиксированной зарплатой, и пишет софт на дядю Васю, а тот решает, как его продавать.

5. Программист и есть заказчик. Он продает софт сам/зарабатывает на рекламе в софте.

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

А не с точностью ли до наоборот?

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

Нишевое ПО вполне может быть свободным и коммерческим — свобода помогает завоевать рынок, а крупным компаниям выкладывать ежемесячно копеечку за поддержку часто много проще, чем иметь перспективу в случае чего копаться в потрохах программы самим.

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

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

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

К стати, еще можно залепить библиотеку под двойным лицензированием. AGPL+коммерческая. Правда не думаю, что в России такой вариант будет прибыльным, т.к. хрен докажешь, что проприетарное ПО использует библиотеку под лицензией AGPL

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

Совсем не обязательно. Мой фреймворк вообще не популярный, от силы пара человек использует (за пределами моих проектов). Однако, опенсорс. И, однако, на хлеб с маслом хватает :)

2. Заказчик кроме ништяков получает неочевидные юридические риски. Экономия неочевидна, определенной цены за готовые проекты на рынке все равно нет.

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

Мой фреймворк вообще не популярный,

что за фраемворк?

Борсщчщс на PHP

Почему выкладывается только в дальнейшем?

Что бы раньше времени не форкнули и не начался срач в переписывании с ЯП на ЯП и прочие глупости.

UPD:

К стати. Пункт №1 можно усовершенствовать в пользу опенсурса. Достаточно самостоятельно разработанные библиотеки, используемые в продукте выпускать под двойной лицензией. Коммерческой за деньги и AGPL для опенсурса. Тогда в стоимость готового продукта входят затраты на приобретение лицензий на необходимые библиотеки, но права на них не передаются.

Что бы раньше времени не форкнули

Тогда лучше такой фигней не страдать

Заказчик финансирует программиста на разработку ПО, которое в дальнейшем выкладывается под свободной лицензией // пожалуй самый нереальный для России вариант.

Я в какой-то другой России работаю. Последние пять лет - почти исключительно в опенсорсных проектах.
Конторы, правда, заокеанские.

3. Годно для популярного массового софта.

И наоборот - в лютом ынтырпрайзе тоже.
В последнем денег больше.

Последние пять лет - почти исключительно в опенсорсных проектах.

Эт какие например?

Так получается что опенсурсная схема вполне прибыльная?

Эт какие например?

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

получается что опенсурсная схема вполне прибыльная?

Cофт сам по себе не работает. Если ты допиливаешь к примеру, линукс до нужного тебе состояния, ставишь на свою железку и внезапно эта железка оказывается востребована рынком - то таки твои программисты зарабатывают на опенсорсе. Они даже патчи Линусу отправят чтобы самим ядро по сто раз в день не пересобирать. И он даже может быть их примет. Хотя потребителю будет трижды плевать на то, линукс там внутри или килька в томате
Либо ты Suse/RedHat и продаёшь поддержку - тоже вариант.
Ещё можно забабахать свой опенсорсный блекджек, а потом его дорого продать. См. MySQL например.
Лор-вариант - делаешь самый-самый свободный линупс одобренный лично RMS, кричишь на всех углах о свободе-свободе и живёшь на подачки гранты FSF. Чучело антилопы приносить своё.
Большинство же пишут мегакрутой просмоторщик картинок с кнопкой Donate и ругаются какие все юзеры, оказывается, мудаки.
Так что варианты есть.

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

Это называется пойти на заведомо невыгодные условия.

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

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

Немаловажно обстоятельство что в случае GPL потребитель обязан выкладывать свои правки при деплое.

Остается проблемной закрытая часть тем не менее. Но меньшее зло открыть нежели наоборот...

в случае GPL потребитель обязан выкладывать свои правки при деплое

Что вы здесь держите за «деплой», если не секрет?

GPL к заноза в некоторых обстоятельствах, не так ли?