Пропускаем картинку для привлечения внимания
Лицензирование и монетизация сегодня
Для чего вообще нужен открытый код? Открытый код необходим для интенсификации развития мировых технологий. И это главное. Открытый код позволяет соединять идеи разных людей и создавать новые проекты малыми командами. Да, черт возьми, эти программы не идеальны, но продукты создаются за более короткий срок и с меньшими затратами, чем если делать всё с нуля. Сделали, проверили на практике, получили обратную связь от пользователя и отлично, работаем дальше. Открытый код позволяет, в случае чего, подхватить выпавшее знамя и нести его дальше.
Теперь о лицензиях. Крайние полюса — это GPL, которая всячески препятствует программисту в защите своих разработок, и проприетарное ПО, с закрытым исходным кодом и в довесок с юридическо-административным аппаратом. Остальные модели лицензировании болтаются где-то в эпсилон-окрестностях. Мне же кажется, что истина где-то посередине.
Зачем придумывать что-то новое, скажете вы, вот, мол посмотрите как все классно у Линукса. Система развивается, все хорошо, вокруг операционки крутятся компании, зарабатывают бабки, некоторые даже особо отличились. Но если присмотреться внимательнее, то увидите, что основной вклад вносят крупные корпорации Intel, Red Hat, Samsung, IBM и т.д. К тому же, Red Hat продает свой Enterpise, как бы завуалировано это не звучало: вы покупаете пакет услуг, но если не нравится, то берите другие дистрибутивы ибо, внезапно, корпоративное соглашение Red Hat дополняет универсальную общественную лицензию GNU GPL.
Если рассмотреть рынок открытых CMS, то ситуация усугубится, с одной стороны, уменьшением масштабов, в с другой стороны большой вариативностью функций. По этим причинам крупные игроки даже не рассматривают подобные рынки. Такого рода проекты живут на пожертвования и основные платежи идут от компаний, бизнес которых основан на использовании данного продукта. Для основателей такой проект интересен только в том случае, если есть сопутствующий бизнес, базирующийся на этих же технологиях. Вклад сторонних разработчиков в код может быть существенным, но не определяющим.
Приведу слова Сергея Голубева:
“Открытая модель способствует вовлечению в разработку бесплатных помощников, но не гарантирует проекту прибыли. Закрытая — способствует получению денег, но исключает создание сообщества. И то, и другое — неэффективно, поэтому реалии требуют нахождения баланса интересов.”
В качестве примера рассмотрим ситуацию с Drupal: декларируется наличие тысяч готовых модулей на все случаи жизни, но активно разрабатываются лишь сотня-другая, остальные заброшены, потому что разработчики не мотивированы их поддерживать и, зачастую, написаны модули под какую-то частную задачу, а выложены просто из-за повышенного чувства собственной важности.
Еще вопрос: почему же руководители веб-студий зачастую используют платные CMS, когда можно использовать бесплатные? Может потому, что им так проще организовать продажи и окупить зарплату продавца уже на этапе продажи коробки, а может он действительно получает лучшее качество продукта?
Устройство рынка
Для примера возьмем всем известный рынок сайтостроения. Клиентским бюджетом распоряжаются веб-студии и справедливо оставляют себе основную часть пирога:
И из этого пирога разработчикам достается мизерная часть или совсем ничего, если это открытый и бесплатный софт :(
Как же выкручиваются производители бесплатного ПО:
- Самое очевидное: сами занимаются созданием сайтов;
- Предоставляют бесплатное решение в облаке. Клиенты: частники и малый бизнес. Выжить можно только за счет массовости.
- Подбирают прочие крошки со стола, например, темы оформления. Не особо устойчиво, всё равно переделывать под конкретный проект и поэтому проще содрать идею, чем платить.
- Обучение, консалтинг. В России с этим несколько сложнее.
- Предоставление платных версий бесплатной программы. Тут проблемы с лицензированием и защитой от воровства. Код-то открытый.
- Платные инструменты для работы с бесплатным ПО, например, среда разработки.
- Ну и для полноты модели: продажа железа, рекламы и данных (не код)
Большинство открытых лицензий не запрещают продажу, но и никак не помогают заработать на этой продаже автору программы. Все осложняется еще тем, что авторов может быть много. Таким образом, наблюдается некое противоречие: для мирового сообщества важно иметь открытые проекты, но финансовый механизм вовлечения широких масс разработчиков не реализован.
Становится понятно, что не существует идеальной системы лицензирования для всех случаев жизни. И платное-закрытое нас не удовлетворяет, и бесплатное-открытое не дает возможности себя реализовать.
Экосистема открытого сообщества будущего
Давайте перейдем к конкретике. Для примера возьмем разработку некого фреймворка для многофункциональных бизнес-систем. Она может включать коммерцию, управление бизнес процессами и сотрудниками, создание сообществ и т.д. Причем, не отдельные куски типа CMS, CRM, а объединенную единой логикой систему (операционную среду для бизнес-приложений).
Как создать условия, чтобы разработчики отдавали на открытый рынок свои наработки и знали, что каждое использование принесет им определенный доход, но, в то же время, затраты на разработку должны быть минимальны? Вполне жизнеспособным вариантом может оказаться идея, что ядро фреймворка должно быть совершенно бесплатным, а решения и модули платными.
В реальной жизни существуют следующие процессы:
- Разработка архитектуры фреймворка и базовых решений.
- Разработка модулей и решений.
- Распространение (продажа) кода.
- Обновления кода.
- Хостинг.
- Облачные услуги.
- Контроль соблюдения условий лицензий (авторское право, воровство).
- Внедрения, консалтинг, обучение, сопутствующие услуги, например, продажа дизайна.
- Эксплуатация.
Придется создать целую экосистему, где множество игроков будут эффективно взаимодействовать между собой, но архитектура и ядро системы должны быть создано централизованно.
Сам фреймворк следует сделать бесплатными для увеличения охвата рынка. Должны быть разработаны базовые решения с минимальным функционалом, бесплатные и условно платные (совершенно недорогие). Разработчики могут создавать модули для решений и свои альтернативные решения (не сборки). Распространение и продажа решений и обновлений осуществляется централизованно. Доход распределяется между всеми участниками процесса.
Схема распределения финансов
Для начала следует ввести такое понятие, как владелец модуля, даже бесплатного. Авторы и соавторы — само собой, но должна быть информация о человеке или организации, которая берет ответственность за поддержку и развитие функционала. По умолчанию, автор является владельцем, но он может отказаться от владения, если не готов дальше вкладывать свои усилия. Другие разработчики могут вносить изменения в модуль, а владелец занимается модерацией, продвижением и получением дохода, но делиться с другими будет на своё усмотрение.
Разработка
Разработчики создают отдельные модули для для своих или чужих решений, назначают им цены. Естественным механизмом регулирования цены станет конкуренция со стороны других разработчиков. Цена должна быть такой, чтобы разработчику решения или сборки выгоднее и быстрее было включить в поставку чужой модуль, чем писать свой. Это может выглядеть, например, так:
владелец модуля получает 60% от выручки за минусом скидок и налогов.
разработчик решения получает 10% от продаж специализированных модулей созданных для этого решения другими разработчиками.
Сообщество (некоммерческая организация) получает остальное.
Внедренцы (продажники). Для профессиональных игроков рынка предусмотрены особые условия (скидка), по которым они продают решения конечным потребителям. Таким образом, они получают выгоду уже на стадии продажи, аналогично продажам коммерческих продуктов.
Облачные сервисы. Некоторые (лицензированные) организации будут предоставлять услуги в облаке. Им также потребуются особые условия.
Некоммерческая организация тратит деньги на маркетинг, управление сообществом, оплату работ программистов, создающих ядро и базовые решения, а также может поощрять в ограниченном размере других разработчиков.
Поддержка
Большую часть функционала необходимо обновлять и развивать. Доход от продажи мотивирует поддерживать код в хорошем состоянии, но эти потоки могут быть неравномерны, а пользователи, которые установили модуль всегда хотят улучшений. Может возникнуть ситуация, когда разработчик не заинтересован в поддержке модулей. В таком случае, для выравнивания денежных потоков применяются регулярные платежи за обновления.
Дополнительно необходимо ввести новый вид услуги, который позволит продавцам (например, облачникам) давать более-менее приличные SLA. Т.е. разработчик не просто делает модуль и пытается заработать на нем денег по старинке, а обещает второй вариант поддержки, который сложнее, но позволяет зарабатывать больше.
Мысли по организации
Система со множеством независимых субъектов очень сложна. Тут еще возникает ряд вопросов по организации справедливого процесса оценки вклада каждого участника сообщества. Для управления ею необходимо создавать сильный институт, стоящий на страже правил, обеспечивающих эту модель. Подобные системы имеют генетический код, который задали их создатели. Проблема в том, что эти же создатели и в дальнейшем определяют развитие платформы, но время уходит и рынок меняется, а человек уже не так “голоден” как когда-то.
Нужна некоммерческая организация, целью которой является обеспечение устойчивого развития проекта и максимальная доступность для потребителей при достаточном ресурсном обеспечении. Такая организация должна быть предельно открыта для своих членов. Можно принимать ряд решений путем онлайн-голосования. В то же время, для системы все равно нужна личность, которая через свою энергию обеспечивает развитие платформы. Вопрос состоит в том, как обеспечить выдвижение действительно лучших людей на ведущие позиции, избежать тупости, злоупотреблений, имитации деятельности и бесполезного политиканства?
Я считаю, что нужно не бояться пробовать создавать сбалансированные организации, в которых сочетаются текущие интересы общества и прозорливость лидеров, в которых открытое бесплатное ПО нормально соседствует с платными дополнениями и услугами. Согласны ли вы, что возможно создать более эффективную открытую модель разработки и лицензирования?
Кто готов сделать что-нибудь в этом направлении? А что именно?
Комментарии (36)
lpre
17.04.2017 20:49+3GPL, которая всячески препятствует программисту в защите своих разработок
А что вы имеете в виду под защитой своих разработок?
Если это защита от воровства кода, то GPL (или AGPL, если речь о сайтостроении) вполне неплохо защищает разработчика от воровства кода проприетарщиками. Многие крупные компании даже ввели внутренние правила для своих разработчиков, согласно которым использование OSS модулей/библиотек, распростроняемых под GPL (часто даже LGPL — на всякий случай), в корпоративном софте запрещено. Чтобы проблем с лицензированием не возникало. Так что в этом направлении GPL работает хорошо.
IvanKlut
18.04.2017 08:20Наверное плохо донес мысль. Имеется в виду защита потенциального заработка автора при распространении кода.
flancer
18.04.2017 08:36В голову сразу же приходит:
Аналогичное:
- https://marketplace.magento.com/extensions/accounting-finance.html
- https://www.odoo.com/apps/modules?price=Paid
Вряд ли удастся создать единую глобальную схему финансирования разработок (подобную вышеупомянутым app/google stores или marketplaces) путем централизованной разумной деятельность как раз в силу аморфности представлений о конечном результате, сложности решаемой задачи, наличия различных "векторов развития" темы, конфликтов в желаниях различных персон и организаций "оседлать движение" в случае его успешности.
Скорее всего так и будут рождаться локальные marketplace'ы вокруг достаточно крупных "нишевых" решений (magento, odoo, ...), пока их кол-во не позволит выделить некоторые общие принципы подобных структур и заложить несколько вариантов базовых лицензий, определяющих правила распределения дохода между всеми участниками "пищевой цепочки" (начиная с "продажников" и заканчивая разработчиками фреймворков). После чего вокруг этих базовых лицензий могут начать кристаллизоваться девелоперские сети (централизованные или пиринговые) со своими электронными платежными системами (paypal'ы, биткоины и т.п.), которые позволят автоматизировать отчисления по иерархии (разрабочикам фреймворков/билиотек/модулей/тем, интеграторам, менеджерам проектов и т.п.) в соответствии с условиями базовых лицензий.
Ну а потом пойдет "дарвиновская эволюция" между этими решениями — с "размножением" лучших вариантов и отмиранием худших. Сомневаюсь, что удастся поставить подобные процессы под контроль "коммерческой организации", особенно на раннем этапе развития — слишком неочевидны механизмы, которые позволят не упустить предполагаемую выгоду после запуска "девелоперской экосистемы" (когда отработаны все неизвестные и становится понятным, как эта экосистема должна была строиться изначально). А когда станет понятно, что и как нужно было делать, пирог начнут делить финансовые монстры и будет все, как обычно.
Но если не ставить себе целью взять процессы под контроль, то вполне можно весело поучаствовать в подобном движе на любом из его участков, т.к. разработка ПО как раз и дрейфует в направлении к "девелоперским экосистемам", IMHO.
IvanKlut
18.04.2017 08:40Сильный комментарий, нужно будет позже перечитать, подумать над ним.
flancer
18.04.2017 13:57-1Спасибо за высокую оценку, коллега.
Я некоторое время уже думал над подобными вещами — монетизация труда разработчиков. И пришел к выводу, что будущее за структурами, подобными AppStore, Google Play, Itinity Marketplace, etc. Правда я на это дело смотрел больше с точки зрения девелопера — в каком виде подобная структура могла бы функционировать. А вот с точки зрения лицензирования не смотрел. А ведь это весьма важно — именно в лицензии закладываются базовые ограничения на "скелет" подобной структуры.
Подумав несколько над этой стороной вопроса пришел к выводу, что в лицензию (типа MIT или ей подобную) нужно ввести ограничение на монетизацию. Типа, бесплатное использование кода допускается, но, если происходит монетизация кода, использующего данный, то получение денег от конечного пользователя возможно только через платежный сервис, указанный в лицензии, с отчислением части оплаты разработчикам данного кода согласно правилам указанного сервиса.
Т.е., формируются кластеры на основе некоторых сервисов, представляющих из себя симбиозы github'а, composer/npm/maven'а, webmoney/paypal'а и twitter/habr/facebook'а (доступ к коду, ввод-вывод денег, учет популярности). Разные кластеры позволяют монетизировать код согласно различных схем учета популярности базовых модулей и различных схем распределения дохода от него. Одна библиотека/модуль может проходить через разные кластеры, самое главное, чтобы оплата проводилась как минимум через один из кластеров, на которых эта библиотека/модуль представлены.
Например, 10% от платы за поддержку (support) готового приложения направляется в кластер (распределяется между всеми разработчиками, чьи модули вошли в приложение, и на поддержание работы самого кластера). То же самое касается внедрения/консалтинга/обучения и т.п. — в кластер добавляются сайты типа freelance.com. Каждый, кто каким-то образом заработал что-то на каком-то приложении, входящим в кластер, должен отдать часть дохода в сообщество. Вернее, даже так — все оплаты должны проходить через платежную систему соответствующего кластера, который по соответствующему алгоритму делит доход между затронутыми в разработке модуля участниками.
Я могу продавать через кластер модули для Magento/Odoo/Intinity/Drupal/… при этом отчисляя процент (допустим, 20%) в пользу той платформы, для которой предназначен мой модуль. Или выкладывать универсальные библиотеки (npm/composer/maven/...), которые могут быть использованы кем угодно и где угодно с одним условием — "вся оплата, получаемая за использование любого продукта, использующего данную библиотеку, должна проходить через один из указанных кластеров с отчислением части оплаты в пользу участников кластера".
Далее часть оплаты, причитающаяся кластеру, делится в каких-либо пропорциях между всеми разработчиками, имевшими отношение к созданию и поддержке всех модулей, составляющих приложение. С учетом того, каким образом можно отслеживать авторство кода на github'е, алгоритмы расчета этих пропорций могут быть весьма "кучерявыми". Более того, одни могут стимулировать активность разработчиков, вторые — интеграторов, третии — эксплутационщиков. Механизм лицензирования должен предоставлять возможность продуктам использовать множество кластеров одновременно и ограничивать использование этого продукта в других кластерах (например, запретить распространять через определенный кластер новые версии).
Принадлежность разработчика какому-то модулю определяется через тот же github (contributor), вклад разработчика в модуль определяется самими разработчиками (владельцем проекта) или на основании каких-либо метрик. Тут уже можно играться в "веса" и "коэффициенты". Алгортимов расчета вовлечения в проект и распределения прибыли возможно придумать достаточно много. Самое главное, чтобы соблюдался базовый принцип: "вся оплата за использование продуктов, производных от данного, должна производится через один из кластеров с отчислением некоторой части в пользу разработчиков продукта по правилам кластера". Ну и чтобы не было злоупотребления ни со стороны кластера, ни со стороны разработчиков (разработчик может в любой момент добавить кластер, через который продвигать свой продукт, добавленный в кластер продукт не может быть изъят из него, но разработчиком могут быть закрыты обновления продукта для этого кластера).
Жизнеспособность данной схеме может в какой-то мере гарантировать подход, чтобы у разработчика было как можно больше вариантов выбора продвижения своего продукта в различных кластерах с различными политиками, а у кластеров — возможность появления различных политик (возможно, заложить условие, что новый кластер может агрегировать оплаты для любых модулей, находящихся под этой лицензией, если только автор модуля в явном виде не указал обратного). В таком случае эволюция сама вынесет на поверхность наиболее жизнеспособные комбинации.
На всякий случай акцентирую внимание, что мое предложение не ограничивает бесплатное использование продукта. Ограничивается именно способ получение дохода таким образом, чтобы можно было наиболее простым способом "взять все, да и поделить" (с). Ну, или не простым.
SergeyUstinov
18.04.2017 15:39Очень все сложно и НЕПРОЗРАЧНО.
Главное отличие от AppStore, Google Play, etc. — там человек платит денежку и сразу может использовать то, за что заплатил (слушать песню, играть в игру...).
С модулями для автоматизации сейчас все не так — их еще надо и внедрить, при этом часто изменив (как минимум настройки, но регулярно и код надо «допиливать»).
И в результате такая схема не сработает.flancer
18.04.2017 16:21Мое предложение нисколько не противоречит имеющемуся на данный момент в AppStore/GooglePlay/… Я не призываю ограничивать права конечного пользователя по использованию конечного продукта. Заплатил денежку — получи продукт.
Я предлагаю усложнить алгоритм разделения оплаты между разработчиками. В текущих схемах "кластером" владеет разработчик основной платформы и разделение дохода идет по-простому: разработчик модуля для этой платформы заявляет какую-то цену и платит с нее определенную часть "кластеру" (разработчикам платформы), если произошла продажа. Разработчик платформы сам заключает договор с платежной системой и ведет расчеты с разработчиками модулей для нее.
Если вынести функционал по ведению расчетов в отдельный сервис, то такой сервис сможет продавать любые модули для любых платформ и предлагать эту услугу всем подряд. Главное, чтобы разработчики (и платформы, и модулей) делегировали ему такое право.
Вот для этого и нужно ограничение в лицензии, которая должна привязать право коммерческого использования библиотеки/платформы/модуля к оплате через подобные сервисы. Чтобы оплата в том или ином виде дошла до разработчиков. А вот в каком виде и до кого она дойдет, а до кого нет — определяется политикой сервиса на основании любых доступных данных. То, что коллега Emelian обозначил как
Специальный комитет при Цифровом Фонде государства мониторит сеть на предмет ...
Самое важное в этой лицензии, чтобы разработчики не могли сильно ущемлять права подобных сервисов, а сервисы — права разработчиков. Ну а дальше — эволюция, как я и отметил выше. Разработчики постепенно сдрейфуюут от неудачных политик к более успешным (даже и непрозрачным), если у них будет такая возможность.
P.S.
У Google'а, кстати, не самая прозрачная система ранжирования результатов поиска.SergeyUstinov
18.04.2017 17:16Я про другой аспект говорил — никто не станет платить за модули, которые надо допиливать. И никакая платежная система или лицензия не поможет.
Заказчику нужно решение его проблемы. Если он может открыть магазин, купить модуль (или подписаться на сервис с ежемесячными платежами) и все заработает — то такая модель будет пользоваться успехом.
А если ты купил модуль + нужно еще заплатить другой фирме за допиливание — уже хуже работает. Одно дело крупный вендор (1С, Microsoft, SAP, Oracle...) + партнеры. Там кое-как схема работает. А когда много производителей модулей…
Google выехал за счет более качественных результатов поиска :))) И на прозрачность всем наплевать. Если оно работает — какая разница, что в черном ящике?
А вот предлагаемая схема лицензирования и оплаты сейчас НЕ РАБОТАЕТ. Её еще просто нет. И убедить людей включиться в такую схему — непростая задача, и непрозрачность схемы всё тоько усложняет.flancer
18.04.2017 18:14никто не станет платить за модули, которые надо допиливать.
Мой персональный опыт говорит об обратном.
Со всем остальным полностью согласен.
IvanKlut
19.04.2017 09:12Вот вы и озвучили проблему. Действительно, сейчас большинство модулей нужно допиливать (или выбрасывать и писать заново), а если будет хорошая мотивация, как писал в предыдущем комментарии flancer, то качество повысится и их можно будет реально использовать.
Emelian
18.04.2017 09:31+2А почему не рассматривается идея «Цифрового Коммунизма?» Сергея Хапрова? Суть проста. Всё, что не затрагивает стратегических интересов государств, свободно и бесплатно. Авторское право сохраняется, но никак не ограничивает распространение и использование программных (в общем случае, цифровых) продуктов. Другими словами, пользователи цифрового продукта ничего не платят его авторам. Грубо говоря, всё кругом колхозное, всё кругом моё.
Но кто должен финансировать авторов и разработчиков цифрового контента? Ответ – только государство (другие случаи не регламентируются)! Частные организации тоже могут, но запрещать распространение (по факту!) своего продукта они не должны. Т.е. цифровое частное спонсорство дело исключительно добровольное.
Но по какому принципу государство должно платить за создание виртуального продукта? За счет специальных фондов, которые реализуются, в т.ч. и от ввода всеобщего, но небольшого цифрового налога на работающих граждан. Основная часть цифрового фонда должна наполняться доходами от использования государством (прямо и косвенно) всевозможных цифровых продуктов.
Зато государство может стимулировать создание любой виртуальной реальности, товаров, услуг и т.д. и т.п. Т.е. то, что ему реально необходимо. Например, нужно скажем (Рогозин вроде бы недавно говорил) ПО для боевого робота ФЁДОР. Государство говорит, ребята нужны хорошие алгоритмы для ИИ нашего робота, допустим для космических полетов, т.е. объявляет конкурс на создание ПО. Публикует ТЗ, спецификации и т.п. Народ пишет программы, демонстрирует использование и т.д. В итоге выигрывают все. Государство получает программы, победители – максимальные призы, а просто участники – утешительные.
Или другой пример – попроще. Допустим, государство заинтересованно в создании обучающих программ иностранным языкам. Все пишут, демонстрируют, публикуют. Победитель определяется по количеству пользователей использующих его программу, степени ее эффективности и по факту ее обсуждения в Интернете и массмедиа. В соответствии с социальным рейтингом происходит открытое распределение призового фонда, при условии получения утешительных (пусть символических) призов всем участникам. Понятно, что рейтинг программы будет пропорционален количеству скачивания ее с сайта разработчика. Не будем сейчас говорить о накрутках, но хорошую веешь видно сразу. А главным стимулом для разработчиков будет использование его программы либо другого цифрового продукта пользователем.
Еще вариант, допустим государство конкурс не объявляло. Но конкретный Вася Пупкин написал сногсшибательную программу для себя лично, опубликовал ее в Интернете и она по факту получила мощное признание (многие тысячи скачиваний, кучу лайков, рейтинговых звезд и благожелательное отношение публики). Специальный комитет при Цифровом Фонде государства мониторит сеть на предмет поиска подобных самородков (можно также допустить прямые запросы в этот комитет от авторов и разработчиков). Лично я бы со стороны государство отметил бы финансово такие разработки как ReactOS, Blender, Ollydbg и множество других. Правда, для поощрения не отечественных разработок нужно уже переходить на межгосударственный уровень. Но сначала, можно попытаться построить «Цифровой Коммунизм» «в отдельно взятой стране».
Нюансов, естественно здесь будет много, но почему бы не начать обсуждать саму идею?IvanKlut
18.04.2017 10:24Почему-то не цепляет, не верю в эту идею, может если только устройство института государственного управления будет совершенно иное.
Emelian
18.04.2017 12:41Оно и будет другое, всё к тому идет. Пройдет 10-20 лет и мы Россию не узнаем. При условии, что «партнеры» не предпочтут локальный армагедончик. Постепенно отомрут все партии и политические выборы. Вместо выборов будут общедоступные публичные конкурсы на право занятия важных должностей, а также определенного вида собственности. Т.е. право распоряжения собственностью и частью прибыли от нее можно будет выиграть в публичном, справедливом, общедоступном конкурсе. И тогда не придется «красть свой первый миллион», чтобы «честно зарабатывать остальные». В таком государстве на первое место выйдет социальное творчество, в т.ч. стимулируемое творчество масс. А в творчестве всех на благо всех такие понятия, как цифровое пиратство уйдут за ненадобностью. Запретительное авторское право направлено на дезинтеграцию общества, в то время, как разрешительное авторское право на его консолидацию.
worldmind
18.04.2017 11:17Государство должно использовать внутри себя только свободный софт, как это написано у меня в книге, но оно не имеет права принудить кого-то открывать свой софт, это личное дело разработчика как распространять свой софт, правда открытый вопрос должно ли государство преследовать за пиратство, но даже отсутствие наказания за пиратство не означает что никто не будет платить, во многих странах наказания по сути нет, но кто-то качает кряки, а кто-то покупает.
Emelian
18.04.2017 12:28-1Государству не нужно принуждать пользователя открывать свой личный софт. Но, то что «с возу упало, то пропало», т.е. если цифровой продукт каким-либо образом «утёк» в сеть, то он стал «ничьим», в смысле необходимости платить за его использование. Хотя авторство всегда должно сохраняться. «Цифровое пиратство» должно стать атавизмом, т.е. отмереть. «Цифровой Коммунизм» (ЦК) и «Цифровое Пиратство» вещи несовместимые. Не зря кто-то сказал из великих, что всё самое ценное в этой Жизни мы получаем бесплатно: Любовь, Родных, Близких, Друзей, Родину, Здоровье, саму Жизнь наконец. В СССР бесплатными были Образование, Медицина, Жилье, Работа (в смысле гарантированности) и т.п. Идея ЦК предлагает добавить к этому перечню все доступные (с точки зрения Морали, Нравственности, Безопасности и т.п.) цифровые и виртуальные продукты. Это ведь неуничтожимый, неисчезаемый и неисчерпаемый ресурс. Чего жадничать то? Авторы хотят заработать? Нет проблем, платит государство за популярность цифрового ресурса. Чем больше народу им пользуются, тем должно быть выгоднее его автору либо правопреемнику. Самое важное это отработать справедливый механизм распределения прибыли от продуктов творчества. От части этих продуктов государство будет иметь прямую прибыль, а от другой части косвенную. Например, если внедрять в обществе конкурсно-ориентированную идеологию (делай как я, делай лучше меня!), то энергия людей, особенно молодежи будет тратиться не на местные понты, а, в конечном счете, на благо государства.
worldmind
18.04.2017 17:53> если цифровой продукт каким-либо образом «утёк» в сеть, то он стал «ничьим», в смысле необходимости платить за его использование
так и будет если отменить наказания за «пиратство»
> В СССР бесплатными были
бесплатного ничего не бывает, просто оплата бывает явной или неявной, но бесплатного ничего нет, точнее бесплатным может быть практически бесконечный ресурс, но это особые исключения
> Нет проблем, платит государство за популярность цифрового ресурса.
у меня подобная схема описана тутEmelian
19.04.2017 10:14-1> так и будет если отменить наказания за «пиратство»
Цифровое пиратство это буржуазное изобретение. Для капиталистов смысл всего это прибыль. При социализме – смысл всего это развитие (всех на благо всех). Тактика международного капитала – ограничить по максимуму развитие других стран и народов, поэтому запретительное авторское право это один из инструментов этой борьбы. Автору цифрового продукта что нужно? В первую очередь деньги. Деньги ему должно обеспечить государство, а степень распространения его продукта способно вызвать тогда только максимум удовлетворения. Ведь какой смысл изобретать либо создавать Нечто, но по максимуму ограничить его использование? Если это не будет касаться потери денег, то автор только рад будет заявить о себе по максимуму. Нормальному государству (социальному, социалистическому и т.п.) нужно Развитие. А финансовая упряжка на использование бесконечно возобновляемого цифрового продукта – ограничивает Развитие (человека и общества). И тогда не будет фраз, звучавших в свое время в Интернете, типа: «чтобы покупать все цифровые продукты, которыми я пользуюсь, мне надо иметь несколько месячных зарплат в неделю».
> бесплатного ничего не бывает, просто оплата бывает явной или неявной,
> но бесплатного ничего нет, точнее бесплатным может быть практически
> бесконечный ресурс, но это особые исключения
Цифровой продукт – бесконечный ресурс, но его не хотят делать бесплатным, а хотят иметь максимально полную оплату за каждую(!) копию.
С другой стороны – бесплатность оборотная сторона Власти. Хозяева (то ли по праву Сильного, то ли по праву Первого) всегда имеют свои ресурсы бесплатно. И уже Хозяева и Власти решают, кому дать бесплатное, а кому платное. Вспомним вечный принцип распределения, который почти не зависит от типа государственного устройства: «От каждого по способностям, каждому – сколько положено!», различается он только мерой наглости.
Поэтому в социально ориентированных (в т.ч. социалистических) государствах можно рассчитывать, на то, что Власти будут не слишком жадничать и поделятся частью (по крайней мере, легко возобновляемых и почти неограниченных) ресурсов. Умные должны понимать, что вложения в Образование и Развитие окупаются сторицей. Обеспечьте Народ ресурсами развития и он вернет властям немыслимые произведенные Блага. Особенно это актуально в условиях международной конкуренции Цивилизаций (не на Жизнь, а на Смерть). Перефразируя известную фразу: «Кто не хочет развивать свой народ, будет развивать чужой».
> у меня подобная схема описана тут
Да, интересные идеи есть, но полностью проблему можно решить только на уровне Государства. Если Россия будет развиваться теми же темпами, то через 10-20 лет она сможет уже не заморачиваться мнением «партнеров», наоборот, «партнеры» будут смотреть в рот России. Вот тогда мы и себя покажем и другим жить дадим :).
worldmind
18.04.2017 11:24+1Пример с Linux это показательный пример преимущества GPL — компании-конкуренты сотрудничают т.к. знают что лицензия не позволяет никому паразитировать на других.
Идея платных модулей в тех же дрюпалах и марджентах вроде как вполне работает и ничего изобретать не требует, но скорее всего их будет всё меньше ввиду появления свободных аналогов, а зарабатывать придётся на поддержке и доработках т.е. просто за копию кода получать деньги в будущем не получится, на эту тему есть доклад «Анархономика» Копенгагенского Института исследований будущего.IvanKlut
18.04.2017 12:16Ну почему же не получится, если будет юридическое основание, то проблем нет. Дело в том, что системы, как правило, развиваются и в код вносится изменения, соответственно программным модулям требуются обновления. И нормально работающий бизнес платит за обновления.
worldmind
18.04.2017 17:46Не получится потому что такая модель не выдержит конкуренции со свободным софтом.
IvanKlut
19.04.2017 09:18Получится, т.к. сейчас даже 100% платный софтом выдерживает конкуренцию со свободным. Но суть того, что я писал в статье в том, что нужно совместить плюсы открытого и платного софта и получить лучшую мотивацию разработчиков более высокое качество систем. То чем мы пользуемся сейчас скоро будут вспоминать с жалостью, как мы вспоминаем неандертальцев: вот бедные, сначала найди кремень, потом обтеши его, к палке привяжи и т.д.
worldmind
19.04.2017 09:29+1Пока выдерживает, но ниша его будет уменьшаться по мере развития свободного софта. Возможно до нуля она не упадёт, но будет всё меньше.
SergeyUstinov
Если говорить конкретно о «фреймворке для многофункциональных бизнес-систем», то скорее всего не взлетит.
Самый первый вопрос — а насколько нужен такой фреймворк? Все активно думают о микросервисах.
Во вторых, сама по себе продажа модулей не настолько простой процесс. Сложность в кастомизации. Обычно не получается просто нажать на кнопку и установить модуль. ОСОБЕННО если есть фреймворк :))) Нужна кастомизация модуля — подгонка под остальные купенные / разработанные модули. Кто будет это делать?
Ну и в целом есть сомнения в модели на уровне ощущений. Взять в качестве примера ту же 1С. Количество внедрений конфигураций (модулей) сторонних компаний (не 1С) относительно небольшое.
acyp
1С не совсем корректный пример для иллюстрации такой мысли. Существует как минимум 8 крупных разработчиков отраслевых решений(конфигураций), причем в некоторых отраслях «материнской» 1С просто нет (популярнейшая конфа «жкх» производства Айлант например). Есть примеры сервисов, которые будучи изначально разработаны командой-франчайзи, стали массово внедряемыми (бухфон, который ныне 1с-коннект).
В этой ситуации 1С скорее регулирует эко-систему в роли арбитра, выдавая сертификаты на продукт «1С-совместимо». Такие сертификаты гарантируют интеграцию если не бесшовную, то хотя бы на уровне сервисов.
Пример организации.
SergeyUstinov
Количество внедренных независимых конфигураций / модулей в экосистеме 1С на порядок меньше внедренных конфигураций самой 1С. То есть в данном конкретном случае идея «разработчик фреймворка» + «много независимых разработчиков прикладного кода» не сработала, хотя 1С поощряет разработку конфигураций сторонними компаниями.
acyp
Спорить сложно, такой статистики просто нет. Как и критериев. Можно ли относить «кастомизированное» решение 1С: БП 3.0 к независимой разработке? Упомянутый Айлант: ЖКХ — как раз катомизированное решение. На какую глубину эту кастомизацию учитывать… А может посчитать рынок по массе денег? ну и прочее… Вопросов больше чем ответов в любом случае.
Вот к чему все выше сказанное: Фреймвок для бизнес систем существует (причем не один). Это и 1С и SAP (да-да, у него тоже есть система франчей-разрабов, просто бизнес-модель продаж отличается). Но они все платные/коммерческие. Возможна ли свободная система? Надеюсь, что да. Надо учиться у «жадных дядей» и брать все лучшее, параллельно развивая в себе понимание, что деньги нужны лишь как инструмент решения задач.
SergeyUstinov
На сайте 1С есть такая статистика. Мне было интересно и я грубо посчитал порядок. Примерно 5% внедрений, описанных на сайте — сторонние «тиражные» разработки. Маловероятно, что внедренцы будут замалчивать свои внедрения, так что эта статистика достаточно надежна.
Вот именно, что фреймворк существует, и не один. :))) Кстати, есть и бесплатные. Но проблема всех этих систем — они ОЧЕНЬ большие и сложные (многие воспринимают 1С Бухгалтерию как маленькую и простую, но это давно не так). И в них очень сильно проявляются все недостатки крупных монолитных систем.
acyp
1. Фирма «1С» ведет справочник внедренных решений, который состоит из информационных сообщений партнеров о внедренных решениях на основе системы программ «1С: Предприятие». Предоставление информации в справочник является добровольным, поэтому он содержит лишь малую часть из сотен тысяч реальных внедрений «1С: Предприятия», осуществленных партнерами «1С».
— Это с самого сайта.
2. Как вы отделили типовые разработки 1с от типовых разработок франчайзи, которые включены в основной прайс?
3. Дело в том, что это просто короткая справка и мы опять приходим к вопросу: «какую разработку считать независимым решением, какую кастомизированным». Исходя из опыта, большая часть конф, сложнее БП внедряются с кастомизацией (допиливанием под реальные потребности) той или иной степени сложности.
4. я не считаю БП маленькой, я во франчайзи работаю :).
5. Любой фреймвок — вещь в себе и часто вырастает в монстра, которого надо поддерживать и сопровождать. Пример: я начинал прогать на php. Преподаватель рассказал нам о пользе шаблонизации, об отделении логики, хтмл-темплейтов и пхп-шаблонов. Написана первая студенческая поделка. А через пол года я просто не узнал ее. Она стала мини-фреймвоком из-за попытки унивесализировать. У товарища который был более ленивым — куча шаблонов. Да, в моем мне писалось легче, товарищу примерно одинаково сложно в обоих.
Моя любимая призказка по таким поводам: каждому гвоздю свой молоток.
SergeyUstinov
1. Партнерам выгодно давать информацию о всех своих успешных внедрениях, независимо от того, типовая конфа или нет. Даже если часть из партнеров не вносит данных — процентное соотношение скорее всего сохраняется.
2. Никак ))) Почитал выборочно пару десятков описаний. Типовые разработки франчайзи или достаются клиентам бесплатно (то есть монетизировать не получится), или речь идет просто о кастомизации, и говорить о тиражном решении нельзя. А действительно тиражные решения обозначены в явном виде.
3. Вопрос надо ставить несколько по другому — можно ли создать экосистему из фреймворка и множества независимых платных модулей? Ответ — скорее всего нельзя, смотрим на 1С. Если речь идет о кастомизации, то нельзя просто купить и включить модуль. Нужно его допилить. А если все равно допиливать (то есть достаточно сильно углубляться, как модуль работает) — зачем за него платить?
4. Я про клиентов. :))) У многих до сих пор остается подсознательное отношение к БП как к чему то маленькому и простому… Это еще можно было с натяжкой сказать про 6.0, но начиная с конфигураций под 7.7 и особенно последние под 8.х — ничего простого там уже нет.
5. И вот тут то и возникает вопрос — кому и зачем нужен фреймворк? Клиентам он не нужен от слова совсем — их интересует прикладной функционал. Программистам для облегчения работы? Возможно, но явно не универсальный — фин проводки и документооборот — очень разные задачи. Снижение входного порога? Но низкая квалификация аукается очень низким качеством решений. И пример 1С хорошо показывает — медленные, часто глючные решения. А когда «специалисты» пытаются написать что-то сложное — вообще тихий ужас (4 из 5 самописок лучше вообще не смотреть — нервы целее будут).
acyp
Интуитивно чувствую некоторое непонимание в определениях «кастомизация» и «тиражное решение». Но поскольку к сути обсуждения не относится, то и заостряться на нем не будем. Хотя именно это может повлиять на ответ к третьему пункту.
Про пример 1с — типовые или тиражные решения (включенные в основной прайс, но могут принадлежать разным коллективам разработчиков) — изначально рассчитаны на предел эксплуатации в парках до 100 пользователей или до 10 тыс документов в день. На практике предел наступает раньше и за дело беремся мы, эксперты по технологическим вопросам и экслуататоры 1с :).
Вот к чему: эко-система 1с — развита. Просто платная. Предположение про бесплатные — с моей стороны уже было.
«Глючность» 1с часто комментировать отказываюсь, просто могу дать доступ к себе и попробуй найти глюки, конфа не самая модная и новая — Комплексная Автоматизация 1.1 совсем чуть-чуть дописанная (интеграция с и-магазом). 30 пользователей онлайн живут вполне нормально не на самом новом оборудовании. От рук все зависит и от знаний.
Как собсно и во всем :).
SergeyUstinov
Глюки везде можно найти. :)))
Я писал о другом аспекте — ценность низкого порога вхождения часто преувеличена. В любом случае нужен хороший уровень знаний. И как пример можно посмотреть на нетленки, подавляющее большинство из которых ужас-ужас.
И, кстати, низкая масштабируемость многих конфигураций 1С — это тоже проблема фреймворка. Ведь если разрекламировать возможность доступа к данным «через точку» — все и будут писать через точку. :)))
Я не являюсь противников фреймворков как таковых, они действительно во многих случаях нужны и полезны. Но идея создать мега фреймворк для всех бизнес приложений кажется мне утопической.
IvanKlut
Микросервисы абсолютно не противоречат идее, а наоборот хорошо в ней работают. Я как раз приступил к реализации одного из двух планируемых микросервисов, которые будут встроены в нашу систему и будут открыты для других.
acyp
Так я Вас и поддержал. если что. И предложил (возможный механизм)*пример маханизма развития и решения коллизий :).
SergeyUstinov
Идея микросервисов — сделать куски кода МАКСИМАЛЬНО независимыми друг от друга. А фреймворк как раз создает сильную зависимость.
IvanKlut
Фреймворк не обязан охватить все аспекты человеческой деятельности. Он может, например, автоматизировать бизнес-процессы, но коммуникации лучше чтобы осуществлял отдельный независимый сервис.
SergeyUstinov
«Давайте перейдем к конкретике. Для примера возьмем разработку некого фреймворка для многофункциональных бизнес-систем. Она может включать коммерцию, управление бизнес процессами и сотрудниками, создание сообществ и т.д. Причем, не отдельные куски типа CMS, CRM, а объединенную единой логикой систему (операционную среду для бизнес-приложений).»
Это довольно широкий список задач. И такое описание очень близко к «охватить все аспекты человеческой деятельности». :)))