Специфика использования open-source проектов

  Как принято считать, стоимость исправления дефектов в ПО тем ниже, чем раньше стадия, на которой этот дефект был выявлен.Эта теорема не раз доказана практикой тысяч конкретных программных проектов. Тестирование идей и требований пока еще звучит как экзотика. Но стимуляция разработчиков к более тщательному выходному контролю кода уже стала нормой. Программисты клепают unit-тесты ( и теперь уже кто-то даже до написания логики ), многие обзаводятся своими собственными тестовыми стендами, и даже прогоняют на них основные по их мнению варианты. Этому нельзя ни радоваться и это нельзя не приветствовать. Но мышление разработчика остается мышлением разработчика. О многих вариантах использования, вариациях входных данных ему думать не досуг. И это правильно. Там, где за разработчиками стоят грамотные тестировщики, можно не беспокоиться - они позаботятся о проверке всех нужных вариантов, в том числе и довольно редких, но все-таки нужных.
  Но не все программные проекты подвергаются экзекуции тестировщиками, не все проекты проходят стадию "тестирования" перед выпуском в свет.. Особенно это касается многих open-source решений. Среди них много таких, которые кроме unit-тестирования никакого более тестирования не проходят. Баги ловят реальные пользователи, кто-то постит их в открытые багтреккеры и, если проект продолжает поддерживаться, он постепенно становится лучше. Бывает так, что баг висит годами без фиксов и пользователям этого открытого софта, библиотеки приходится патчить самим. Все бы ничего, схема работает. Да здравствует open source и GPL в руки! Но когда речь идет о создании коммерческого софта с использованием открытых библиотек, то не все удосуживаются анализировать используемый сторонний (3rd party) софт на наличие ошибок. Вот и вылезают потом неожиданности в виде багов, которые непонятно кому исправлять - то ли ждать фиксов от авторов сторонней софтины, то ли самим патчить. Если самим , то как это сделать так, чтобы не сломать - а для этого надо разобораться с внутренней архитектурой стороннего решения...
   В общем, не так гладко может все сложиться. А ведь даже поверхностный анализ баг-треккера той или ной открытой либы может помочь понять , стоит ее использовать в коммерческой разработке или нет.

• Покрыта ли библиотека unit-тестами, если да , то на сколько ? 
• Проходят ли unit-тесты в окружении, в котором планируется использовать будущий коммерческий софт? 
• Даже если внешне все гладко, то не стоит ли поручить тестировщикам помучать с помошью заглушек эту библиотеку и дать свою экспертную оценку о ее качестве?  

Ответ на последний вопрос, конечно же, не может быть однозначным - все решается на месте в данных конкретных условиях.

  Одно ясно точно - использовать open-source разработки в коммерческих проектах надо обязательно ( чтобы не изобретать велосипедов) , но чтобы потом не переписывать половину кода, из-за того, что "либа оказалась Г..", все сторонние решения надо тщательно анализировать.

+27 к жизни

Помните песню Сюткина "ежедневно 42 минуты под землей", где он складывал в года время, потраченное на езду в метро?

Песня - песней, а для многих жителей мегаполиса и окружающих его окраин - это большая проблема... Например, я до недавнего времени тратил час - полтора на дорогу только в одну сторону. Было много причин, для того, чтобы мириться с этим положением дел. Было много компромиссов в виде аудиокниг (если в машине), читалок с полезным контентом (если на общ.тренспорте), прослушанных курсов английского и так далее...
Но простая арифметика показывала , что в год набегало что-то около 27 дней только на стояние в пробках, у которых пока не видно тенденции к уменьшению.. И когда я просто физически перестал успевать делать многие важные вещи, когда терпение лопнуло и здравый смысл перевесил все эмоции, то я перебрался поближе к основному месту работы. Какая красота - 15 минут от двери до двери!
Теперь в моем распоряжении совсем не лишних ~27 дней в году, которые можно как минимум потратить на хороший отдых )

Вот такой вот тайм-менеджмент...