Как стать автором
Обновить

Комментарии 74

Абсолютно здравая позиция. Выглядит как хороший вариант OS.

+1. Не ломает систему (всё ещё можно в любой момент сделать форк), но разделяет собственно работу (за которую хорошо бы человеку заплатить) и право пользоваться результатами его труда.

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

Ну, это хорошая причина для форка.

Upd: а ещё такие баги создадут неудобства и тем, кто уже заплатил – т.е. багрепорты будут всё равно. Так что маловероятно.

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

Если тот форк будет фиксить баги за тебя, - так это же хорошо - для этого в оупенсорс и выкладывают. :)

ТО есть ты потратил усилия, внём баги в ПО, ничего с этого не получил, и еще народ уполз пользоваться не твоей веткой, а веткой другого чувака.

Не вижу профита, одни потери.

Верно. Не очень понял, что вы отвечаете на коммент чела который предлагат вносить баги, что бы потом их править. :)

Форков может быть много. Автор оригинала может делать pull'ы из них.

Смотрите, это как, не знаю, условным Попкорн Тайм. Есть популярный, официальный(ТМ) источник и двадцать форков, особенно, если оригинальный не выглядит заброшенным - есть недавние коммиты, обновлялась релизная версия и т.п.. Куда вы пойдёте?

Собственно в этом вся суть пулл реквестов. Ты форкаешь, делаешь фикс, и просишь изначального автора принять его. Он собирает всё воедино.

Так автор и не против патчей, он готов их принимать. Автор против того, чтобы эти патчи писать (бесплатно) самому.

Про это практически в самом начале статьи. В принципе, разумное зерно в мнении автора по этому вопросу определенно есть:

Такая бизнес-модель окажется убыточной (особенно с учётом времени на разработку хорошего бага, за удаление которого заплатит кто-то один)

Прямо в статье написано почему это - плохая бизнес-модель

Во-первых, хороший баг тоже нужно ПИСАТЬ и это едва ли не сложнее, чем его править

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

А так - честная позиция "вам подарили продукт, пользуйтесь, а если надо что-то еще, даже исправление реального бага, но который МНЕ и моим ПЛАТНЫМ пользователям, видимо не мешает - велкам, платите"

На мой взгляд, это честнее, чем "купите платный софт /железку, к ним - платную поддержку, а теперь извините - ваш баг попадает в категорию will-not-fix, потому что он возник всего у десятка пользователей по всему миру и в попытках быстро его подчинить ломается более важный функционал"

Про will-not-fix вам расскажут шёпотом и на ушко, и то, если у вас очень хорошие отношения с локальным менеджером, а так -"ждите патча"

Мне нравится модель GitLab, когда багрепорты принимают у бесплатных пользователей и баги либо исправляют, либо дают workaround. А вот новые фичи аккаунт-менеджеры обосновывают ссылками на CRM с реальным выхлопом в деньгах.

С классическим OSS сложнее, но проигнорированный критический баг у бесплатного пользователя может потом выстрелить у платного и в этом случае проиграют все.

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

Кому же вы тогда нужны? Люди перейдут на аналоги. Я не понимаю автора

Это обычно называется работой. И, как ни удивительно, за работу люди обычно получают деньги.

Пусть лучше идёт вагоны грузит.

Так может его УСТРАИВАЕТ, что люди перейдут на аналоги?

Нет, ну реально, ему то какая разница? Он решил СВОЮ проблему и все.

Кому же вы тогда нужны?

Он поделился программой, а будите ли вы ею пользоваться, ему все равно, ведь денег с вас ноль.

Люди перейдут на аналоги.

Попадает под пункт выше.

Я не понимаю автора

Скорее всего вы не пробовали помочь тому, который сам не хочет ничего делать.

Принять баг репорт в систему это одно, это ничего не стоит. Более того, другие пользователи или разработчики иногда могут помочь найти решение или воркэраунд.

А вот рассмотреть баг, проверить, разобраться и исправить - другое, это работа.

