Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
по поводу iOS / Android / WP — неплохо покупают плагины и компоненты к кроссплатформенным движкам, типо Unity3d
В одном небольшом Java-проекте использовал библиотеку с интересной бизнес-моделью: сама библиотека бесплатна, но полная документация к ней за отдельную плату.
.NET
за этот год около $5.000 расходов на компоненты
за этот год около $5.000 расходов на компоненты
Javascript разработчики покупают.
Смысл тут в такой: если купить библиотеку/компопент/неведомую хрень/etc дешевле, чем написать самому/заказать фрилансеру, то покупают. Абсолютные суммы при этом никакой роли не играют. Это финансовый аспект.
И, конечно же, играет роль факт качества библиотеки/компонента/etc. С одной стороны, предпочтительнее купить нечто, если это нечто используется многими людьми, развивается и поддерживается, чем писать свой велосипед. С другой стороны, если это нечто явно заброшено автором, бывает лучше писать свой велосипед, а не разгребать чужой код.
Смысл тут в такой: если купить библиотеку/компопент/неведомую хрень/etc дешевле, чем написать самому/заказать фрилансеру, то покупают. Абсолютные суммы при этом никакой роли не играют. Это финансовый аспект.
И, конечно же, играет роль факт качества библиотеки/компонента/etc. С одной стороны, предпочтительнее купить нечто, если это нечто используется многими людьми, развивается и поддерживается, чем писать свой велосипед. С другой стороны, если это нечто явно заброшено автором, бывает лучше писать свой велосипед, а не разгребать чужой код.
Если посмотреть, что спрашивают на stackoverflow.com, то складывается ощущение, что все хотят получить все бесплатно или за минимальные деньги.
Как сотрудник компании построившей бизнес на продаже компонент, могу сказать что ощущение автора обманчиво. Те кто платят за компоненты, пишут к нам в саппорт, а не на стековерфлоу. Это все равно что мы напишем так:
Если посмотреть, что спрашивают на devexpress.com/support/center, то складывается ощущение, что все хотят использовать (или уже используют) наши компоненты за деньги.
Внесу свои 5 копеек. При разработке процессоров обычно компании тоже покупают ip-ядра, предварительно кем-то разработанные на verilog-е. Потому как тратить кучу времени на разработку своих интерфейсов USB, SD/MMC или тем более DDR и PCI-e никто не будет. Гораздо проще да и зачастую дешевле взять готовые блоки и собрать все как конструктор.
В любой области можно аналогию найти. Допустим я хочу построить кастомный велосипед. Я не стану плавить сталь и варить резину. Я просто куплю раму, колеса и обвес под свои хотелки. И даже если я изобрел велик нестандартной компоновки и буду варить кастомную раму, мне все равно пригодятся типовые колеса, тормоза и педали.
Если выполняются определенные условия, то почему бы не купить компонент? А условия просты:
— Адекватный заказчик/руководство
— По результатам анализа подходящих компонентов, платный компонент ушел в отрыв
— Адекватная стоимость компонента (как минимум дешевле разработки и поддержки подобного компонента собственными силами)
— В стоимость входит качественная поддержка
— Наличие исходных кодов (иногда такое необходимо, например, что бы убедиться, что компонент не навредит бизнесу)
На вскидку это основные пункты. Дополните, если что то забыл. Да, все это прежде всего относилось к Java проектам, но схожие пункты будут и при выборе компонентов для других технологий (разве что выбор бесплатных будет уже).
— Адекватный заказчик/руководство
— По результатам анализа подходящих компонентов, платный компонент ушел в отрыв
— Адекватная стоимость компонента (как минимум дешевле разработки и поддержки подобного компонента собственными силами)
— В стоимость входит качественная поддержка
— Наличие исходных кодов (иногда такое необходимо, например, что бы убедиться, что компонент не навредит бизнесу)
На вскидку это основные пункты. Дополните, если что то забыл. Да, все это прежде всего относилось к Java проектам, но схожие пункты будут и при выборе компонентов для других технологий (разве что выбор бесплатных будет уже).
Гхм… по моему истина простая. Если проще купить, чем написать, то ясно дело стоит купить.
Я работаю с несколькими программистами, так вот ни когда не понимал их упертости, что вот я напишу свое решение, оно будет лучше быстрее и конечно без всякого мусора.
На деле стоимость покупки скажем 100 баксов, стоит написать свое может быть 200 баксов. Но блин это же еще править придется… В результате мы тратим чуть ли не 1000 баксов на отладку выпуск билдов, и приходим к тем же костылям и шелухе, и таких ситуаций я видел вагон.
Вывод простой часто купить проще хотя бы потому, что у тебя результат есть здесь и сейчас, а не в какой то отдаленной перспективе. Кстати мое мнение, что как раз задача менеджера проекта принимать такие решения, чтоб не давать программистам изобретать собственные велосипеды.
Я работаю с несколькими программистами, так вот ни когда не понимал их упертости, что вот я напишу свое решение, оно будет лучше быстрее и конечно без всякого мусора.
На деле стоимость покупки скажем 100 баксов, стоит написать свое может быть 200 баксов. Но блин это же еще править придется… В результате мы тратим чуть ли не 1000 баксов на отладку выпуск билдов, и приходим к тем же костылям и шелухе, и таких ситуаций я видел вагон.
Вывод простой часто купить проще хотя бы потому, что у тебя результат есть здесь и сейчас, а не в какой то отдаленной перспективе. Кстати мое мнение, что как раз задача менеджера проекта принимать такие решения, чтоб не давать программистам изобретать собственные велосипеды.
Вы все верно говорите. Но к сожалению, в реальном мире не все так просто. И менеджеры с такими взглядами, как у Вас встречаются не так часто, как хотелось бы. А еще, за ними зачастую стоит еще более прижимистое руководство. И хорошо, если альтернатив нет. А если есть бесплатная альтернатива? Не важно какая. Когда менеджера или директора волновало удобство API, подробная документация, качество кода и наличие поддержки бесплатного компонента? Да, такое случается. Но чаще приходится слышать: мы будем использовать бесплатную библиотеку! И доводы, что мы с этим компонентом в последствии отгребем на сумму, превышающую стоимость платного компонента не прокатывают. Пока не наступят на грабли. А когда стоимость компонента переваливает за 1k $ — все только усугубляется…
С другой стороны, при своем (или по открытым лицензиям) компоненте код открыт для модификаций, его функциональность можно менять, в том числе расширять или сужать, оптимизировать код под разные условия и т. п.
А вы как заказчик готовы подождать в три раза дольше и заплатить в 5 раз больше? Просто из-за того что открытый код… Добавьте к этому, то что заказчик стремиться заплатить, как можно меньше и он я думаю очень расстроится узнав, что за его деньги разрабатывалось, то что он мог купить в 10 раз дешевле. Выгоду тут может получить только разработчик или компания разрабатывающая, так как не известно по какой лицензией еще выпустят этот код разработанный с нуля программистом.
Мои заказчики часто предпочитают именно подождать и заплатить (причем не факт, что заплатить больше вообще, не говоря о в 5-10 раз) чтобы иметь исключительные права на весь код своего приложения. Ну и код я обычно не под лицензией выпускаю, а передаю исключительные права заказчику по договору авторского заказа.
Если вернуться к моим комментариям выше, то мы говорили о том, когда писать свои библиотеки стоит дороже чем купить. Соотнося время требуемое на разработку (считай стоимость разработки) со стоимостью готового решения. Когда проще написать самим, то этот вопрос конечно не актуален, но ведь очень часто бывает, что свой велосипед обойдется заказчику в разы дороже.
Пускай дороже, но он получит исключительные права на написанный мной код и может делать с ним всё что хочет: использовать в разных своих проектах, продавать другим лицам, выложить в паблик и т. п. А при покупке будет ограничен лицензией зачастую разрешающей использование только одного экземпляра и даже чтобы сделать балансинг на два сервера ему нужно будет покупать две лицензии.
Если в рамках данного теста разработку с WordPress можно отнести к php, то да, я покупал плагины неоднократно.
Как я понимаю, в посте речь идёт именно о компонентах (уровня zf, yii), а не коробочных решениях (wp и битрикс).
Применительно к php это мог бы быть модуль к wp.
Применительно к php это мог бы быть модуль к wp.
В статье говорится конечно о библиотеках, но я думаю, что ситуация схожая и там и там… В свободно распространяемых CMS я думаю… что все обстоит гораздо хуже. Типа все же бесплатно, зачем еще за что-то платить, пойду варезник найду. При этом рядового сайто-клепателя не интересуют лицензии и прочие тонкости.
В использовании платного компонента, при наличии опен сорс аналогов праткически для всего, слишком много рисков.
— Качество может оказаться неудовлетворительным, и вендор не будет ничего с этим делать.
— Вендор может изменить лицензию, как ему захочется. Например брать больше денег.
— Отсутствие сорс кода негативно влияет на производительность разработчика при отладке
Сейчас, имеет смысл покупать только уникальные вещи, которых ни в одной опен сорс библиотеке в принципе не будет, например, yFiles www.yworks.com/en/products_yfiles_about.html Для остальных вещей разумнее либо взять опен сорс библиотеку, либо написать самому.
— Качество может оказаться неудовлетворительным, и вендор не будет ничего с этим делать.
— Вендор может изменить лицензию, как ему захочется. Например брать больше денег.
— Отсутствие сорс кода негативно влияет на производительность разработчика при отладке
Сейчас, имеет смысл покупать только уникальные вещи, которых ни в одной опен сорс библиотеке в принципе не будет, например, yFiles www.yworks.com/en/products_yfiles_about.html Для остальных вещей разумнее либо взять опен сорс библиотеку, либо написать самому.
При наличии готового компонента приемлемого качества практически никогда не будет разумнее писать самому.
А на ваши замечания насчет рисков можно ответить следующее:
— Большинство вендоров предлагают вначале скачать ознакомительную версию, с которой можно поиграться, выяснить все нюансы. Так же все возникающие вопросы можно обсудить с поддержкой. Если вендор отказывается предоставлять ознакомительную версию и отвечать на ваши вопросы — тут что то не чисто и, наверное, не стоит платить за этот компонент. Хотя, конечно, и тут наверняка есть исключения.
— При покупке компонента ты заключаешь договор, и после его заключения условия оплаты меняться не могут. Теоретически. Правда тут я не силен, юридические аспекты лучше решать с юристами. Но в моей практике как раз с этим проблем не было.
— Многие вендоры (по крайней мере это касается Java) предоставляют source код, иногда за дополнительную плату. Наличие сырцов — это конечно огромный плюс, но и без него можно обойтись. В случае возникновения ошибок, которые растут из купленной библиотеки, они решаются письмом в поддержку.
А покупать стоит не только уникальные решения, но и просто качественные, с удобным API и отзывчивой поддержкой. А самому писать стоит только ну очень уникальные решения, когда все остальное просто не справляется с вашими конкретными задачами.
А на ваши замечания насчет рисков можно ответить следующее:
— Большинство вендоров предлагают вначале скачать ознакомительную версию, с которой можно поиграться, выяснить все нюансы. Так же все возникающие вопросы можно обсудить с поддержкой. Если вендор отказывается предоставлять ознакомительную версию и отвечать на ваши вопросы — тут что то не чисто и, наверное, не стоит платить за этот компонент. Хотя, конечно, и тут наверняка есть исключения.
— При покупке компонента ты заключаешь договор, и после его заключения условия оплаты меняться не могут. Теоретически. Правда тут я не силен, юридические аспекты лучше решать с юристами. Но в моей практике как раз с этим проблем не было.
— Многие вендоры (по крайней мере это касается Java) предоставляют source код, иногда за дополнительную плату. Наличие сырцов — это конечно огромный плюс, но и без него можно обойтись. В случае возникновения ошибок, которые растут из купленной библиотеки, они решаются письмом в поддержку.
А покупать стоит не только уникальные решения, но и просто качественные, с удобным API и отзывчивой поддержкой. А самому писать стоит только ну очень уникальные решения, когда все остальное просто не справляется с вашими конкретными задачами.
>— При покупке компонента ты заключаешь договор, и после его заключения условия оплаты меняться не могут. Теоретически. Правда тут я не силен, юридические аспекты лучше решать с юристами. Но в моей практике как раз с этим проблем не было.
Ну вот, пример ситуации. Вы покупаете продукт, который позволяет писать iOS приложения. Например решение от Xamarin. Apple известно тем, что с релизом новой OS заставляет девелоперов переходить на последнии API. В случае если лиценизя на новую версию изменится, вы получаете тут попадос. Если на этом построен ваш бизнес, ему может наступить хана.
>А покупать стоит не только уникальные решения, но и просто качественные, с удобным API и отзывчивой поддержкой. А самому писать стоит только ну очень уникальные решения, когда все остальное просто не справляется с вашими конкретными задачами.
Я с таким очень давно не сталкивался. Сейчас очень много open source проектов, которые могут делать практически все что угодно.
Ну вот, пример ситуации. Вы покупаете продукт, который позволяет писать iOS приложения. Например решение от Xamarin. Apple известно тем, что с релизом новой OS заставляет девелоперов переходить на последнии API. В случае если лиценизя на новую версию изменится, вы получаете тут попадос. Если на этом построен ваш бизнес, ему может наступить хана.
>А покупать стоит не только уникальные решения, но и просто качественные, с удобным API и отзывчивой поддержкой. А самому писать стоит только ну очень уникальные решения, когда все остальное просто не справляется с вашими конкретными задачами.
Я с таким очень давно не сталкивался. Сейчас очень много open source проектов, которые могут делать практически все что угодно.
Сейчас очень много open source проектов, которые могут делать практически все что угодно.
И тем не менее, посмотрите сколько собственных решений написали для себя Facebook, VKontakte и прочие. Все очень сильно зависит от задачи и от масштабов.
Ну вот, пример ситуации. Вы покупаете продукт, который позволяет писать iOS приложения. Например решение от Xamarin. Apple известно тем, что с релизом новой OS заставляет девелоперов переходить на последнии API. В случае если лиценизя на новую версию изменится, вы получаете тут попадос. Если на этом построен ваш бизнес, ему может наступить хана.
Повторюсь, что я не специалист в области права, а так же не знаком с решениями от Xamarin и условиями их распространения — я тружусь несколько в другой области. Но могу сказать только одно: внимательно читайте условия договора… И еще, ваше приложение должно быть абстрагировано от используемых компонентов. Купленная библиотека помогла Вам быстро стартануть и выйти на рынок? Отлично! В следующей версии вы не можете ее использовать? Что ж, берем другой компонент и подпихиваем его в приложение. Если все было правильно сделано изначально, то это не потребует больших затрат. И даже разработка своего компонента в этом случае будет уже более осмысленной, т.к. Вы получили значительный опыт использования стороннего компонента, Вы прощупали все его достоинства и выявили недостатки и теперь вам не составит труда избежать большинства граблей, на которые вы обязательно наступите, если будете писать все с нуля сразу. Что же касается факапа в бизнесе, то тут еще при оценке необходимости покупки компонента Вы должны учитывать этот риск.
А почему, кстати говоря, вы приравниваете платность и отсутствие исходного кода?
UPD: каюсь, не заметил сразу, что ISergius уже задал этот вопрос. С другой стороны, KonstantinSolomatov его в ответе проигнорировал.
UPD: каюсь, не заметил сразу, что ISergius уже задал этот вопрос. С другой стороны, KonstantinSolomatov его в ответе проигнорировал.
С ужасом представил что DevExpress GridControl надо написать самостоятельно.
За последнее время потратил около $2к на компоненты разных компаний (DevExpress, Devart, FastReport и т.д.).
За последнее время потратил около $2к на компоненты разных компаний (DevExpress, Devart, FastReport и т.д.).
DevExpress Universal этим летом купил для одного разработчика. Стоимость покупки ~70к, это в два раза меньше стоимости одного месяца работы разработчика (с налогами).
Считай даже не сэкономил, а заработал.
Считай даже не сэкономил, а заработал.
А вот интересно: возможно под .Net так активно покупают платные компоненты в том числе потому, что под эту платформу действительно есть качественные компоненты с хорошей документацией и поддержкой? Не случайно здесь так много пишут про DevExpress.
Может быть такой ход мыслей и логичен, если человек берет бесплатную Ubuntu, ставит бесплатную IDE для бесплатного PHP и приступает к зарабатыванию денег.
Не редко из этого списка присутствует только бесплатный PHP и то за него платишь хостеру. Хотя несколько раз рассматривал возможность покупки платных модулей для бесплатных CMS на PHP, но отказался после обсуждения с заказчиком. Из причин:
— невнятная или неподходящая лицензия. Больше всего запомнился запрет на передачу третьим лицам: если покупает заказчик, то не может передать мне, если я — то заказчику. Заказчик должен был сам поставить на сервер, а я интегрировать его в систему только на сервере, никаких локальных дев-серверов. Ещё запреты на модификацию даже если исходники физически открыты. Запрет на реверс-инженеринг обфуцированных.
— недоступность исходных кодов вкупе с необходимостью менять окружение (Zend Guard например ставить);
— заоблачная цена, рассчитанная видимо на многократное использование в разных продуктах;
— медленная реакция продавца (один раз через неделю с лишним ответил, когда уже весь проект был сдан, а с помощью либы планировалось день сэкономить);
— невнятная реакция продавца на вопросы об юридическом и бухгалтерском оформлении «киньте мне на вебмани, а я вам письмо с архивом пришлю, что ещё надо?»
За хорошие компоненты и заплатить не жалко. Плохо, что отдав 1.5-2 тыс. долларов за DevExpress, бывает страшно переходить на следующий минорный релиз.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кто покупает библиотеки и компоненты?