Комментарии 46
Арифметика действительно простая, но на первый взгляд (и далеко не для всех) очевидная. Только когда сам через это проходишь — убеждаешься, что купить вышло бы дешевле и надёжнее как для разработчика, так и для клиента.
На примере проекта существующего более 8 лет, в котором изначально никто не задумывался о составе используемых компонентов:
— проект становиться тяжело портируемым под новые версии сред разработки;
— трудно добавлять новый функционал в купленные с исходниками компоненты (каждый пишет как ему удобно);
— сторонние компоненты с исходниками после правки под себя, перестают развиваться и у Вас есть своя правленная версия, а разработчики идут своим путем.
При написании своих компонентов Вы сами решаете в какую сторону их развивать, может оказаться так, что при обновлении сторонних компонентов в новой версии не окажется необходимой функции.
— проект становиться тяжело портируемым под новые версии сред разработки;
— трудно добавлять новый функционал в купленные с исходниками компоненты (каждый пишет как ему удобно);
— сторонние компоненты с исходниками после правки под себя, перестают развиваться и у Вас есть своя правленная версия, а разработчики идут своим путем.
При написании своих компонентов Вы сами решаете в какую сторону их развивать, может оказаться так, что при обновлении сторонних компонентов в новой версии не окажется необходимой функции.
НЛО прилетело и опубликовало эту надпись здесь
ИМХО, всё перечисленное — это проблемы архитектуры конкретного продукта, а не использования сторонних компонент (о чём, собственно, и повествует первый абзац). Если делать из продукта свалку решений (чужих и собственных) то при любом раскладе ничего хорошего из этого не получится.
а еще проще поискать на просторах opensource, ведь существует немалое количество достойных бесплатных компонентов, grid для delphi — EhLib
бесспорно devexpress тоже достойные компоненты, но смысл покупки оправдан только если будет окупаемость и желательно после 1-го проекта)))
бесспорно devexpress тоже достойные компоненты, но смысл покупки оправдан только если будет окупаемость и желательно после 1-го проекта)))
Как-то всё утрировано.
По времени: если разработчик не один, то разработка будет идти быстрее (по календарному времени), а вот разбирательство и осваивание вряд ли. А если вспомнить про ротацию кадров, то покупка закрытого решения может оказаться ещё дороже (каждому новому сотруднику придётся разбираться, были бы исходники — разбираться было бы быстрее)
По деньгам: написав свой компонент, его тоже можно потом продать и окупить затраты многократно (это я услышал от своего бывшего начальника как-то на предложение купить сторонний софт), в случае с покупкой перепродажа, как правило, запрещена.
Ну и самое главное, не рассмотрена ещё одна альтернатива — разрабатывать не с нуля, а на основе свободных решений, имеющих часть необходимой функциональности (правда тут тоже может быть проблема с начальником, которому надо объяснить, что в некоторых случаях нужно открывать свои доработки, но это проще, чем уговорить его платить деньги :) )
По времени: если разработчик не один, то разработка будет идти быстрее (по календарному времени), а вот разбирательство и осваивание вряд ли. А если вспомнить про ротацию кадров, то покупка закрытого решения может оказаться ещё дороже (каждому новому сотруднику придётся разбираться, были бы исходники — разбираться было бы быстрее)
По деньгам: написав свой компонент, его тоже можно потом продать и окупить затраты многократно (это я услышал от своего бывшего начальника как-то на предложение купить сторонний софт), в случае с покупкой перепродажа, как правило, запрещена.
Ну и самое главное, не рассмотрена ещё одна альтернатива — разрабатывать не с нуля, а на основе свободных решений, имеющих часть необходимой функциональности (правда тут тоже может быть проблема с начальником, которому надо объяснить, что в некоторых случаях нужно открывать свои доработки, но это проще, чем уговорить его платить деньги :) )
Есть среди заказчиков такие потрясающие личности, которые хотят продавать все, что для них сделано. Вплоть до тог доходит, что им на сайт нужно гостевую книгу поставить, но при этом разработав ее с нуля чтобы можно было ее продавать для других проектов…
Встречаются, но и оплату с них надо брать соответствующую и пускай продают. А вообще надо различать ситуации, когда заказчик заказывает именно разработку софта (тогда, обычно, все права ему принадлежать), а когда ему нужна функциональность, и не важно откуда она возьмётся — напишите снуля, используете свои другие наработки или вообще возьмёте open-source.
У DevExpress исходники тоже доступны (за дополнительные, но отнюдь не запредельные деньги).
Конечно, это не Open Source, но только в том смысле, что вы не имеете права эти исходники распространять. А изучать, отлаживать и дорабатывать для себя — пожалуйста.
А рассчитывать на то, что написанный для своих нужд компонент удастся продать… Всякое может быть, но конкурировать с фирмами, занимающимися этим профессионально, будет очень сложно.
Конечно, это не Open Source, но только в том смысле, что вы не имеете права эти исходники распространять. А изучать, отлаживать и дорабатывать для себя — пожалуйста.
А рассчитывать на то, что написанный для своих нужд компонент удастся продать… Всякое может быть, но конкурировать с фирмами, занимающимися этим профессионально, будет очень сложно.
А у кого-нибудь из присутствующих был опыт продажи компонентов, разработанных в ходе реализации другого проекта? Поделитесь историей.
Скачиваете компоненты и делаете за пару дней на них пробное решение. Если всё хорошо, то вполне вероятно, что ваш выбор удачен
Я бы поспорил. Только после полутора месяцев использования Silverlight грида от Infragistics всплыла достаточно серьезная проблема, которую пришлось решать ректальным путем. Они просто не предполагали, что это понадобится. Результат — нервы начальства и работа разработчика на грани увольнения. Ну и, помимо этого, постоянное допиливание до нужного функционала, по мелочам.
Скорее всего требования при выборе компонентов были поставлены не правильно, либо вообще не поставлены. У каждой задачи есть конкретные требования, выявляемые путем анализа. Если Вы этого не сделали, то результат не удивляет. Другое дело, когда компонент не удовлетворяет требованиям новой задачи, но здесь уж как певезет.
С самописным кодом от этого тоже никто не застрахован
Что у вас за начальство такое, что за чужие ошибки — сразу работа на грани увольнения.
Это не ошибка была, просто для выполнения новой задачи стал нужен дополнительный функционал, который не был реализован в гриде.
А работа на грани увольнения — это, конечно, достаточно образно :) Но неприятностей было бы немало. Жесткий график, серьезный клиент и неожиданное препятствие. Нервная работа у нас, однако… *удерживая дергающуюся бровь руками* Хе-хе…
А работа на грани увольнения — это, конечно, достаточно образно :) Но неприятностей было бы немало. Жесткий график, серьезный клиент и неожиданное препятствие. Нервная работа у нас, однако… *удерживая дергающуюся бровь руками* Хе-хе…
У меня всплыла ректальная проблема с Silverlight DataGrid ;)
А какой грид для сервелата теперь посоветуете?
А какой грид для сервелата теперь посоветуете?
Неожиданно увидеть DX на Хабре. Текущий проект на работе целиком и полностью построен на компонентах DevExpress'а с небольшими вкраплениями наших контролов, наследованных, опять же, от DX. Изначально он брался из-за нескольких контролов (отчетник очень уж лют :)), но потом стали использовать все.
Использование сторонних компонентов в общем-то палках о двух концах: с одной стороны, освобождаешь себя от написания, с другой стороны, меньше контролируешь и ответственность переносится на вендора. DevExpress'ом в общем-то довольны. Какие-то баги с их стороны за 2 года моей работы в проекте появлялись пару раз и саппорт всегда присылал решение. Документация действительно на высшем уровне.
Использование сторонних компонентов в общем-то палках о двух концах: с одной стороны, освобождаешь себя от написания, с другой стороны, меньше контролируешь и ответственность переносится на вендора. DevExpress'ом в общем-то довольны. Какие-то баги с их стороны за 2 года моей работы в проекте появлялись пару раз и саппорт всегда присылал решение. Документация действительно на высшем уровне.
DevExpress — это самый крупный и серьезный проект сторонних компонентов, который я видел за свою рабочую историю. И насколько я сталкивался с некоторыми компонентам — сделано все очень грамотно и работает хорошо. Конечно возникали и нестыковки и находились ошибки, но без этого не обойтись.
И хотелось бы, чтоб кто-то, так же серьезно занялся разработкой компонентов для Qt.
А по теме — очень согласен, более того в мире Delphi использование сторонних компонент — это была один из основных подходов. Поэтому компонентов наплодили очень много.
И хотелось бы, чтоб кто-то, так же серьезно занялся разработкой компонентов для Qt.
А по теме — очень согласен, более того в мире Delphi использование сторонних компонент — это была один из основных подходов. Поэтому компонентов наплодили очень много.
А как же Telerik? Очень плотно покрывают всё для C#/.net
ну DevExpress намного древней. А главное — я ничего не знаю о Telerik так как ушел из мира Windows, когда появилась технолгия .NET (не из-за нее :-), а просто так получилось).
Именно поэтому и написал, что «за свою рабочую историю».
Именно поэтому и написал, что «за свою рабочую историю».
Все пытаюсь себя заставить попробовать Телерик в деле, но убивают скины их контролов — после DevExpress, выглядят просто ужасно
DevExpress — всегда радовали своей документацией. Вы делаете отличный продукт. прикрутите шаблоны к экспорту в хтмл, пожалуйста… :)
А вот и наши подтянулись. Welcome! )
Со стоимостью не все так просто: обычно компоненты продаются с лицензиями на каждый компьютер (или очень дорогая enterprise версия) и если программистов много, то стоимость всех лицензий может превысить стоимость собственной разработки.
Кроме того, купленный компонент не будет делать сразу то, что от него требуется — к нему тоже надо писать какой-то код, разбираться в документации и т.п.
Мы одно время использовали купленные компоненты (правда, купили только одну лицензию), но со временем стали постепенно мигрировать на самописные.
Кстати, грид раньше действительно был камнем преткновения в средствах разработки от Microsoft, т.к. в стандартной поставке не было ничего достаточно функционального. Но с выходом .NET 2.0 появился отличный грид. Он не такой навороченный, как DevExpress, но основную функциональность он покрывает.
Кроме того, купленный компонент не будет делать сразу то, что от него требуется — к нему тоже надо писать какой-то код, разбираться в документации и т.п.
Мы одно время использовали купленные компоненты (правда, купили только одну лицензию), но со временем стали постепенно мигрировать на самописные.
Кстати, грид раньше действительно был камнем преткновения в средствах разработки от Microsoft, т.к. в стандартной поставке не было ничего достаточно функционального. Но с выходом .NET 2.0 появился отличный грид. Он не такой навороченный, как DevExpress, но основную функциональность он покрывает.
С лицензиями кстати у всех по-разному. У нас, например, лицензия на разработчика, а не на компьютер. Т.е. если проект удаётся толково разделить на модули, то вполне реально экономить и при этом не нарушать лицензию. Впрочем, подход с одной лицензией на 100 человек тоже никто не отменял.
Обычно у каждого разработчика свой компьютер, так что разницы особой нет, разве что лицензию проще нарушить, т.к. привязаться к разработчику вместо компьютера сложнее.
У нас было разделение на разные модули, в том числе и на UI, бизнес логику и т.д., но разработчики делились по функциональному принципу (финансовый модуль, склад и т.п.). Т.е. каждый разработчик занимался и UI и бизнес логикой, т.е. нуждался в лицензии.
Делить разработчиков на UI и бизнес нереально в сложных проектах, т.к. в этом случае все разработчики должны быть в курсе _всех_ бизнес процессов.
У нас было разделение на разные модули, в том числе и на UI, бизнес логику и т.д., но разработчики делились по функциональному принципу (финансовый модуль, склад и т.п.). Т.е. каждый разработчик занимался и UI и бизнес логикой, т.е. нуждался в лицензии.
Делить разработчиков на UI и бизнес нереально в сложных проектах, т.к. в этом случае все разработчики должны быть в курсе _всех_ бизнес процессов.
В нашем проекте начали использования компонента dhtmlxGrid (благо была урезанная бесплатная версия). В итоге, через два года использования в проекте — решено в обязательном порядке от него отказаться, как и от любых других сторонних.
Причины банальны и просты: 1) иногда функционала не достаточно, 2) иногда функционал излишен, 3) массивность библиотек, 4) специфика использования, 5) сложность описания «простых» задач…
В итоге был написан грид своими силами в домашних условиях («для себя») за 2 недели, который полностью устраивает по функционалу и весит (это важно) в 30 раз меньше.
Всё сугубо субъективно. Решайте ДО использования. Думайте о будущем проекта — оно покажет необходимость использования сторонних компонент, а не текущие задачи или «нравится внешне».
Причины банальны и просты: 1) иногда функционала не достаточно, 2) иногда функционал излишен, 3) массивность библиотек, 4) специфика использования, 5) сложность описания «простых» задач…
В итоге был написан грид своими силами в домашних условиях («для себя») за 2 недели, который полностью устраивает по функционалу и весит (это важно) в 30 раз меньше.
Всё сугубо субъективно. Решайте ДО использования. Думайте о будущем проекта — оно покажет необходимость использования сторонних компонент, а не текущие задачи или «нравится внешне».
Ооо, любимые графики от ДевЭкпресса. Мы их выбрали за то, что они умеют сериализоваться :-)
Было вот какое дело, давно правда. Использовал ваши компоненты, но когда вышла более новая версия, то вся структура очень сильно поменялась, вплоть до названия мемберов и типов данных. Пришлось много переписывать :-)
А компоненты красивые, заказывать однозначно.
А компоненты красивые, заказывать однозначно.
а вариант взять готовое опенсорсное не рассматривал ваш коллега? почему вопрос ставится именно так: купить или написать самому?
Вопрос ставился «сколько времени займёт написать»?
Open source тоже вполне себе вариант, особенно если бюджет ограничен.
Как и у любого другого варианта тут есть свои плюсы и минусы.
Из серьёзных минусов я бы отметил следующее. Можно найти open source грид. Можно найти бары. Т.е. многое можно подобрать под свои нужды, но по отдельности. Могут возникнуть сложности при попытке заставить это всё нормально работать в связке. Надо обязательно проверять. Документация и саппорт также не всегда на высоте.
Open source тоже вполне себе вариант, особенно если бюджет ограничен.
Как и у любого другого варианта тут есть свои плюсы и минусы.
Из серьёзных минусов я бы отметил следующее. Можно найти open source грид. Можно найти бары. Т.е. многое можно подобрать под свои нужды, но по отдельности. Могут возникнуть сложности при попытке заставить это всё нормально работать в связке. Надо обязательно проверять. Документация и саппорт также не всегда на высоте.
Тут коммерческие компоненты хорошего качества с трудом найдешь, а вы про опен-сорс…
Ооо! Я вас люблю! Прикуел, если честно, когда узнал что вы из России! Компоненты у вас препрекрасные! cxGrid просто великолепен! Использую, к сожалению пиратские билды, прямо признаюсь… Но от продукта в восторге полном!!! У меня даже кот монитор нюхает когда видит Ваш dxBarManager! Может быть слишом много восторга, но Ваши продукты и впрям облегчили жизнь мне, как разработчику! Спасибо Вам! P.S. ну поделиииитесь лицензией пожалуйста, ну поделиииитесь! =)
В случае с DevExpress, как раз переживать нечего. Заплатив деньги (хотя и не малые) можно быть спокойным, что обновления будут вовремя сделаны, баги исправлены, и т.д.
Если же речь идет о менее именитых наборах компонентов, то тут как раз не все так очевидно. Хотя и цены там значительно либеральнее. Например, вполне можно отдать $50 и за GridEh, даже если автор «устанет» сопровождать библиотеку, полтинник — не те деньги, что бы писать подобный продукт самому.
PS
Рад увидеть DevExpress на Хабре!
Если же речь идет о менее именитых наборах компонентов, то тут как раз не все так очевидно. Хотя и цены там значительно либеральнее. Например, вполне можно отдать $50 и за GridEh, даже если автор «устанет» сопровождать библиотеку, полтинник — не те деньги, что бы писать подобный продукт самому.
PS
Рад увидеть DevExpress на Хабре!
Вопрос к DevExpress — почему компоненты для Silverlight Grid, Menu etc… заточены под нечеловечески большие шрифты?
Почему под WinForms шрифты нормального размера.
Почему под WinForms шрифты нормального размера.
Эта логика легко масштабируется на «а зачем вообще заказывать разработку если можно купить готовый продукт и настроить?»
Мой скромный опыт подсказывает, что контролов в VS достаточно для всех разумных желаний заказчика в области интерфейса. Если заказчик хочет странного то проще потратить пол дня и убедить его отказаться от странного, а не тратить пол-года на реализацию его ночного сновидения.
Ну а если речь об опенсоурс то вопросов меньше — все библиотеки и контролы доступны.
Мой скромный опыт подсказывает, что контролов в VS достаточно для всех разумных желаний заказчика в области интерфейса. Если заказчик хочет странного то проще потратить пол дня и убедить его отказаться от странного, а не тратить пол-года на реализацию его ночного сновидения.
Ну а если речь об опенсоурс то вопросов меньше — все библиотеки и контролы доступны.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Сторонние компоненты — деньги на ветер или экономия средств?