типа каждый открытый баг имеет свой счёт для доната/оплаты? в принципе для бага, который мешает большому количеству пользователей, можно скинуться толпой. и когда сумма «на счету» бага будет достаточной или перевалит минимальную ставку то разработчик возмётся чинить. можно ещё приоритет сделать, баги с бОльшим балансом чинятся раньше.

Вы только что придумали Bountysource

можно ещё приоритет сделать, баги с бОльшим балансом чинятся раньше.

  1. Убираем верхний порог цены бага

  2. Говорим о том, что будем чинить самый дорогой

  3. Не чиним баги а просто копим деньги на счетах, чтобы баги "дорожали".

Схема для разработчика, безусловно, приятная).

Но деньги не обналичишь, пока баг не починишь.

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

Если только сделать систему, что автору проекта тикеты в принципе не видны, пока туда не поступит денег хотя бы на час работы, чтобы произвести первоначальный разбор тикета. А иначе на практике все равно заметное количество времени будет на это уходить, как ни крути.

Может для одного человека это и имеет смысл, но в компаниях обычно принимают все баг-репорты, а далее разделяют их на Free/Paid support. Соответсвенно в первую очередь фиксятся Paid support, а Free support фиксятся либо прицепом к Paid support, либо просто копятся. Опять же если по одному и тому же фришному тикету очень много запросов – начинаешь уже смотреть на него внимательней.

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

НЛО прилетело и опубликовало эту надпись здесь

Для Free Support ничего этого и не нужно как раз таки по причине трудоемкости. Вы не обязаны следить ни за дубликатами, ни за актуальностью. Ваш лучший друг - сортировка по дате последнего обновления задач в которой видна дата создания задачи. Там очень хорошо видны те задачи которые очень долго не теряют своей актуальности и могут быть включены в план развития продукта.

PS: Если сильно чешутся руки, то по фильтру можно удалить те задачи по которым несколько лет ничего не происходит, но, опять же, вам за это не платят, поэтому проще оставить как есть.

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

Я к баг репортам всегда пулл реквест прикладывал. Половина отправилось на свалку, но я решал свою проблему и мне не жалко.

По-моему, стоит логически отделить сам баг-репорт от процесса анализа и исправления бага. Когда я пишу баг-репорт, я не ожидаю, что разработчик бросится срочно его исправлять; моя основная цель — просто проинформировать разработчика о том, что баг вообще есть. А если разработчик запирает себя в информационном пузыре, то, кажется, вряд ли это хорошо


А за сообщение об уязвимости тоже надо заплатить? А то у других обычно наоборот — платят большие деньги тому, кто сообщил об уязвимости :)

По-моему, стоит логически отделить сам баг-репорт от процесса анализа и исправления бага.

Возможно в данном случае подразумевается что если репорт был значит будет и фикс обязательно. Тогда все звучит логично.

Абсолютно не согласен с автором. Половина его аргументов опираются на какие-то субъективные понятия о справедливости и честности, тем не менее как он сам замечает — для кучи людей это не справедливость, а засранство.


Как только вы размещаете кнопку «Пожертвование», вы начинаете бизнес, который автоматически создаёт накладные расходы.

А когда он берет деньги за саппорт это...?


Почему? Если я буду читать такие сообщения, то возникнет соблазн оказать кому-то бесплатную услугу. Это несправедливо по отношению к тем, кто платил за моё время.

Это странно. Типа я плачу х рублей за исправление бага №1 и буду недоволен, что автор потом в свободное время исправил баг №2? Бред




По мне — так не стоит ограничивать интерес люедй к твоему продукту. Это не требует нагрузки, но позволяет сделать комьюнити и наладить диалог с пользователями. Искусственно пресекать любые попытки людей тебе помочь прикрываясь какими-то высокими материями это глупо и аморально.


