На мысль натолкнуло исправление очередного бага в Ajax Control Toolkit.
 

Часто мы в проектах, чтобы не изобретать велосипед, используем уже готовые инструменты. Иногда это open source приложения/библиотеки. И что делать, если нам не хватает функциональности этих библиотек или надо срочно исправить какуе-то ошибку? Первая же мысль - это взять исходники, подправить/дописать, после чего скомпилировать и радоваться жизни. Но радоваться будем недолго, до выхода новой версии этой замечательной библиотеке, в которой есть необходимые изменения. Приходится качать исходники, опять вносить туда свои изменение, компилировать и т.д. В процессе этого пишуться письма авторам библиотеке, создаются новые запись в ихнем багтрекере, но необходимых изменений в очередной версии мы так и не получаем.

После нескольких таких итераций голову приходит очередная мысль (нет, не отказаться от этого продукта): "А, может, не будем изменять исходники? Может, просто приспособимся к их API или сделаем класс-наследник и добавим в него недостающую функциональность?". В этот момент начинает казаться, что пользы от open source становится всё меньше и меньше. При таком подходе переход на новую версию используемой библиотеке становится менее болезненным, но мы не застрахованы, что в новой версии ничего не изменится и не поломает нашу функциональность.

И вот с выходом новой версии библиотеки, в которой, конечно же, есть новые, жизненно-важные, для нас функции, мы долго размышляем, сомневаемся, но всё же приходим к решению использовать её. Но всё оказалось не так хорошо, как хотелось: API поменялся, наши изменения не работают, а проект вообще не компилируется. В этот появляется третья мысль, относительно используемой библиотеке: "Ведь нам не нужна все её функциональность?! Давайте напишем свою! Там будет только то, что нам нужно и не будет лишних багов, нас не будет волновать выход новой версии...". И все дружно начинают писать свою версию open source библиотеки, стараясь не сделать ошибок своих предшественников и делаю новые, но свои, ошибки...

Возможен так же сценарий, в котором на каком-то из этапов принимается решение отказаться от библиотеки А и использовать библиотеку В. А знаю, что использование готовых продуктов на первых порах ускоряет написание и выпуск своего продукта, но, в будущем, вполне вероятно что прийдётся отказаться и использовать что-то другое. И это займет намного больше времени, чем внедрять это в начальных стадиях разработки проекта.

Нет определенного ответа на вопрос "Использовать библиотеку А, В,заплатить за библиотеку С или написать свою?". Все зависит от конкретного случая и выбор, временами, сделать очень трудно. Интересно, какие у вас мысли по этому поводу? Аналогичная, по моему мнению, и ситуация с использованием CMS для сайта: писать свою, взять готовую или на основе готового написать свою?

P.S. Всё это я рассмотрел со стороны рядового разработчика и не учитывал влияния заказчика PM-а и других заинтересованных сторон.


Comments

Kosinsky Ukraine

Friday, March 27, 2009 4:13 PM

Kosinsky

Глупый вопрос, а почему нельзя отослать патч, который фиксит баг и помочь не только себе? Это же OpenSource

mihasic Ukraine

Friday, March 27, 2009 4:44 PM

mihasic

Глупый вопрос, а почему нельзя отослать патч, который фиксит баг и помочь не только себе? Это же OpenSource
на многие продукты патчи рассматриваются очень вяло, касательно ajax control toolkit достаточно взглянуть на патчи (и их даты), которые до сих пор рассматриваются

Kosinsky Ukraine

Friday, March 27, 2009 5:08 PM

Kosinsky

Я когда-то отсылал в Atlas ASP.NET, когда все еще в кучу было. Они его быстро приняли

e0ne

Friday, March 27, 2009 5:14 PM

e0ne

Ajax Control Toolkit был только для примера. И не все присланные им патчи они быстро добавляют в код

Mike Chaliy

Friday, March 27, 2009 6:11 PM

Mike Chaliy

Та намана все приймають, там можна розробників пошукати, я робив декілька патчей, іноді розробників надо пнути, сказати що дуже потрібно, там завжди люди з ними можна размовляти.

whirlwind Ukraine

Saturday, March 28, 2009 11:23 AM

whirlwind

є ще один варіант -- взяти актуальну версію чужих кодів і тупо приєднати їх до свого проекту.  Правда, виникне інша проблема: треба буде час від часу заглядати до сусідського багтрекеру, чи не було там виявлено якихось занадто критичних багів. І збірка проекту при цьому ускраднюється, що теж не добре.

vansha Ukraine

Sunday, March 29, 2009 1:31 AM

vansha

В статті "Don't Like It? Code it Yourself! ("www.codinghorror.com/blog/archives/001247.html) Jeff Atwood пропонує пропонує проспонсорувати реалізацію тих фіч чи багів, які вам життєво необхідні.



Глеб Russia

Friday, April 10, 2009 8:51 PM

Глеб

Это беда не только опенсорсных продуктов: мы тут движок форума купили (один из самых известных), так там тоже баг на баге, приходится править. Плюс фичи, которые сами дописали. С ужасом думаю, как будем переводить его на новую версию, когда она выйдет...

Comments are closed