Нипанимаю

[gul_tech]

Когда на винде или на маке падает какое-то приложение, выскакивает окошко с предложением отправить об этом информацию в Майкрософт или, соответственно, в Apple для изучения. Под FreeBSD, если пользователь сталкивается с ошибкой, он может сказать "send-pr" и отправить problem report.

Однако, если я сталкиваюсь с явной проблемой в Cisco/Juniper/Extreme, я должен заплатить за то, чтобы сообщить производителю о проблеме. Даже если у меня на руках отброшенная иосом кора, трапнувшийся джуносовый демон или воспроизводимая бага экстрима. Мне это совершенно непонятно. Ведь это не мне нужно - если у меня что-то не работает, я не буду ждать, пока вендор исправит ошибку и выпустит обновление, это для меня неприемлемо, я найду другой способ решения поставленной задачи, чтобы больше с этой ошибкой не сталкиваться. А после этого могу сообщить вендору об ошибке (чтобы другие пользователи не наступали на те же грабли), а могу не сообщать. Почему вендоры препятствуют тому, чтобы я им сообщал об ошибке? Ведь для этого не обязательно брать на себя гарантии исправления, не обязательно делать багрепорты общедоступными - почему бы просто не дать возможность отправить багрепорт?

Если бы так поступал один вендор, я бы решил, что у него какой-то выверт в мозгах. Но так поступают практически все, а это значит, что чего-то не понимаю я.

Объясните.

Comments

cynical mode on

[furry.livejournal.com]

"Никогда не проверяйте код ошибки, если вы не знаете, что с ней делать"(с) :)
Ну отправил John Doe, админ компании "FooBar Inc", сеть которой состоит из трех каталистов и одного Netscreen'a, bug report. Что с ним (репортом) будут делать вендоры A,B,C и даже J? Если баг критичен для key customer(s) - то оные кастомеры уже (при помощи платного контракта на поддержку) уже открыли case, вынули мозг AM'у и, возможно, услышали в ответ номер версии, в которой все будет исправлено. А если баг для key customer'а не критичен - то на баг можно забить (ну или воспользоваться этим как шансом продать контракт).
И насчет "не буду ждать" - а какие иногда варианты? Иногда именно что приходится ждать, когда исправят, и upgrade'иться.

Re: cynical mode on

[gul-kiev.livejournal.com]

Наверное, это так...
Но всё равно не покидает ощущение, что FreeBSD team больше заинтересована в решении проблем своих пользователей, чем Cisco или Juniper - своих. Обычно ведь принято не только рубить бабло и исповедовать идеологию "заплати, тогда будет о чём с тобой говорить", но и заигрывать с клиентом (даже потенциальным) делать вид, что ты заинтересован в технологии, в качественном результате - и не только в IT, а во всех областях.
А тут явное пренебрежение проблемами клиентов, которые купили железо, но не купили саппорт. Понятно, не купили поддержку - не можете требовать исправления ошибок в ограниченные сроки, тут ведь никто не спорит. Но хотя бы выслушать с понимающим видом или сделать email, куда отправлять problem reports (а там передавать или нет эти репорты в R&D - вопрос отдельный) - это ведь нетрудно, как мне кажется?

Re: cynical mode on

[furry.livejournal.com]

> Но хотя бы выслушать с понимающим видом или сделать email, куда отправлять problem reports (а там передавать или нет эти репорты в R&D - вопрос отдельный) - это ведь нетрудно, как мне кажется?

"Нетрудно" - это, IMHO, не слишком подходящее слово. такая активность стоит вполне определенных денег. Какой-то TACовский инженер должен каждый репорт принять. Посмотреть, достаточно ли информации собрано клиентом. Проверить, воспроизводится ли проблема, не является ли она дубликатом уже известной или вообще "это не баг, это фича" и т.п. и т.д.
Такие компании любят считать деньги.
И насчет "FreeBSD больше заинтересована" - дык это ж сообщество. Там мотивы немного другие. Это все равно что удивляться, почему в квартирах на окнах цветы стоят - а в подъездах кадки с цветами редко, только в избранных домах.

Re: cynical mode on

[sha90w.livejournal.com]

А не будет ли профита от заранее пофикшенных багов на которые еще не наткнулся какой-то кастомер с дорогой поддержкой.
Хотя наверное затраты на фильтрацию багрепортов могут быть больше.

Re: cynical mode on

[gul-kiev.livejournal.com]

Дело не только в том, что баг, на который ещё не наткнулся кастомер с купленной поддержкой, может быть заранее пофикшен. IMHO дело в первую очередь в том, что это могло бы глобально увеличить надёжность (уменьшить кол-во багов) и тем самым привлечь больше клиентов, увеличить продажи. Вендоры фактически отказываются от тысяч тестеров, от обратной связи.
По сравнению с этим затраты на фильтрацию багрепортов кажутся мне пренебрежимо малыми.
Впрочем, чем-то же они думают и как-то деньги считают. Значит, я ошибаюсь...