У меня, например, есть опен-сорс проект с 6000+ пользователей (за всё время), в гитхабе лежит 100 ишьюсов, но я их не чиню — и пользователи реагируют нормально. Они мне: "заметили баг такой-то", я им "спасибо, чинить не буду". Всё, никаких претензий друг к другу, мир, дружба, жевачка. Они теперь даже двойные баг-репорты отменяют, говоря что такой баг уже заведен. Или просто когда человек не разобрался, но хочет создать репорт — его отговаривают, указывая что это корректное поведение. За последние полгода я потратил на проект минут 30 времени от силы.


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

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

А, дескать "Хочу чтобы баги в программе чинил только я, а вы мне за это платили."? Ну тогда да, пожалуйста.


Всё равно считаю что это неэффективно с т.з. продукта, но тут его право.

субъективные понятия о справедливости и честности

а есть объективные понятия о справедливости и честности? ну, кроме УК и прочих кодексов.

Если почитать комментарии к этому посту, то есть ряд людей, которые согласны с автором, а значит их "понятия о справедливости и честности" в этом вопросе совпадают с автором и не совпадают с Вашим (то есть автор такой не один). На мой взгляд автор никому ничего не должен, пока ему не заплатили - это логично. Кому не нравится, тот пусть ищет альтернативу

Вы триггернулись на фразу, не дочитав комментарий?


а есть объективные понятия о справедливости и честности? ну, кроме УК и прочих кодексов.

Нет. Именно поэтому аргументы автора "Это несправедливо по отношению к тем, кто платил за моё время." несостоятельны.


Я, полностью признаю право автора делать с продуктом всё, что ему вздумается, пусть хоть требует облизывать ему ботинки за поддержку, но замечаю, что вместо честного "я самодур и творю дичь по своему праву", он старается аппелировать к справедливости и какой-то логичности/эффективности — и вот с этим я не согласен

По этому вопросу на Хабре была шикарная ветка комментариев, где пользователь пытался отстаивать позицию «разработчики свободного ПО обязаны». Там ему популярно объяснили, что в таком случае многие из них вообще не стали бы делать софт публичным.

А зачем делают тогда софт публичным (опенсорсным)? Чтобы что? Просто снять с себя ответственность? Или же наоборот, добавить себе ответственности за своё детище?

Я когда выкладываю свой софт, я как раз и надеюсь, что мне помогут сделать его лучше, и им будут пользоваться больше людей, скажут спасибо, а не "Иди нахрен, жмот".

Чтобы что?
Например, чтобы дать другим возможность не писать код с нуля. Если софт работает у меня, но не работает у пользователя (или ему не хватает какой-то фичи), у него появляется возможность доработать софт (или нанять кого-то для этой работы). Которой у него бы не было, если бы я не опубликовал код.

Чтобы что?

Как вариант, чтобы оно «само поправилось». Снижение собственных трудозатратат в части, выхлоп от которой представляется сомнительным (например, по причине «мне сойдёт и так», или другим каким). Анализ причин возникновения ошибки силами добровольцев, если это в самом деле кому-то надо. Вплоть до предложения решения. Мерж реквест там, всё такое... Чтобы подключить коллективное сознание на всех этапах улучшения: «критикуешь — предлагай» и т.п. вместо «сунул, вынул, высказал конструктивную критику, убежал».

Кстати, это всё называется «Open source», а не «Free support». Мне почему-то кажется, это не случайно. Заметьте, что для бесплатного использования или даже бесплатной техподдержки (если вам вдруг хочется этим заниматься) открывать исходники совсем НЕ обязательно. Так что давайте ещё раз зададим себе тот же самый вопрос: открывать исходники (делать софт именно опенсорсным, а не всего лишь бесплатным) — чтобы что?

Чтобы что?

Because I can. Вы что, хотите запретить просто так взять и выложить код в паблик?

Многое здраво звучит, но:

У автора нет смысла делать софт Лучше самостоятельно, для себя и комьюнити, заплатят - сделаю. "Лучше" - это про ввод новых фич, добавление удобства для старых. Это говорит о том, что автор либо уже не пользуется своим софтом, либо пользуется сильно меньше по сравнению с временем, когда софт разрабатывался. А когда автор перестаёт юзать софт, который пишет, это приводит к очень печальным последствиям.

