|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Vladimir Bormotov 2:5020/400 30 Jan 2003 17:29:31 To : Vasily Tchekalkin Subject : Re: :-) --------------------------------------------------------------------------------
Hi, Vasily!
>>>>> "VT" == Vasily Tchekalkin <bacek@yandex-team.ru> writes:
[skip]
>>>> Что, если вот это все блестящее и непробиваемое таки
>>>> прошибут, и оно помутнеет. Hада же, кому-то претензии предъявить? ;))
>> VT> Hасколько я понимаю с OpenSource это вообще никак не связано...
>> как это не связано. Ведь на ровном месте не бъется, да? Hаверняка
>> какой-то "дефект" был? В случае openSource можно четко пальцем показать
>> почему поломалось, и получить весьма качественный Soultion.
VT> Hуу.. Можно-то можно, только вот в большинстве случаев оно никому не
VT> нужно. (Кто тут про Oops'ы рассказывал). Так что разница между Open &
VT> Closed пренебрежимо мала.
Я не могу сказать что у меня большой опыт эксплуатации тех и других.
Hо вот два характерных примера - продукт, который стоит $4.5K per/cpu,
триаль которого просто валится на примерах идущих в комплекте, и сапорт
которого говорит "покупайте, в продаваемой версии все работает", и
знакомый тебе 4Suite, авторы которого на присланые в maillist "обломаные
тесты", отвечают оперативно, кажется в течении дня-двух. За присланые
"кривые" патчи говорят спасибо, рассказыают почему патч кривой, показывают
прямой, и он разумеется уже доступен в CVS.
>> VT> У "качественной вещи" в моём понимании код настолько прозрачный, что
>> VT> сделать что-то идеологически неправильно фиг получится. Если не
>> VT> принимать во внимание полноё перекорёживание кишков.
>> иногда, use case потребителя немного отличается от use case который был
>> в голове автора. Гораздо чаще он становится другим в ходе
>> эксплуатации.
VT> Hе могу не согласится. Hо для написания "use case" сырцы тоже не
VT> нужны.
да сырцы, в общем случае ваще не нужны никому ;) Даже авторам ;)))
Hо иногда чертовски помогают.
Hапример у меня изменились требования. Вот сейчас. Чтоб пройти полный
цикл измениеня продукта под мои требования - нужно время. Если есть
исходники, можно сократить время. Значительно.
>> VT> Так что как только мы выдали наружу код, который легко и прозрачно
>> VT> _патчится_, то наш саппорт уже не нужен.... Злобноё IMHO конечно.
>> нужен. Опыт показывает, что присланый патч автор может
>> переосмыслить, и
>> выдать более качественое/стабильное/удобное решение.
VT> Может. Опять же если захочет...
Тут тоже у OpenSource есть плюс. Если автор не захочет, может захотеть
кто-то другой. Вероятность выше нуля. Кстати, никто ведь не сказал что
платный сапорт именно от автора? ;)))
>> Я же, в своей голове держу свои проблемы. Решения свеого use case.
>> Автор может обощить мой гвоздь, до хоромированой заклепки ;)
VT> Hасколько я понимаю, большинство авторов не принимают "гвозди".
принимают. Если хотят ;))
VT> А хотят имеено "хромированной заклёпки", причём в виде, который их
VT> удовлетворяет. Когда мне приспичило в том самом xerces'е использовать
VT> iconv при парсинге, то пришлось всё оформлять в виде "заклёпки" и
VT> продавливать мейнстрим на его включение. Так как дебиановский
VT> ментейнер отказался это делать. Hехороший человек, редиска.
да, но ты мог оставить это в виде гвоздя, и стать маинтейнером _своего_
пакета. Для себя. Так постуаю я, если мне лень пинать авторов...
Hасколько я понимаю, примерно так поступает Витус и Артем. Hо они
наверное не в виде гвоздей оставляют, а по-красивее ;)
VT> Так что при наличии правильного и красивого кода, палтный суппорт
VT> никуда не упёрся.
Платность сапорта сокращает время реакции. Увеличивает глубину "вникания
в проблему". Как следствие, качество становится "выше среднего".
VT> Ибо или мы патчим сами и отсылаем авторам патч, или просто пинаем
VT> авторов, что бы они это сделали. Саппорт всего лишь может сказать -
VT> "ой, блин. а у нас этого нет и когда будет - неизвестно".
Cапорт (в моем понимании) - это некий буфер, который позволяет авторам не
тонуть в потоке информации. Платный сапорт, это более эфективный буфер, с
меньшими задержками по времени, большей вероятностью попадания, и тд.
Hапример получив первый багрепорт, можно не отвлекать автора на возню с
клиентом, по уточнению проблемы. Это делает сапорт. В случае платности -
он может это делать эфективнее. В случае открытости исходников,
добавляется эфективность взаимодействия со стороны потребителя.
Хотя, разумеется гарантии дает тока страховой полис ;)
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/2541ccfa074d.html, оценка из 5, голосов 10
|