как правильно продавать опенсурц?

1. как теперь разграничить ответственность «наше» от «их», когда оно все вдруг падает?

Для этого придумали брендинг. Если клиент модифицирует сырцы - должен удолить все логотипы. Или как-то так. Я вообще далек от этой темы.

2. а как это обновлять?

Обновлять в обычном режиме.

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

очень хочется продавать опенсурц, но чет пока непонятно как.

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

Только продаться корпорастам, перейти на пассивный доход и забыть про все это вот.

что сделали: придумали ворох либ, на них построили прикладные прилажухи, успещно продали и все вроде работает.

Так это вы написали KDE 5??

Отдавать бесплатно, свободно, всем желающим: сорцы.

Раздавать клиентам: благословенный бинарь и/или воспроизводимый ебилд, собирающийся в благословенный бинарь

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

Все остальные варианты более-менее невозможны.

открыть массажный салон например..

Версия с дивана:

1. в багрепорт автоматически включать sha256 сумму приложения или информацию о времени и хосте сборки (если система сборки это позволяет)

скрипт для первого уровня техподдержки: наша или ваша сборка?

price: отладка вашей сборки за вас - 5 офигеардов денег / час

2. принимать merge request’ы обратно, если фича будет полезна кому-то ещё. ну или может если идея лучше реализации, то отклонять и добавлять в todo

3. обычно у клиента нет задачи модифицировать код just for fun, а он решает какую-то прикладную задачу

Если получится отделить область интересов клиента и добавить соответствующий API, проблема с падением приложения превратится в проблему с падением клиентского модуля без падения приложения в целом. Окно или строка в логе с человеческим текстом, и запросов на поддержку будет меньше

что вы тут нам втираете?

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

«ваше» это только когда в работе бинарники собранные вами сконфигурированные по инструкции(а желательно работающие в опечатанном железе или вашем же облаке, вобщем как у серьезных парней типа Dell или IBM). Если где-то не работает это надо вопроизвести вашими силами. Если не воспроизводится значит не работает не ваше. Если все-таки требуют разобраться, выезд специалиста на дом или его работа телематически тарифицируется почасово в независимости от других подписанных бумажуль.

открыть массажный салон например..

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

а как это обновлять? вот мы придумали МР, вот мы его толкнули и….? кто должен разрешить 100500 конфликтов с доработками у клиента? мы как поставщики обновления? пупок развяжется к каждому клиенту ходить. клиента сам? так он нарукожопит еще больше и станет хуже.

В идеале, продукт нужно делать расширяемым через плагины. Тогда вокруг него сформируется экосистема дополнений и компаний-дополняторов.

Если кто-либо дорабатывает само ядро — это уже форк. Вы за его поддержку уже отвечать не должны.

Продавать можно:

1. платную поддержку

2. доработку ядра под нужды конкретного заказчика

3. написание расширений

4. курсы и сертификации для разработчиков

5. партнёрские программы

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

очень хочется продавать опенсурц, но чет пока непонятно как.

Продаются услуги связанные с открытым софтом: доработка, внедрение, сопровождение. Сам код очевидно что не продается.

что сделали: придумали ворох либ, на них построили прикладные прилажухи, успещно продали и все вроде работает.

Т.е. продали готовое решение под конкретного заказчика, наверняка еще и по договору заказной разработки. Вы вообще уверены что теперь ваш «ворох либ» вам вообще принадлежит? Если этот момент специально не обозначен в договоре то все: у вас два набора кода. Один ваш, второй - заказчика.

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

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

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

В таких случаях я делаю доработки строго в переданном исходном коде (либо в текущей версии заказчика), без гарантий и на почасовке.

как теперь разграничить ответственность «наше» от «их», когда оно все вдруг падает?

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

Если на стороне заказчика занимаются доработкой вашего софта - с вашей стороны гарантийные обязательства заканчиваются и начинается банальная почасовка.

чет пока непонятно как

я вообще думал это бесплатно

1. Отдавать в собранном виде с поддержкой за денюжку, а сорцы отдельной ссылкой, не?

2. Обновлять опять же в бинарном виде

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

вроде же все давно уже придумано, не? или я не совсем задумку понял?

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

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

Если клиент модифицирует сырцы - должен удолить все логотипы.