Если же платны только багрепорты, то звучит здраво.

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

У описанной идеи "платного багтрекера" есть свои минусы. Теряется "прозрачность", теряется "сообщество" и, что хуже всего, решаться так могут только мелкие баги.

Мне удивительно, что фактически нет "гибридного" формата с открытым баг-трекером и "голосованием деньгами за исправление". Лично мне во многих случаях не лень было бы, найдя тикет, описывающий мешающий мне баг (или отсутствующую фичу), закинуть условные ~5USD на "краудсорсинговый контракт" на исправление этого конкретного бага (который может прилагаться к тикету).

  • Юзеру это лучше чем просто донат, потому что он понимает за что платит (деньги не переходят разработчику до выполнения контракта)

  • Разработчику это лучше чем просто донат, потому что юзер более мотивирован заплатить. И потому что видно, за что собственно юзеры готовы платить, а что блажь.

  • Платформе (github например) это даёт возможность брать комиссию.

    • Можно реализовать арбитраж, в духе типа ebay (да, тут могут быть сложости и классические проблемы с "написанием ТЗ" и соответствием результата ожиданиям, но мне не кажется что они заведомо нерешаемы)

    • Можно реализовать "биржу фрилансеров"

  • Себестоимость исправления большинства багов выше 5USD, но если множество пользователей проголосует своими деньгами, сумма может стать вполне существенной (и возможно достигнет значения, заранее назначенного разработчиком).

  • Снимаются назойливые вопросы "а почему не реализовано вот это"?

  • Подходит даже для очень крупных проектов. Можно даже Windows и/или Linux развивать по такой схеме. А "юзером" может быть не только физ.лицо.

Тем не менее подход автора оправдан — он же не скрывает свою политику, можно не пользоваться, если не нравится

В такой схеме есть вопрос когда снимать деньги.

Логично что-ли произвести перевод только когда баг починен.

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

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

Так что в итоге ну соберет ваш баг пять баксов донатов. Для опытного разработчика эти пять баксов - это десять минут времени по рыночной оплате, за это время только и можно что описание бага прочитать. В итоге материальной заинтересованности у разработчика все равно не будет, зато появятся рычаги для морального давления у пользователя: "ну я ж тебе денег заплатил, чини давай". Что в общем мне, как разработчику, нафиг не нужно (за такие копейки).

я ж тебе денег заплатил, чини давай

Наоборот же... Если деньги не переходят разработчику до выполнения контракта, то можно их и не снимать с его карты/баланса, т.е. пользователь ничего ещё не заплатил и никакого "рычага" у него нет. А вот при обычной "платной техподдержке" ситуация "я тебе 5$ заплатил, чини давай" возникает почти каждый раз (для реальных багов) - пользователь что-то заплатил, а проблема не решена, только отписку какую-то получил шаблонную.

Думаю такого нет, потому что оно не сработает. Люди реально редко донатят

"Голосованием деньгами за исправление" это уже не совсем донат. Люди довольно часто платят за разные услуги, которые облегчают им жизнь. За какое-то платное приложение, которое чуть удобнее чем бесплатное, например. И это уже ближе. Особенно если представить себе на секунду, что добавление такой "кнопки" к своему github репозиторию ничего не стоит и схема всем стала привычна насколько же, насколько платные приложения в google play (которые, конечно, тоже не всегда окупаются, но в целом схема известная и рабочая).

Обычно рядом с этим есть ещё полиси "но если вы пришлёте MR, мы его рассмотрим". scratch your own itch. Нашёл баг? Написал патч? Присылай.

На анализ MR тоже время нужно.

Безусловно. Но если "разбирать жалобы клиентов - это моё время", то MR в себе уже содержит большую часть работы. Человек обнаружил проблему, бисектнул её, нашёл первопричину, нашёл решение, предложил решение. Рассмотрение MR'ов - часть этики opensource.

