Вопросы с софтом должны решаться немного по другому принципу. Софт — это не конечный продукт, а инструмент, обычно. Тут уже нужно продавать не сам софт, а гарантии. Гарантии того что он будет работать, гарантии того что он будет надежен, гарантии того что он будет развиваться и обновляться.
И эти гарантии будут покупать.
А можно продавать сервис — см модель 37 сигналов. Они свой софт не продают никому.
(Конечный продукт — игры, для них есть OnLive :) )
Не обидно. Следующий раз крупные студии позовут мальчика писать еще один сценарий. Уже за отдельные деньги и публиковать он его нигде не будет.
Кроме того, если сценарий хороший и кино популярное — то люди начнут его читать — пойдет доход. :) Но не сразу всё, конечно :)
Я вам ничего не продаю :) А то что я продаю — вам не нужно. (те кому нужно — платят большие деньги, но не столько за то что я им продал, сколько за сопровождение и обновление того что я им продал).
я не притворяюсь и не ищу отговорки. То что я хочу купить — попросту не продается. или продается с задержкой в 3-4 года.
На тему доступа в iTunes и прочем — могу отправить вас поговорить с ребятами из музыкального коллектива Петра Налича, к примеру. Сначала напишите что-то хорошее, дайте его бесплатно и собирайте деньги с концертов.
Если это действительно что-то хорошее, а не очередной клон того, чего полно на рынке — то будет замечено и куплено.
Проблема в том, что вы пытаетесь защищать всех авторов, в том числе «говноделов». А их-то как раз защищать и не нужно.
Здесь основных способов монетизации я вижу два:
1. Предоставление контента (любого) по библиотечному принципу. То есть платишь фиксированную сумму ежемесячно (за абонемент) и смотришь/читаешь/слушаешь всё что угодно и столько сколько влезет. Много всё равно не влезет.
Здесь есть несколько проблем:
а. Сумма должна быть адекватная, соизмеримая с локальным уровнем доходов. Определяется путем маркетинговых исследований
б. В библиотеке реально должно быть вообще все => библиотека должна быть государственной, то, чего нет в библиотеке — не защищается копирайтом на территории данной страны
в. Сумма вознаграждения должна определяться частотой использования произведения (см модель flattr).
2. Предоставление связанных услуг — сувениров, концертов, выступление, публичных чтений, эксклюзивных печатных изданий и т.п. Да, это накладно и не всегда удобно авторам. Но это делает авторов ближе к фанатам и приносит дополнительный доход.
У REST нет описания схемы ресурсов потому, что разработчики еще не определились как это сделать. Есть WADL и WSDL 2, но, пока что, оба они не применяются широко, хотя у Java появились автоматические генераторы адаптеров для REST по WSDL.
Ниже есть от меня большой комментарий.
Протоколов УЖЕ вагон, нет, состав и маленькая тележка. Их так-то замучаешься в одну систему интегрировать. OPC в этом плане сильно спасает.
Теперь появляются люди, которые говорят «А давайте к этому вагону изобретем ЕЩЕ один протокол! Это же так классно, изобретать новые протоколы».
При этом сами признаются, что с последними усилиями большой части отрасли (http://opcfoundation.org/About/MemberList.aspx) в области стандартизации не знакомы.
Я очень желаю всем интеграторам, чтоб ваш проект сдох, так и не родившись.
А вам желаю понять специфику отрасли и таки быть в курсе современных разработок. И не изобретать собственных велосипедов там, где они не нужны.
Какой КОШМАР!
Данная статья может являться замечательным примером того, как люди не понимают разницы между стандартами и технологиями.
Это звучит примерно как «Зачем нам HTTP, он закрытый (описан в каких-то RFC, которых я никогда не читал). У него куча недостатков. Поэтому вместо него мы лучше будем использовать UDP. Он открытый, в пакетах можно отправлять что угодно...»
Так вот, немножко про OPC:
1. Стандарт OPC UA существует (в разных вариантах) уже 4 года
2. Он кросс-платформенный, включая бинарные протоколы. (Поддержка их крайне важна для разработчиков PLC, да и прочего совместимого оборудования)
3. Он расширяемый (при необходимости, стандартным образом)
4. Он поддерживается огромным количеством производителей, включая таких не специфичных для промавтоматизации как SAP
5. Для совместимости со старыми версиями существуют «преобразователи», которые могут быть использованы для конверсии из UA в Classic и обратно.
6. Стоимость членства в OPC Foundation — от 500 долларов в год
7. Уже существует множество SDK, в том числе и открытых
Вы там выше в комментариях упоминали про интеграцию… Так вот, запомните на всю свою последующую жизнь — стандартизация протоколов обмена данными является абсолютно необходимым требованием для успешной интеграции больших систем. А не «зато мы можем писать любые данные которые нам взбредет в голову».
Кстати, именно поэтому в OPC используется SOAP, а не REST. В REST на сегодня даже нет единого формата описания схемы ресурсов (несколько черновых и недоделанных — не в счет).
Пользовался Money и еще парой других. Остановился на YNAB, который стоит на голову выше остальных в плане активного планирования финансов. За первую неделю использования он мне сэкономил в 10 раз больше денег чем сам стоит. За полгода ROI = 5000%. :)
Взамен защищается законом о защите частной/личной информации.
Или ДСП :)
И эти гарантии будут покупать.
А можно продавать сервис — см модель 37 сигналов. Они свой софт не продают никому.
(Конечный продукт — игры, для них есть OnLive :) )
Кроме того, если сценарий хороший и кино популярное — то люди начнут его читать — пойдет доход. :) Но не сразу всё, конечно :)
На тему доступа в iTunes и прочем — могу отправить вас поговорить с ребятами из музыкального коллектива Петра Налича, к примеру. Сначала напишите что-то хорошее, дайте его бесплатно и собирайте деньги с концертов.
Если это действительно что-то хорошее, а не очередной клон того, чего полно на рынке — то будет замечено и куплено.
Проблема в том, что вы пытаетесь защищать всех авторов, в том числе «говноделов». А их-то как раз защищать и не нужно.
Может быть нам и не нужны такие авторы, а?
1. Предоставление контента (любого) по библиотечному принципу. То есть платишь фиксированную сумму ежемесячно (за абонемент) и смотришь/читаешь/слушаешь всё что угодно и столько сколько влезет. Много всё равно не влезет.
Здесь есть несколько проблем:
а. Сумма должна быть адекватная, соизмеримая с локальным уровнем доходов. Определяется путем маркетинговых исследований
б. В библиотеке реально должно быть вообще все => библиотека должна быть государственной, то, чего нет в библиотеке — не защищается копирайтом на территории данной страны
в. Сумма вознаграждения должна определяться частотой использования произведения (см модель flattr).
2. Предоставление связанных услуг — сувениров, концертов, выступление, публичных чтений, эксклюзивных печатных изданий и т.п. Да, это накладно и не всегда удобно авторам. Но это делает авторов ближе к фанатам и приносит дополнительный доход.
Протоколов УЖЕ вагон, нет, состав и маленькая тележка. Их так-то замучаешься в одну систему интегрировать. OPC в этом плане сильно спасает.
Теперь появляются люди, которые говорят «А давайте к этому вагону изобретем ЕЩЕ один протокол! Это же так классно, изобретать новые протоколы».
При этом сами признаются, что с последними усилиями большой части отрасли (http://opcfoundation.org/About/MemberList.aspx) в области стандартизации не знакомы.
А вам желаю понять специфику отрасли и таки быть в курсе современных разработок. И не изобретать собственных велосипедов там, где они не нужны.
Данная статья может являться замечательным примером того, как люди не понимают разницы между стандартами и технологиями.
Это звучит примерно как «Зачем нам HTTP, он закрытый (описан в каких-то RFC, которых я никогда не читал). У него куча недостатков. Поэтому вместо него мы лучше будем использовать UDP. Он открытый, в пакетах можно отправлять что угодно...»
Так вот, немножко про OPC:
1. Стандарт OPC UA существует (в разных вариантах) уже 4 года
2. Он кросс-платформенный, включая бинарные протоколы. (Поддержка их крайне важна для разработчиков PLC, да и прочего совместимого оборудования)
3. Он расширяемый (при необходимости, стандартным образом)
4. Он поддерживается огромным количеством производителей, включая таких не специфичных для промавтоматизации как SAP
5. Для совместимости со старыми версиями существуют «преобразователи», которые могут быть использованы для конверсии из UA в Classic и обратно.
6. Стоимость членства в OPC Foundation — от 500 долларов в год
7. Уже существует множество SDK, в том числе и открытых
Вы там выше в комментариях упоминали про интеграцию… Так вот, запомните на всю свою последующую жизнь — стандартизация протоколов обмена данными является абсолютно необходимым требованием для успешной интеграции больших систем. А не «зато мы можем писать любые данные которые нам взбредет в голову».
Кстати, именно поэтому в OPC используется SOAP, а не REST. В REST на сегодня даже нет единого формата описания схемы ресурсов (несколько черновых и недоделанных — не в счет).