Многие лицензии опенсорца явно и категорически запрещают такое делать.

Панда вроде как работает по такому принципу

Панда? Это лицензия?

https://www.gnu.org/licenses/license-list.html

https://habr.com/ru/articles/243091/

https://www.mozilla.org/en-US/foundation/trademarks/policy/

А, я не так Вас понял. Вы про логотип, а я про шапку в сырцах.

Ничего страшного.

такое наверно где-то уже есть? как это принято делать во взрослом мире?

Unreal Engine поставляется в исходниках уже давно. Обновления могут быть максимально болезненными для клиентов (при мажорных апдейтах).

Мой опыт использования - чуть больше 5 лет. Какие моменты могу отметить:

1. Есть календарных график мажорных релизов - раз в квартал выходит новая мажорная ветка 4.x раньше и 5.x сейчас.
2. В рамках одной версии движка (4.x или 5.x) фичи не удаляют
3. В рамках мажорного обновления фичи могут зарефакторить и клиентский код нужно править. Правки клиентского кода - на клиентах.
4. Доступ к исходникам получаешь приняв правила использования в которых прописаны права и обязанности клиента.
5. Бекпортирование фиксов в предыдущие мажорные версии идет в течении 1-2 следующих релизов (обычно, раз в 6 месяцев выходит поддерживаемая версия)

Итог: Есть две стратегии - обновлять версию движка почаще (3-6 месяцев) или фризить ее и бекпортировать фичи самостоятельно. Фризят, обычно, перед релизом. Обновляются - в течении основного этапа разработки (за счет прогнозируемости мажорных релизов на это можно закладывать ресурсы заранее).

nice try товарищ военком, но в следующий раз.

как теперь разграничить ответственность «наше» от «их», когда оно все вдруг падает?

Если MD5 от ВСЕХ бинарей и библиотек совпал с вашей сборкой - это ваша проблема, иначе это проблема клиента.

кто должен разрешить 100500 конфликтов с доработками у клиента?

Клиент. Он платит вам за то чтобы вы ему собрали и предоставили. Если он собирает сам - это его проблемы.

теперь решили как минимум приложухи продавать в сырцах

А причём тут open source?

Взрослые компании вроде Vector или Elektrobit тоже поставляют исходные коды к своим дистрибутивам AUTOSAR, но open source там и не пахнет.

EDIT:

как теперь разграничить ответственность «наше» от «их», когда оно все вдруг падает?

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

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

потому что «они» строго всегда начинают с того, что «ваше не работает»

Мы обычно решаем через тех.поддержку того же Vector’а в случае, если после отладки на нашей стороне мы выясняем, что проблема в их дистрибутиве/драйверах: (а) тикет в тех.поддержку, (б) обсуждение с отладкой/доказательством и (в) внедрение пропатченой версии от Vector.

продажа ТП (чем быстрее реакция, тем дороже) и курсов по использованию.

1 собирать проект у себя в виде двоичной «библиотеки» (чтобы не патчили ваш код) и передавать кастомеру для внедрения собственных доработок. Коммерческая работоспособность гарантируется только с официальными сборками.

2 как обычно: минорные и мажорные версии api, гайд по переходу между мажорными версиями для кастомера.

Такое есть у 1С.

Конфигурации продаются с полными исходниками.

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

2. Есть штатный механизм, позволяющий пользователю для метаданных выбрать «версия поставщика», «версия наша», «попробовать объединить». Для исходников объединение использует kdiff3.

Выглядит примерно так: https://pmkt.ru/image/catalog/pages/%2018.png

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

Шутка

Это да.
ТС осталось лишь «раскрутить» свою фирму а-ля 1С и всё будет «чики-чики».

Ты будешь смеяться, но в начале 2000-х 1С выбила всех конкурентов именно открытыми исходниками и щедростью по отношению к партнёрам.

У конкурентов были более функциональные решения, но поддержка только централизованная. 1С выдавала конструктор а-ля Linux с открытыми исходниками, отдавала 40% от розничной стоимости партнёру и почти все деньги за сопровождение партнёру. В результате, через пять лет конкурентов практически не осталось.

У конкурентов были более функциональные решения, но поддержка только централизованная.

Это бескрайняя тема для обсуждения ...

Шутка

Это прекрасный пример умелой раздачи «бесплатного сыра».