Если с позицией "я ваши баги читать буду только за деньги" согласиться можно, то позиция "я ваши MR'ы буду мержить только за деньги" уже является анти-общественной, потому что указанное ПО заняло чужое время, чужое внимание и информационное поле, но сопротивляется улучшению; даже если автор MR'а сделает форк с исправлением, то ему придётся конкурировать с оригинальным ПО и никакой пользы от этого не будет.

Ооо нет) принимать PRы это очень сложно (я как обладатель большого набора популярных проектов говорю).

Иногда проще самому поправит фюбаг, чем пулл реквест вмерджить.

Да. Но, "поправить самому" по багрепорту с фиксом легче, чем по багрепорту. Потому что а) человек в коде показал что он хочет, вместо размахивания руками и рассказов "чтобы всё хорошо было" б) есть какое-то (хоть и неправильное с архитектурной точки зрения) решение в) человек, который написал фикс, вольно-невольно будет использовать хотя бы примерно правильную терминологию в описании проблемы.

Непонятно, почему автор проводит разделение между багрепортами с патчем и багрепортами без патча. На патч тоже нужно смотреть и изучать, редко он применяется в оригинальном виде. И патч тоже может быть фичой, нужной пользователю, замаскированной под исправление бага.
Ну и вообще - чтение любых сообщений от некоммерческих пользователей можно убрать, всё в спам, это ведь отнимает время. Хочешь, чтобы твоё сообщение прочитал разработчик - заплати. Разве это не логично?
Да и зачем он писал документацию? Ему самому она не нужна, а время тратится. Исключительно для коммерческих пользователей?
Наверное, только вот мне кажется, что opensource - не про это.
Такая позиция скорее напоминает trial, несмотря на доступность исходников.

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

В целом согласен с автором. Во всех лицензиях английским по белому прописано “as is with no warranties”. Так что технически и юридически имеет право. Хочешь “warranties” - так вот, кастомная лицензия для платных пользователей, может даже SLA там же (не знаю что у автора, но многие так и делают).

Позиция цельная и имеющая место быть.
Пытается решить важный вопрос: как монетизировать OpenSource (а шире - как спасти OpenSource в ситуации, когда "почти все простые программы уже написаны, а чтобы писать комплексные программы нужны ресурсы").

Однако с точки зрения развития OpenSourse-проектов такая модель создаёт плохие стимулы:
- а) нет стимула повышать качество ПО.
- б) непонятно, как эту модель (платная поддержка и устранение багов) можно масштабировать на бОльшее число разработчиков - то есть монетизировать крупные проекты по такой системе вряд ли получится.

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

Ну и
Увеличить затраты на инфраструктуру, которая подорвёт мои доходы? Звучит как план. НЕТ! Парень, высунь голову из темноты своих идиллических иллюзий.
(...)
Когда у людей возникает проблема, они хотят с кем-то поговорить и чтобы проблему своевременно решили. Они не хотят регистрироваться на форумах и неделями следить за ответами в надежде, что какой-нибудь член сообщества в конце концов найдёт ответ.

… и прочие подобные попытки усидеть на двух стульях. Парень, ты уж определись, тебе пики точены или вторая альтернатива. Пользователь не хочет регистрироваться на форумах или ты не хочешь подрывать свои доходы.

Давеча собирал пакет для AUR и чинил сломанную систему сборки. Отправил автору pull-реквест. Сколько с меня? Может быть купить годовую подписку, "pay as you fix"?

Очень хорошо понимаю автора.

У меня как-то на работе был случай: написал я один функционал, выкатил, и на меня посыпались багрепорты. Причём разобрать такой багрепорт - это минут 10 вдумчивого чтения xml-ки с исходными данными для поиска ошибки там, а иногда и приходилось разворачивать симуляцию, т.к. даже я сам ошибку найти не мог. В результате из штук 50 багрепортов по этому функционалу багом оказались... ноль. По всем остальным я написал объяснение, почему поведение именно такое со ссылками на ТЗ и данные. Естественно, счастья мне это ни разу не прибавило, я потратил хренову тучу времени на совершенно неприятную и бесполезную работу.

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

