Здравствуйте, so5team, Вы писали:
S>Повторю еще раз: мне интересно понять, если GPL лицензию вы считаете токсичной для бизнеса, то какие по вашему мнению есть другие альтернативные способы заработка на OpenSource библиотеках.
В целом я согласен с позицией о токсичности GPL лицензий, особенно GPL3. Если же говорить о монетизации таких решений, то, библиотека за деньги в современном мире — это практически нонсенс. Но при этом есть примеры монетизации типа Lucene (под нормальной лицензией, приемлемой для бизнеса) которая само собой не приносит денег. Но вот продукт на ней построенный уже имеет платные дополнения и деньги приносит. По ощущениям сейчас библиотеки мало кому за деньги нужны, другое дело продукты, там уже может быть коммерческая заинтересованность.
Здравствуйте, kaa.python, Вы писали:
KP>Но при этом есть примеры монетизации типа Lucene (под нормальной лицензией, приемлемой для бизнеса) которая само собой не приносит денег. Но вот продукт на ней построенный уже имеет платные дополнения и деньги приносит.
О каком продукте и каких платных дополнениях идет речь?
KP>По ощущениям сейчас библиотеки мало кому за деньги нужны, другое дело продукты, там уже может быть коммерческая заинтересованность.
В чем принципиально отличие "продуктов" от "библиотек"? Продукты предназначены для не-программистов или что-то другое?
Здравствуйте, so5team, Вы писали:
S>О каком продукте и каких платных дополнениях идет речь?
Речь про Elasticsearch и дополнение X-Pack.
S>В чем принципиально отличие "продуктов" от "библиотек"? Продукты предназначены для не-программистов или что-то другое?
Разница в том, что библиотека не решает никакой бизнес проблемы "из коробки", она требует кучи приседаний в результате которых может быть что-то хорошее выйдет. Продукт же включает в себя библиотеку и его функционал близок к библиотеке, но он сразу добавляет ценность бизнесу.
На днях на Python митапе чуваки рассказывали про свой проприетарный продукт — быстрый многомерный куб для выборки по многим изменениям (вариации на тему OLAP куба). Они продают продукт трейдерам и управляющим фондам и работают над открытием библиотеки лежащей в его основе, библиотека — она ничего не стоит в современных реалиях.
Здравствуйте, kaa.python, Вы писали:
KP>Речь про Elasticsearch и дополнение X-Pack.
Т.е. речь про код, открытый под Elastic License (можно смотреть, но нельзя ничего трогать и нельзя строить на базе этого кода собственные производные решения).
S>>В чем принципиально отличие "продуктов" от "библиотек"? Продукты предназначены для не-программистов или что-то другое?
KP>Разница в том, что библиотека не решает никакой бизнес проблемы "из коробки", она требует кучи приседаний в результате которых может быть что-то хорошее выйдет. Продукт же включает в себя библиотеку и его функционал близок к библиотеке, но он сразу добавляет ценность бизнесу.
Не понятно. Вот, допустим, есть задача из приложения читать/писать файлы какого-то формата (скажем, docx). Для этого берется библиотека, обеспечивающая такую возможность.
Здравствуйте, so5team:
S>Т.е. речь про код, открытый под Elastic License (можно смотреть, но нельзя ничего трогать и нельзя строить на базе этого кода собственные производные решения).
Часть продукта, основа — Lucene, под Apache.
S>Не понятно. Вот, допустим, есть задача из приложения читать/писать файлы какого-то формата (скажем, docx). Для этого берется библиотека, обеспечивающая такую возможность.
S>Эта библиотека будет продуктом или нет?
Это библиотека которую вряд ли кто-либо и когда-либо купит. В то же время условный сервис по конвертации между форматами уже будет продуктом.
Здравствуйте, kaa.python, Вы писали:
KP>Часть продукта, основа — Lucene, под Apache.
Речь про то, за что берут деньги. Деньги, как я понимаю, берут именно за код, который идет под Elastic License.
S>>Эта библиотека будет продуктом или нет?
KP>Это библиотека которую вряд ли кто-либо и когда-либо купит.
Э... Если бизнесу нужно решить проблему (скажем, писать в docx-файл из программы), которая решается либо покупкой лицензии на библиотеку, либо написанием собственного велосипеда, то покупать библиотеку не будут, будут делать собственный велосипед?
KP>В то же время условный сервис по конвертации между форматами уже будет продуктом.
Тогда еще раз: чем продукт отличается от библиотеки?
Пока что единственное принципиальное отличие, которое видно мне: продукт -- это приложение, которое может запустить не программист и/или DevOps. Тогда как библиотека не является продуктом потому что требуется программист, который встроит библиотеку в некий прикладной код.
Здравствуйте, so5team, Вы писали:
KP>>Это библиотека которую вряд ли кто-либо и когда-либо купит.
S>Э... Если бизнесу нужно решить проблему (скажем, писать в docx-файл из программы), которая решается либо покупкой лицензии на библиотеку, либо написанием собственного велосипеда, то покупать библиотеку не будут, будут делать собственный велосипед?
Именно. Т.к. слишком часто разработчики библиотеки бросают всё и переходят в кузнецы, а бизнес остаётся у разбитого корыта. Дальше ему надо своими силами майнтейнить или вообще с нуля делать, если лицензия не той системы. И вот парадокс — вариант "лицензия" все равно превращается в "пилим сами"
В одном случае платишь много и сразу, в другом случае над тобой висит риск в виде недополученой прибыли, который срабатывает слишком часто. Суммарные издержки часто больше именно во втором случае. Например — вместо освоения нового подхода, рынка, сегмента приходится начинать всё заново т.к. либа уже не той системы или протухла.
S>Пока что единственное принципиальное отличие, которое видно мне: продукт -- это приложение, которое может запустить не программист и/или DevOps. Тогда как библиотека не является продуктом потому что требуется программист, который встроит библиотеку в некий прикладной код.
Нету отличий. Разница только в том, на кого нацелен тот или иной продукт и каковы юз-кейсы.
Здравствуйте, so5team, Вы писали:
S>Э... Если бизнесу нужно решить проблему (скажем, писать в docx-файл из программы), которая решается либо покупкой лицензии на библиотеку, либо написанием собственного велосипеда, то покупать библиотеку не будут, будут делать собственный велосипед?
Ну ты же знаешь как работает. Почти наверняка найдут готовую, если вдруг не найдут, то постараются завелосипедить и если только велосипед ну вообще на квадратных колёсах выйдет, то подумают о покупке.
S>Пока что единственное принципиальное отличие, которое видно мне: продукт -- это приложение, которое может запустить не программист и/или DevOps. Тогда как библиотека не является продуктом потому что требуется программист, который встроит библиотеку в некий прикладной код.
Отличие в том, что продукт не требует никакой разработки, его можно просто развернуть, и он обладает дополнительными полезными функциями. На примере конвертора, он ещё бы умел использовать шаблоны, проверять на вирусы, рассылать письма с корвертирвованным документы адресата, а так же имел бы интеграцию с Elasticsearch.
Здравствуйте, kaa.python, Вы писали:
KP>Ну ты же знаешь как работает.
Нет. Мир слишком большой и мне интересно, что происходит за пределами той мизерной части, которая видна мне.
KP>Почти наверняка найдут готовую, если вдруг не найдут, то постараются завелосипедить и если только велосипед ну вообще на квадратных колёсах выйдет, то подумают о покупке.
Т.е. если лицензия на готовую библиотеку стоит $1K, ее внедрение займет всего неделю, а поиск и эксперименты с бесплатными решениями разной степени кривости займут две недели, а минимальная версия своего велосипеда потребует месяца работы, то покупка в принципе рассматриваться не будет?
Здравствуйте, so5team, Вы писали:
S>Т.е. если лицензия на готовую библиотеку стоит $1K, ее внедрение займет всего неделю, а поиск и эксперименты с бесплатными решениями разной степени кривости займут две недели, а минимальная версия своего велосипеда потребует месяца работы, то покупка в принципе рассматриваться не будет?
Именно так. И чем больше компания, тем больше вероятность того, что на платную версию даже не взглянут, разве что она очень известная и сильно сложная. Ты просто задолбаешься бюджет одобрять на покупку библиотеки, а разработчиков то гора и ЗП им всяко платить.
Здравствуйте, kaa.python, Вы писали:
KP>Именно так. И чем больше компания, тем больше вероятность того, что на платную версию даже не взглянут, разве что она очень известная и сильно сложная. Ты просто задолбаешься бюджет одобрять на покупку библиотеки, а разработчиков то гора и ЗП им всяко платить.
Интересно. А как же time-to-market? Или в больших компаниях это не приоритет?
Здравствуйте, so5team, Вы писали:
S>Интересно. А как же time-to-market? Или в больших компаниях это не приоритет?
Официальная версия, обычно, это офигеть какой приоритет. Тем не менее наблюдаемых действия почти всегда этому противоречат. Бывают исключения, почаще потому что полимеры уже просраны и там не до новых библиотек, надо то что есть заставить работать.
Здравствуйте, kaa.python, Вы писали: KP>Именно так. И чем больше компания, тем больше вероятность того, что на платную версию даже не взглянут, разве что она очень известная и сильно сложная. Ты просто задолбаешься бюджет одобрять на покупку библиотеки, а разработчиков то гора и ЗП им всяко платить.
Плюс дождаться своей очереди в юр. отделе, который должен одобрить применение лицензии. Это с GPL сразу понятно, что "вам запрещено применять в разработках GPL библиотеки под страхом увольнения", а с коммерческими лицензиями никаких стандартов нет. Каждый вендор изобретает свои собственные уникальные требования, которые могут быть несовместимы с требованиями корпорации-покупателя.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kaa.python, Вы писали:
KP>Официальная версия, обычно, это офигеть какой приоритет. Тем не менее наблюдаемых действия почти всегда этому противоречат. Бывают исключения, почаще потому что полимеры уже просраны и там не до новых библиотек, надо то что есть заставить работать.
Спасибо.
А вот как в больших компаниях с такой ситуацией: библиотека распространяется под пермиссивной лицензией (типа BSD, MIT, Boost), за деньги продается техподдержка и расширенная документация/учебные пособия для нее. Насколько просто согласовать приобретение техподдержки/документации?
Здравствуйте, so5team, Вы писали:
S>А вот как в больших компаниях с такой ситуацией: библиотека распространяется под пермиссивной лицензией (типа BSD, MIT, Boost), за деньги продается техподдержка и расширенная документация/учебные пособия для нее. Насколько просто согласовать приобретение техподдержки/документации?
На обучение и поддержку деньги обычно не сложно согласовать. Особенно на обучение, так как это отдельный бюджет, часто не выбираемый что само по себе проблема. Но я не знаю как много народу такое захочет, опыт Akka показывает что не мало, но с другой стороны, продукт все же лучше библиотеки. Сам я поддержки библиотеки никогда не согласовал в отличие от продуктов. Бизнесу сложно обосновать зачем программистам библиотека, "ты ж программист!!11", ну а продукты — это просто, это бизнес понимает.
Здравствуйте, so5team, Вы писали:
S>А вот как в больших компаниях с такой ситуацией: библиотека распространяется под пермиссивной лицензией (типа BSD, MIT, Boost), за деньги продается техподдержка и расширенная документация/учебные пособия для нее. Насколько просто согласовать приобретение техподдержки/документации?
Oбучение? Читаешь документацию, примеры, гуглишь по форумам. Поддержка? Нашел баг — открыл исходник — исправил.
KP>Проблема винтика решается очень просто: маленькая компания или небольшой стартап. Код будет с первых недель работы (нонсенс для большой компании) делать кучу интересного и важного.
А то я не знаю!
KP>Правда сразу возникнет вопрос "кому нужен C++ в стартапе, надо же кучу всего и сейчас", но это отдельная философская тема.
Поиски показали, что в принципе нужен, хотя совсем не массово, конечно. Некоторые стартапы по инерции делают проекты на С++.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, $$, Вы писали:
BS>>>А чем бы ты хотел заниматься на С++?
B>>AI к играм и не только
$$>Почему именно C++, а не питон или lua?
Это скорее то, чем я в принципе хотел бы заниматься. А лучше всего знаю С++. Ну и большинство игр ААА-класса написаны на С++, так что писать на нем AI вполне себе адекватно.
С Lua я достаточно много имел дело, даже написал робота, который играет в WoW на арене за хилера (по сути, это чистый игровой AI и есть). Lua да, отличный язык, очень мне нравится, на нем бы я с удовольствием попрограммировал. Но на нем очень мало работы (в основном это моды для игр) и она непостоянная.
Питон тоже использовал и он тоже хорош, но больше для прототипирования. Писать серьезный AI на нем стремно, т.к. он все-таки медленный и без статической типизации.
Вообще, имхо, оптимальный язык для игрового AI — это Rust. Там шикарная система типов, да еще дополненная паттерн-матчингом, и много возможностей для функционального программирования. Плюс скорость, надежность и куча других, более мелких приятных плюшек, типа встроенных юнит-тестов, удобных макросов и т.п.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