Re: cynical mode on

[cdplayer.livejournal.com]

По-моему, вы заблуждаетесь, думая что вендор заинтересован в улучшении качества своего продукта. Good enough is enough. Ресурсы ограничены, в т.ч. на фиксенье багов, и фиксится только то, что реально может принести вендору убыток (читай - бага у крупного клиента с многомиллионными заказами).

Re: cynical mode on

[furry.livejournal.com]

Если продукт не падает (работает) у key customers - значит, он достаточно хорош.

Re: cynical mode on

[visir.livejournal.com]

А еще фикся один баг можно добавить два...

Re: cynical mode on

[furry.livejournal.com]

Понимаешь ли, я уверена, что изрядная куча кейсов, открытых как "у вас тут бага" - в итоге оказыается банальным случаем misconfiguration/misunderstanding. С каждым случаем (ну кроме явных крешей) надо разбираться, вопроизводить и т.п. - люди стоят дорого. А раз key customers на это не наткнулись - значит, баг не критичный и на продажи не влияет.

[pro-dz.livejournal.com]

тут наверно дело в сегменте рынка, который занимают компании. Если Мелкософт больше направлена на домашних пользователей (ну во всяком случае, значительная доля), то телекомные вендоры все же не пекутся о домашних абонентах (ЦПЕ что-ли начинать делать?).
и если у первых прибыль получается больше от количества проданных штук, а не от цены одного, то у вторых все как раз наоборот.
и отсюда желание впаривать "smart-net" или "svc-nd" по-дефолту к каждой купленой коробке...

[gul-kiev.livejournal.com]

> если у первых прибыль получается больше от количества проданных штук, а не от цены одного, то у вторых все как раз наоборот.

Что-то я не могу вкурить эту мысль. Мне упорно кажется, что доход в любом случае получается как произведение цены на количество. :)

> отсюда желание впаривать "smart-net" или "svc-nd" по-дефолту к каждой купленой коробке

То есть, это всё-таки целенаправленное угнетение пользователей, не купивших smart-net, а не просто "экономически невыгодно держать инженера, принимающего и сортирующего багрепорты"? Похоже на правду (ведь даже критические обновления безопасности без саппорта недоступны), но почему бы тогда просто не прекратить продажу железа без саппорта? Что заставляет делать то, что не нравится и не приносит желаемого дохода?

[furry.livejournal.com]

>> если у первых прибыль получается больше от количества проданных штук, а не от цены одного, то у вторых все как раз наоборот.

>Что-то я не могу вкурить эту мысль. Мне упорно кажется, что доход в любом случае получается как произведение цены на количество. :)

есть разница между "очень много мелких пользователей, покупающих понемногу" и "не так уж много крупных клиентов, суммы заказов которых измеряются миллионами"

[lonely-scribe.livejournal.com]

Вендор вендору рознь. Техсаппорт дэлинка (по крайней мере российский) без проблем общается на тему багофиксов с любыми посетителями на форме. Хотя это наверное china way - проводить бесплатное бета-тестирование силами кастомеров.

[gul-kiev.livejournal.com]

> 1. средний пользователь juniper без сапорта не живет

Если судить по моему кругу общения, я бы так не сказал.

И я спрашивал у представителя Juniper, что делать пользователю без саппорта, который столкнулся с багой в JunOs. Ответ: ничего не делать. В смысле, покупать саппорт или самостоятельно искать workaround. Анонимные багрепорты (на форуме или где ещё), скорее всего, рассмотрены не будут.

Я, конечно, понимаю, что нужно отделять решение проблемы пользователя (предоставление ему версии JunOS с исправленной ошибкой или поиск workaround для его ситуации) от устранения проблемы в JunOS (когда-нибудь в одной из будущих версий). Саппорт предполагает первое. И если найден воркэраунд, пользователь удовлетворён и кейс можно закрывать. Я же говорю о втором, о том, что разработчик софта, как мне кажется, должен быть заинтересован в исправлении багов.

> 2. наличие собственно коры далеко не всегда позволяет понять причины их возниктовения

Разумеется. И, если нет саппорта, никто и не будет требовать понять причины и устранить их. Но нередки ситуации, когда проблема легко воспроизводится. Даже если таких случаев меньше половины (хотя я думаю, что больше) - разве это значит, что никакие коры неинтересны?

> 3. очевидно что сбор кор для массовых сегментов гораздо больше дает информации чем не для массовых

Не вполне очевидно, хотя, вполне возможно, что и так.
Но из этого ведь не следует, что сбор кор для немассового сегмента неэффективен. Особенно, если в дамп включить конфиг, лог, последние выполненные команды и другую полезную информацию.