У Microsoft заявлена такая модель в поддержке по инцидентам, но в какой-то момент саму поддержку отдали на аутсорс с нулевой квалификацией и приоритет у багов ниже плинтуса. Для продуктовой команды проблемы не существует, пока о ней не заявил клиент из Fortune 500 с контрактом на несколько миллионов долларов.

Я тут недавно столкнулся с немного другой ситуацией.
Есть известная IT-Компания, называть не буду. Масса продуктов. На примере одного из продуктов. Продукт платный, причем, ранее — пару лет назад как купленный. Лицензия была такова, что все обновления далее бесплатны, а вот поддержка и исправление багов в нашем случае 6 месяцев, которые уже прошли давно. Но вот с этого года — все продукты переводят на подписку, теперь хочешь обновления — плати, покупай подписку, каждый год.
Ну ладно, фирма покупает подписку, продукт нужен. При этом суппорт на все время действия подписки.
Ок, тут выявляем баг. Отправляю. Ответ: баг не в нашем продукте, а в вашем рабочем окружении. Ни у кого больше таких проблем нет, если хотите, мы для вас исправим, но за такие то деньги. Стоп, говорю, проблема не в нашем окружении, а в корректной работе вашего продукта в нашем окружении. Все равно, отвечает суппорт, бесплатно идите на…
Честно говоря, стало очень неприятно, но коллеги предложили такой комромиссный вариант: не нужно срочно закрывать баг, сделайте плановое обновление к следующему релизу.
Но нет. Предложение отклонено.
Ну что ж. В результате наша фирма будет уходить к следующему году на альтернативные решения, по всем продуктам данной компании. Всего фирма заплатила более 3500 Евро, с учетом подписки на текущий год.
Так что вот бывает и такое отношение.
Собственно, ситуации с описанной статьей немного разные, общее есть наверное только одно: репутация — ничто, бабки — все.

Имеете право.

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

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

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

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

Я:		Отлично! Для этого откройте тикет, пожалуйста.
Юзер:	Но тикеты вроде входят в платный пакет?
Я:		И?

Достаточно наглядно

Не общайтесь в стиле "ну и чё ты докопался" - и о чудо, претензий будет кратно меньше

в стиле "ну и чё ты докопался"

С засранцами приходится общаться на их языке.

Вот только инициатор такого общения - вы а не они, цитату я привел как пример выше

Человек пришел и начал общение вежливо, ему можно вежливо отказать

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

Более того, можно было сразу объяснить что "поддержка данного софта - платная". Redhat так делает уже очень давно и нормально зарабатывает на "бесплатном линуксе".

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

Вот уж не думал, что фраза - это не баг, это фича - обретёт такой смысл.

Хорошая идея, для стартапа, делаем приложение, периодически добавляем в него баги, собираем с людей деньги за багрепорты, а в следующем обновлении, убираем эти баги и добавляем новые. Каждый багрепорт отдельно оплачивать нужно будет.

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

Вы упускаете основополагающую деталь — автор делает программу для себя, а не для других.

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

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

Но в общем да, всё равно это выглядит как справедливый противовес растущему числу потребителей, пришедших к F/OSS и считающих что он *для них лично*.

Лучше поставьте кнопку для донатов!

Отличная идея! Как часто вы нажимаете такие кнопки?

я регулярно нажимаю, и на мою нажимают, хотя сильно реже

мне кажется проблема в том что эти кнопки многие просто игнорируют, а ведь это отличный способ помочь проекту

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

Автору хочу пожелать успехов, статье плюс и плюс карме, но, чисто по человечески - не всё в этом мире продается за деньги...

Я изучал проблему и почти всегда оказывалось, что ничего не сломано, просто всё работает не так, как ожидалось (чего, собственно, и следует ожидать от любого достаточно сложного программного обеспечения)

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий