Comments 150
Вы вообще прикольные и очень нескромные. Обычно требуют повесить плашку на главной странице (aka README.md) об использовании такого-то продукта на безвозмездной основе. А вам вставку рекламы во все исходники подавай. Потому и "пока на GitHub не так много людей, использующих PVS-Studio".
Конечно, мы не можем знать, быть может деньги это как-то привлекает, через такую вот рекламу. Пока всё это выглядит крайне «высокомерно» со стороны создателей, вроде, нужного/правильного софта.
У разных компаний разный подход. Кто-то просит их упоминать в индивидуальном порядке (в блогах/твиттере), кто-то хочет плашку (что может быть уже неприемлемо для некоторых организаций курирующих open source проекты типа ASF, Eclipse).
PVS-Studio вот хочет комментарий до информации о лицензии (в первых двух строках), да и ещё с довольно странным текстом. Ну и условия использования таковы, что для большинства не-хобби open source проектов это будет blocker'ом.
Т.е пихать в каждый файл малополезный, даже более того, засоряющий, текст лицензии вы готовы (и почему не устраивает отдельный файл с лицензией в репозитории?), а полезный маркер — нет? А не объясните, чем так мегаполезны эти 20-30 строк в каждом файле, что за них удавиться готовы (а ведь их еще каждый год обновлять нужно, ведь как же так, а вдруг новый год, а у нас лицензия на него не распространяется? А вдруг украдут?!!)?
Т.е пихать в каждый файл малополезный, даже более того, засоряющий, текст лицензии вы готовы (и почему не устраивает отдельный файл с лицензией в репозитории?)
На разные файлы может быть разная лицензия, у них могут разные авторы и истории. И явное указание лицензии в файле (причем в случае, скажем, Apache License v2.0 и GPLv3 там только ссылка на лицензию) позволяет другим проектам делать производную работу не по всему проекту, а по его подмножеству.
а ведь их еще каждый год обновлять нужно, ведь как же так, а вдруг новый год, а у нас лицензия на него не распространяется
Там указывается inception year, а не current year. И это год (или диапазон) от которого считается срок действия имущественным прав на код. Как минимум, в US это так. Disclaimer: IANAL.
На разные файлы может быть разная лицензия,
Это как-то мешает указать "См. текст лицензии в файле LICENSE.mit" или "LICENSE.lgpl" и т.п.? Зачем весь текст именно в каждый файл писать?
Там указывается inception year, а не current year.
Неважно, что год значит, его же обновляют каждый год, по всем файлам проекта, если текст лицензии в каждом файле. (Кстати, если это только начало, то зачем там диапазон? Заканчиваться тоже диапазоном будет, типа, какой год ближе по душе, тот и считаю концом действия лицензии?)
Это как-то мешает указать "См. текст лицензии в файле LICENSE.mit" или "LICENSE.lgpl" и т.п.? Зачем весь текст именно в каждый файл писать?
Примерно это там и указывается во всех нормальных лицензиях. Совсем мелкие (2/3-clause BSD, MIT, ISC и тому подобные) здесь скорее исключение.
Это как-то мешает указать "См. текст лицензии в файле LICENSE.mit" или "LICENSE.lgpl" и т.п.? Зачем весь текст именно в каждый файл писать?
Вы вообще читали, что я написал? От указанного диапазона отсчитываются 70/90/120 лет на которые распространяется copyright. Многие там указывают только один год (когда код написан), этого вполне достаточно. Изменять после этого его не нужно, это не год последней модификации. Если были существенные изменения, то могут указывать диапазон, в котором начало не меняется (год когда код написан), а конец соответствует текущему году, когда эта тяжелая модификация была сделана.
Объясняю. Для получения какой-то пользы от статического анализатора, его надо гонять чуть ли не на каждый билд на CI-сервере. Соотвветственно, эти комментарии в коде необходимо держать на постоянной основе. Выдавать им индексируемую гуглом рекламу в 2300 исходных файлов на проекте на гитхабе с 190 форками и 2000 звёздочек я лично не собираюсь, это превышает пользу, которую проект может потенциально извлечь из их чудо-анализатора. Соответственно, когда будет стоять выбор "какой анализатор использовать", я выберу их конкурента, которому достаточно плашки.
Поймите, я не жалуюсь и не требую чего-то от авторов. Я объясняю причины, по которым не буду использовать их продукт по этой "бесплатной" программе.
Как-то вот так.
К чему это я?, а к тому, чтобы понять вы пишете предметно или о «своей» теории.
У меня есть проект которым пользуются люди и который я развиваю, продвигаю проект написанием статей и прочим. Конкретно ко мне приходили в почту люди от указанной выше фирмы и предлагали вставить комментарии в каждый файл в проекте, в 200+ файлов. Грубо говоря, посланы они были вежливо ровно так же как описывает kekekeks
Выгода от вставки этих комментариев не покрывает нанесенный ущерб репутации проекта, дискредитации проекта.
Иначе говоря, ребята сильно переоценили свою значимость. После переписки с указанной выше компанией я пошел поглядеть кто есть на этом рынке ещё. В итоге, повесил себе плашку Coverity и успешно проверяю проект. И я не один такой, после вот такого «пиара» знаю людей которые сделали то же самое. То есть, они ничего не использовали для анализа кода, но вот почему-то взяли и ушли к конкурентам.
Более того, много, как по мне, вменяемых людей имеющие большие открытые проекты описывали чем плох данный подход с комментариями, но разработчики софтины не прислушались к ним, и даже напротив начали противодействовать им. При этом размещая ссылки на комментарии каких-то студентов которые первый раз написали 20 строк кода и которые мега-благодарны создателям инструмента.
Вот и получается, что софт вроде хороший, но создатели его в лоб не хотят слушать и видеть своих пользователей. Именно это и расстраивает, делают хороший софт, но по всем показателям скатываются куда-то, делают себе антирекламу. При этом всё, антирекламу они делают себе упорно, я бы сказал, что словно целью задались такой.
Скажу за свой проект. Подобные просьбы вставок в каждый файл рекламы в проект который позиционирует себя как серьезный проект недопустимы, проект, который позиционирует себя как встраиваемое решение с прозрачным намеком на то, что разработчики проекта знают и понимаю, что делают, а тут батц и просьба:
«Пожалуйста, проверьте мой проект, а то мы тут как-то разобраться не можем...»
При этом, комментарий настолько дебильный и рекламный, именно дебильный и рекламный, что не в какие ворота не лезит. Более нагло было бы написать ещё: Теперь проект принадлежит компании… Выглядит это как вмешательство в проект.
Я не уверен, но если бы это была последняя строчка комментария в файле, вроде:
/* Checked with PVS Studio (link) */, но и то, и то разместить такое не каждый сможет.
Когда весит плашка, где-то в реадми то люди с гордостью говорят: а этот проект проверяется Х софтиной, отлично. Но PVS Studio не имеет такого «авторитета», как скажем, Coverity.
Простите, написал бы более развернуто, но вынужден откланяться, выходные.
Во-первых, я пишу лично от себя, как я это вижу имея какой-то проект. Не в теории.
Меня кажется, вы не понимаете, что опенсорс денег выедает не мало, это такой же бизнес, там свои законы и свои методы заработка. Я не перехожу на личности и не пытаюсь оценивать вас или кого либо из разработчиков. Я высказываю почему это плохо для меня, более того и для многих разработчиков которых я знаю, но тут я могу писать только за себя.
Тут не действует метод «назло бабушке уши отморожу», тут конкретно речь о том что создатели хотят пиарится за счёт открытых проектов. Создателям софта говорят, что мы тоже тратим деньги/время и их просьба должна быть соизмерима. Но вы и прочие уверены, что если опенсорс, то там все бесплатно и вообще, должны ещё спасибо вам говорить. Нет, мир там немного сложнее.
Не считая того, что их предложение не для open-source, а для некоммерческих проектов. Т.е. Linux, Apache HTTP server, nginx, openssl, xorg, libreoffice и безумное количество других не подходят под из предложение (даже не из-за положения или текста комментария, а т.к. они не являются некоммерческими). А в их проверке есть польза всем.
Ещё раз, я не теоретик, я практик. Даю обратку ребятам разрабатывающим нужный/правильный софт. Они мне сами написали, не я к ним лез. Я рассказал почему оно не для меня. Если им интересно только положительное мнение то что же, но вот реальный проект который хотел бы использовать их продукт, но условия дикие. Вы, теории можете разводить тут сколько вам угодно, я же пишу предметно.
Ну так не пишите, никто же не заставляет. Захотите воспользоваться без написания этих строчек — купите лицензию. Тем более, если он так вам помогает, что прям никуда без него.
То есть, они ничего не использовали для анализа кода, но вот почему-то взяли и ушли к конкурентам.
Т.е. ЧСВ настолько хлещет через край, что будь PVS-Studio даже в несколько раз лучше конкурентов, использовать мы ее не будет, лишь бы не дай баг не дать кому-то рекламу бесплатно (более того, вы серьезно думаете, что подобная реклама хоть на кого-то повлияет в выборе анализатора для проекта на сотни тысяч строк? Или все же на качество анализа смотреть будут?).
Оо-ок. Пожалуй, а буду обходить ваши проекты стороной — кто знает, что чего там еще удумают, прикрываясь "открытым" и "свободным" кодом, вдруг им шашечки важнее.
Понимаете, с одной стороны коммерческая компания, которая продает свой продукт и по собственному желанию разрешает использовать его всем бесплатно. С другой стороны — проект, в который по определению силы вкладывают добровольно и даже если это делает коммерческая компания, никто ее под дулом пистолета не заставляет этого делать.
Нежелание в первом случае раскрывать свое ноу-хау и/или многолетный опыт вполне понятно.
Нежелание во втором улучшать общий код из-за кому-то из манагеров показавшимся унизительными пары строчек как раз и говорит о крайне раздутом ЧСВ. Прям так и слышится "Вы никто, а мы (та-дам!!!) open source(!!!) проект, целуйте нас в попу)". В конце концов, если вам это не надо, то проходите мимо, незачем испражняться по пути.
1) Ну так ведь и проходили мимо, пока "какие-то манагеры" из сабжевой компании не начали плакаться что "ой, мало юзеров используют".
На что был дан ответ почему именно мало используют.
На этот ответ вы пишете "не нравится — проходите мимо".
Ну так и проходим ведь.
Но ведь плачутся что мало юзеров :)
2) не знаю как остальные "нытики", а вот если бы была плашка вместо комментария такой унизительной формулировки, да ещё и до лицензии, я бы вполне добавил. Проверять ещё одним дополнительным анализатором лишним не будет. Если он не требует запредельного :)
А если требует, то да, даже если бы (если бы!) он был на голову выше конкурентов, я бы тридцать раз подумал стоит ли такой текст комментария в каждом файле проекта этой вот разницы с конкурентами, или я лучше сам навелосипежу аналог, зато буду ментально здоров.
3)
раскрывать ноу-хау
многолетний опыт
а) и в чём же, интересно, может быть ноу-хау в статическом анализе? В умении читать стандарт и писать правильные регэкспы (в пункте "б" напишу почему регэкспы)?
б) Есть у меня один знакомый (он даже на хабре есть, и иногда заходит в треды сабжевой компании. И сабжевая компания ему даже предлагала год (или типа того) лицензии на свой продукт за обещание (!) написать положительный (!) отзыв. В общем, если захочет — сам придёт и расскажет всё).
Так вот, этот вот знакомый пишет свой проект используя кучу заворотов из самых новых стандартов С++, да и вообще его код читать "простому сишнику" довольно тяжело.
И вот он как-то ещё несколько лет назад (ну, тогда это не С++17 был, конечно, а тогдашний свежевышедший стандарт) натравливал триальную версию сабжевого продукта на свой проект...
И, судя по выхлопу, было очень похоже на то, что сабж тупо проверяет по списку регэкспов. И если регэксп сфейлился — выдаёт какашку. В то время, как ни компилятор не возмущается (да-да, в них тоже есть анализ некоторых из вещей, на которые может ругаться сабж, и эти какшки были как раз из таких), ни статический анализатор в том же "шланге", ничего. А сабж — да. Потому что не интерпретировал, а парсил.
Так что повторю вопрос ещё раз? Многолетний опыт написания регэкспов? Так он и у меня немаленький! Правильный регэксп = ноу-хау? Тогда знаете сколько их у меня? Может мне тоже начать продавать их?
// с такой же "офигенной" политикой лицензирования, как у сабжевой компании, ага :)
про регэкспы в этих буквах написано довольно мало.
И, не смотря на то, что про используемые технологии "уже столько раз писали":
0) а разве "столько букв" (информативное расписывание каждого пункта со всеми доводами) — это недостаток?
1) на заборе тоже можно написать, а без возможности посмотреть за этот забор приходится только верить автору надписи на слово.
2) про неправильность подхода лицензирования (в качестве одного из обоснований того, почему же так сабж практически никому из потенциальных клиентов не интересен), и про то, что до исправления этого подхода ныть о том какие все кругом неблагодарные бессмысленно, "тоже писали уже столько раз". Но ничего не меняется.
Ну и между строк, в конце концов, в том коментарии можно было прочитать что "я понимаю, что регэкспы там не используются, но по качеству работы пару лет назад возникало именно такое ощущение". А если ещё и почитать комментарий в этой же подветке перед вашим, то вообще все вопросы отпадут. Наверное.
почему же так сабж практически никому из потенциальных клиентов не интересен
Сабж, как многие статьи в последнее время, про популяризацию статического анализа, а не поиск потенциальных клиентов.
По разработке ПО вообще много книг и методик. Они совсем не о том, «как писать на C++ и что появилось в C++17», поэтому не всегда интересны рядовому программисту, а зря.
— А это правда, что Иван Иванович выиграл машину в лотерею? — Правда. Только не машину, а тысячу рублей. И не в лотерею, а в преферанс, и не выиграл, а проиграл…
1. Мы не раз писали, что на регэкспах невозможно выполнять хоть сколько-то серьезный статический анализ кода. Наиболее полно этот момент изложен в статье ещё аж 2010 года: "Статический анализ и регулярные выражения".
Обзорно про внутреннее устройство анализатора недавно была статья "Как PVS-Studio ищет ошибки: методики и технологии". Где опять-таки говорится, что регулярные выражения не используются. Вместо этого перечислены более серьёзные технологии, позволяющие находить сложные ошибки. Статический анализ только на первый взгляд кажется просто программкой, которую можно написать за месяц. На самом деле этот айсберг, над поверхностью воды от которого торчит только малая часть, от чего и возникают всякие заблуждения. Подробнее про это мы попробуем рассказать на C++ Russia 2017. Приглашаю на доклад «Как потратить 10 лет на разработку анализатора кода».
2. По поводу положительных отзывов. Да, мы пробовали подобным способом привлечь авторов, которые что-то про нас бы написали. Причем мы никогда не требовали, чтобы статья была хвалебной. Всегда предлагали писать, как есть. Однако, нас надо понять. Какой нам смысл давать лицензию, за то, что какой-то тролль ради прикола напишет, как всё плохо.
3. По поводу как всё плохо. У меня вызывает сомнения качество эксперимента. Уже не раз было, что как доходит до дела, то выясняется не низкий уровень анализатора, а низкий уровень того, кто его использует. Классическая случай на эту тему: "Народ против PVS-Studio: дубль первый". См. мой комментарий.
1) Ну так ведь и проходили мимо, пока "какие-то манагеры" из сабжевой компании не начали плакаться что "ой, мало юзеров используют".
Может и плакались, что в опенсорсе мало используют (и это логично — потому что нельзя было использовать бесплатно и не все готовы ради хобби проекта покупать дорогущий продукт). Пошли навстречу, сделали бесплатно. Но вы же понимаете, тут не благотворительность, поставили условия, чтобы отсечь тех, кому и денег жалко, и ЧСВ чешится. Я считаю, вполне правильно сделали — от таких личностей только проблемы будут, вечное нытье и распальцовка "вы мне должны". Да ну нафиг, лучше спать спокойно.
А если требует, то да, даже если бы (если бы!) он был на голову выше конкурентов, я бы тридцать раз подумал стоит ли такой текст комментария в каждом файле проекта этой вот разницы с конкурентами, или я лучше сам навелосипежу аналог, зато буду ментально здоров.
Ага-ага, навелосипедите. Потом год отлаживать будите, еще пару лет всякие фичи дополнительные вставлять, да граничные случаи отлавливать, там и новый стандарт уже, еще 5 лет на его поддержку (не забываем про параллельную правку багов). Боюсь, своим проектом заниматься некогда будет. Ну или поймете, что это ваше, через 10 лет сравним с PVS-Studio и Coverity ;)
И сабжевая компания ему даже предлагала год (или типа того) лицензии на свой продукт за обещание (!) написать положительный (!) отзыв
Ну так логично — если отзыв отрицательный, то значит продукт не понравился и лицензия человеку не нужна :). А если продукт не нравится, а отзыв пишется хвалебный (с прицелом...) — то наверное это проблема в человеке, а не компании, как считаете?
Так что повторю вопрос ещё раз?
Тут вы сами выдумали, какие технологии используются под капотом на основе информации от ведомства ОБС многолетней давности и просите прокомментировать. Извините, не буду :)
Давайте заглянем хотя бы в википедию:
Э́тика (греч. ἠθικόν, от др.-греч. ἦθος — этос, «нрав, обычай») — философская дисциплина, предметами исследования которой являются мораль и нравственность[1]
Что аморального или безнравственого в шутливой просьбе, дающей легальное право пользоваться анализатором?
Гитхаб сам по себе упоминается каждый раз, когда вы пишите git clone или даете ссылку на репозиторий. clang — проект с открытым кодом, странно, чего бы он это стал что-то требовать.
Гитхаб сам по себе упоминается каждый раз, когда вы пишите git clone
git clone https://git-wip-us.apache.org/..., где упоминание github'а?
clang — проект с открытым кодом, странно, чего бы он это стал что-то требовать.
А вообще он что-то требует, если вы, конечно, читали лицензию, с которой согласились при его использовании.
Однако я не понимаю, что вызывает такое отторжение вообще и от наших комментариев в частности. Программа SourceMonitor говорит, что код на 18 процентов состоит из комментариев. На первый взгляд, мне кажется, что комментарии-заголовки занимают 15% от всего проекта. Так чем-же не угадили ещё 2 строчки. Неужели Вы так сильно переживаете, что PVS-Studio потеснит Ваше имя с первых двух строчек… :)
/*
Copyright (C) 2016 Alexander Borisov
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Author: lex.borisov@gmail.com (Alexander Borisov)
*/Чудо от использования PVS-Studio не произойдёт. Однако PVS-Studio мог бы дополнить Coverity и поможет устранять ряд ошибок на самом раннем этапе. Например, мне кажется, что вот с этим кодом не всё в порядке:
myhtml_tree_attr_t * myhtml_token_node_attribute_first(myhtml_token_node_t *token_node)
{
return token_node->attr_first;
}
myhtml_tree_attr_t * myhtml_token_node_attribute_last(myhtml_token_node_t *token_node)
{
return token_node->attr_first;
}Мне кажется, во второй функции следовало написать «return token_node->attr_last;»
Или, например, здесь:
void * mycss_property_destroy_text_decoration(mycss_entry_t* entry, void* value)
{
if(value == NULL)
return NULL;
mycss_values_text_decoration_t *text_decoration = (mycss_values_text_decoration_t*)value;
if(text_decoration->color)
text_decoration->color = mycss_declaration_entry_destroy(entry->declaration, text_decoration->color, true);
if(text_decoration->line)
text_decoration->color = mycss_declaration_entry_destroy(entry->declaration, text_decoration->line, true);
if(text_decoration->style)
text_decoration->color = mycss_declaration_entry_destroy(entry->declaration, text_decoration->style, true);
return mycss_values_destroy(entry, text_decoration);
}Есть подозрение, что после Copy-Paste не изменена левая часть «text_decoration->color =».
Это я к тому, что тот-же Coverity не является панацеей.
Кстати, в своих проектах (не C++) я использую сервисы типа CodeShip и Scrutinizer. Их плашки у меня установлены (хотя они этого не требуют). Но если бы они хотели от меня модификации исходников, я бы от них отказался.
опыт же подсказывает, что статический анализ находит весьма малую часть проблем
Критичность находимых багов статическими анализаторами сильно занижена. АЭС не взорвётся, конечно (надеюсь), но пользователей тысяч разных программ они выводят из себя. Опыта одного человека недостаточно, чтобы сделать подобный вывод.
На днях буду писать статью о проверке одного крутого проекта и буду делать это с особым пристрастием. Там будет видна эта «весьма малая часть проблем» и как она потенциально сказывается на работе продукта.
А сколько боли принесёт ошибка в матанном алгоритме с приоритетом операций или использование одноимённых переменных из-за опечатки в одной букве? Это по-прежнему малая часть возможностей, но хотя бы речь идёт о серьёзных проблемах.
выявляются мелкими тестами
Не удержался. Что я вспоминаю при упоминании мелких тестов и их покрытии кодовой базы:
unsigned int count = GetCount();
assert(count >= 0)
Как говорится, «основано на реальных событиях»
clang-3.9.1/include -std=gnu++1z
К сожалению, современные компиляторы не так оперативно внедряются на практике.
Опенофис, падающий во время работы из-за того, что история изменений съела гига полтора? Легко.
Казалось бы, при чём тут ошибки в Open/LibreOffice? А, это, наверное, потому, что они до сих пор PVS-Studio не пользуются.
Ну так это, кстати, ещё вопрос: какой из сторон выгоднее сделать для PVS интеграцию плашечкой вместо правки сорцев, если в результате в проекте класса LibreOffice на главной репозитория появится плашечка PVS-Studio. По-моему, это выгоднее всем: реклама производителям анализатора и повышение качества кода в проекте. Но разработчики PVS искуственно ограничивают потенциальную аудиторию несмотря на то, что они (аудитория) всё равно в большинстве, вероятнее всего, не стали бы покупать такой продукт.
Остальные части вашего комментария к сути проблемы имеют мало отношения, поэтому я опущу ответ на них.
Действительно, как же можно сравнивать ошибки в программах, которые никому не мешают, и такое страшное действо, как вставить комментарии в код.
А я, вроде, и не сравнивал. Впрочем, если честно, мне вообще трудно распарсить, что именно вы пытались сказать в вашем комментарии. А оправдание тем, что пользователь важнее — это замечательно. Так можно ведь (утрируя) и требование отдать почку в обмен на бесплатную лицензию оправдать тем, что почка-то одна, а пользователей — миллионы.
Ах да, ну и на хабре может быть мнение только ваше и не верное.
[sarcasm]Вы уловили суть![/sarcasm]
Особенно, если у вас кармы хватает снижать ее тем, кто так не может.
Пресвятой Торвальдс, мы уже о Карме! Если вам будет интересно, я не трогал карму ни одного из комментаторов в этом треде. Для меня вообще изменение кармы должно сопровождаться чем-то серьёзным, а не глупым срачиком на тему правки сорцев.
Я свою позицию по этому вопросу уже выразил. Мне такие требования кажутся странными и я, если буду писать проект на C++ обойду PVS стороной и выберу конкурента, которому добровольно (Coverity, вроде, не требуют плашек) сделаю такую же рекламу, но без мусора в исходниках. Не потому, что мне не нравится PVS, а потому, что я считаю такое требование странным и завышенным.
В итоге, все останутся довольны: у меня будет статический анализатор, у Coverity появится потенциальный платный клиент, а PVS будут рады, что проект, разработчик которого счёл их требования завышенными, не использует их продукт. Секунду, или последнее звучит странно? А нет, тут уже несколько раз написали, что так и задумано.
угадили
Хорошая опечатка :)
Давайте начнём с того, что проекты, в которых ошибки критичны, не будут писать подобные комментарии во всех файла проекта ради бесплатной проверки своего кода каким бы то ни было анализатором.
Если в них ошибки и в самом деле критичны, то они 100% уже используют статический анализатор и довольны им (иначе бы не дожили до такого размера и важности проекта).
====
А вот в остальных проектах, где ошибки некритичны, разработчики имеют право воротить нос от таких унизительных комментариев и явного позиционирования своего продукта важнее текста лицензии.
Поэтому правильным было бы сказать не
Я не могу серьезно воспринимать комментарии, где плата в виде «комментария» объявляется слишком большой.
а
я понимаю, что у нашего продукта мало пользователей потому что мы выдвигаем несоразмерные "профиту" от его использования требования за бесплатное использование, и поэтому мы либо примем ваши пожелания по изменению требований к сведению, либо мы перестанем плакать что у нас мало пользователей и опять напишем статью, что линупс и опенсорс нинужны.
А вот в остальных проектах, где ошибки некритичны, разработчики имеют право воротить нос
Здесь уже несколько раз поднимался вопрос этики при работе с open-source. А разве этично так относиться к остальному софту, что не оборонка, опасное производство и т.п.?
Если вы хотите получить ответ на этот комментарий, сначала скажите что приняли к сведению высказанные мысли о том, что:
1) формулировка комментария для разблокировки триала — слишком унизительная и подлежит пересмотру
2) требование помещать его выше лицензии — имеет смысл так же пересмотреть
3) имеет смысл подумать о "плашках" в README* вместо комментариев.
и что обещаете обсудить внутри компании и рассказать о своём решении по этим вопросам.
Тогда мы поймём что вы настроены на серьёзное общение (а не на "огрызание"), и будем так же рады продолжить дискуссию
Ответ по всем пунктам: всё так и задумывалось.
Объясняю:
1) коммерческие open-source обходят стороной
2) индивидуальные разработчики радуются
3) разработчики open-source радуются
4) комментаторы негодуют
Мой вопрос: почему же к пользовательскому софту надо относиться хуже критичного?
Что вы скажете о «не критичных» багах в этих проектах?
Надо по возможности пользоваться статическими анализаторами даже для некритического софта.По возможности? Надо программировать без варнингов компилятора, пользоваться бесплатными инструментами повышения качества кода. И если есть возможность, привлекать платные инструменты.
разработчики open-source радуются
А тут вы неправы, о чём вам здесь (и в предыдущих тредах) многократно писали.
Мы получили немало благодарностей в почте, так что всё мы сделали правильно.
Не совсем логически верный довод, опять же. То, что вы получили некоторое количество положительного фидбека в почту не значит, что вы всё сделали правильно. Это значит, что вы начали двигаться в правильном направлении, а более высокие градации оценки этого уже могут являться лишь догадками.
Ложная дихотомия. Кроме тех кто доволен и использует, недоволен/комментирует и не использует есть ещё куча категорий: начиная от тех кому просто пофиг на ваш продукт, заканчивая теми кто недоволен, но не имеет достаточной мотивации, чтобы писать на хабр.
Ну и количество благодарностей нерелевантно оспаривоемому тезису, если, конечно это не благодарности от серьезных FOSS проектов, т.к. в нашем подлунном мире под open-source по умолчанию понимают free/libre open-source software, а не non-commercial open-source software.
Не считая того, что вы или ваш коллега в предыдущем посте явно говорили что F(L)OSS — не ваша аудитория. И после этого заявлять, что «разработчики open-source радуются» — это какое-то двоемыслие. Проблема крестика и трусов.
4) комментаторы негодуют
Никто не забыт.
1) коммерческие open-source обходят стороной
А могли бы вас рекламировать. Всё равно ведь не покупают.
2) индивидуальные разработчики радуются
а) Во-первых, не все. В комментариях явные примеры разработчиков, которые радовались бы, но не радуются.
б) Если речь о частных — могли бы и покупать, либо открыть код и рекламировать вас плашкой со ссылкой на главной.
3) разработчики open-source радуются
Судя по комментариям (и тому, как я вижу себя на их месте) — не особо и далеко не все.
На последний вопрос не знаю, что ответить, т.к. я вообще не очень его понимаю. Багов меньше должно быть везде.
Ответ по всем пунктам: всё так и задумывалось.
Кстати, чем-то напомнило скандал с JetBrains и новой системой лицензирования с подписками. В итоге они написали «мы ушли подумать и скоро вернёмся» и через месяц выкатили практически идеальный для всех вариант, за что получили новых подписчиков и уважение за реакцию на фидбек.
Давайте начнём с того, что проекты, в которых ошибки критичны, не будут писать подобные комментарии во всех файла проекта ради бесплатной проверки своего кода каким бы то ни было анализатором.
Именно так и задумано! В серьезных проектах такие комментарии вставлять не будут. И мы не потеряем потенциального клиентов, за счёт того, что просто дали возможность всем подряд использовать бесплатно.
А маленькие проекты могут использовать, а могут не использовать. Мы дали возможность, а решать им. На наш взгляд плата в виде комментария для них несущественна.
Не круто вешать плашки, а анализатором не пользоваться. Было множество случаев: разработчикам присылаешь статью с 40 багами, а они "… мы уже используем Coverity Scan...". Ну сорян, «пользуйтесь» дальше.
Разработчикам нужно присылать не "статью с 40 багами" (особенно, учитывая её текст "вот тут, наверное, может быть, скорее всего, по-моему, мне кажется, я думаю, надо было написать вот так вот, а не вот так, а тут разработчик, наверное имел в виду вот это", а так же зачастую дерзкий и отталкивающий заголовок), а письмо (если нет багтрекера), или баг на багтрекер (если есть) вида (не дословно, но по сути):
"мы, компания PVS-Studio, пишем очень мощный и удобный статический анализатор, который называется PVS-Studio.
Мы нашли в вашем проекте 40 потенциальных багов, которые ваш текущий анализатор, скорее всего, не нашёл. Посмотрите, пожалуйста на список ниже, и, если что-то из этого окажется ложно-положительным срабатыванием, отправьте нам, пожалуйста, фидбек на e-mail такой-то.
<список замечаний и комментарии к ним>
С наилучшими пожеланиями,
команда PVS-Studio
"
Вот тогда вас бы уважали и не отвечали "мы уже используем YYY, отвалите" даже не вчитываясь в ваше письмо.
А с текущим подходом странно удивляться такой реакции на вас. Я бы наоборот мог удивиться, что слишком мало людей посылают, если бы изучал "психологию потребителя" :)
Но, увы, в вашем проекте расстраивает то, что не смотря на ваши (компании) попытки изобразить, будто вам интересны программисты и их мнение (на самом деле, нет), сквозь каждую вашу (компании) статью или комментарий представителя просто "течёт" скрытый подтекст, что вам интересен только менеджмент компании (априори не разбирающийся в матчасти), которому можно впарить продукт. Потому что технология впаривания уже обкатана и даёт хорошие плоды.
Так зачем же слушать каких-то шавокопенсорс-программистов и менять свой подход? Тратить силы и ресурсы на это… Фи, придумают тоже! Итак бабло неплохо течёт.
Я привёл пример из жизни, после которого плашками можно не меряться.
баг на багтрекер (если есть) вида (не дословно, но по сути):
Дословно и по сути? Когда мы работали с Unreal Engine 4, некоторые баги неделями разбирали разные команды своих разработчиков, чтобы исправить.
Когда я увидел заголовок статьи, я подумал, что PVS-Studio интегрируется с GitHub и предоставляет сервис вроде travis_ci ;)
C юмором вы, похоже, не знакомы...
Вообще конечно «а для публичных репозиториев ГитХаба бесплатна» — сейчас выглядит как стандарт на этом рынке. Посмотрим, как у вас пойдет, интересно.
Я как понял, они хотят дать возможность использовать продукт и мелким командам. В крупных организациях никто не даст засорять код лишними коментами, а мелкие могут себе это позволить.
Думаю дело не в пиаре, а в том что-бы отсечь большие фирмы от этой акции наименьшими усилиями. Они могли бы попросить написать любой коментарий в принципе. Дело не в том, что кто-то будет его читать, а в том, что кто-то не будет его писать.
Естественно с ограничениями. Например, лимит на количество кода в проекте, символические $5 (или $1) за проверку, не чаще двух проверок в месяц.
Так отсекаем большие проекты, лишние мусорные запросы на проверку, которые могут положить онлайн сервис, и делаем себе рекламу, выдавая плашку о хорошем качестве кода для README при второй проверке.
Это только в качестве примера, который я придумал (но не продумывал) за 2 минуты. Правильный вариант может быть совсем иным.
А также, похоже, чтобы отвадить все well established open-source projects, которые разрабатываются под эгидой любых (в том числе некоммерческих) организаций, как то Free Software Foundation, Apache Software Foundation, Eclipse Foundation, Mozilla Foundation и подобных. Т. к. софт, который производят люди в рамках курируемых проектов, полезен не полутора землекопам, а куда более широкой аудитории, включая коммерческие фирмы.
Какой-нибудь YourKit даже никакой плашки не требует за право использовать из профайлер, чем вызывают уважение. Как JetBrains — хз, т.к. у меня all products pack и бесплатную версию у них не запрашивал.
JetBrains ничего не требуют кроме соответствия проекта критериям опенсорса.
все well established open-source projects, которые разрабатываются под эгидой любых (в том числе некоммерческих) организаций, как то Free Software Foundation, Apache Software Foundation, Eclipse Foundation, Mozilla Foundation и подобных.
Это всё относится к большим фирмам, которые могут позволить приобретать софт для сотрудников. Надеюсь вы не посчитали, что на проектах с открытым кодом никто не зарабатывает также, как на закрытых проектах.
ASF, например, имеет мизерное количество сотрудников (наёмные админы), все разработчики более 400 проектов — волонтеры и выступают с позиции индивидуальных разработчиков. Но сказать, что, например, Hadoop — non-commercial software язык не повернется, хотя ASF на нём (как и на остальных проектах) деньги не зарабатывает.
- Реально, интеграция типа Coverity гораздо удобнее.
- А что делать компаниям (мелким, но), выпускающим Open Source? Хоть и выпускающим эти продукты часто от частного лица, но вот у меня большая часть больших проектов (open source, часто автор давно ушел, а я maintainer) принадлежат организациям.
Эдык его накрыло, такого понаписал, аж волосы на голове зашевелились
Этого недостаточно ― необходимо указывать, что используется продукт под GPL (you must show them these terms so they know their rights), а также привести либо объектные файлы рядом с дистрибутивом, либо указание на то, что объектные файлы необходимо запрашивать по почте (If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place).
Сейчас проверил еще раз —
$ grep -ri GPL pvs-studio-6.13.20904.1-x86_64 | wc -l
0
(1) If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
6. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place
And you must show them these terms so they know their rights.
Dear PVS-Studio, please do not violate GPL.
На каждом экземпляре такого произведения Лицензиат обязан поместить уведомление, содержащее указание на то, что данное произведение использует Библиотеку, распространение, модификация и использование которой осуществляется в соответствии с настоящей Лицензией. Лицензиат также обязан к каждому экземпляру произведения приложить копию настоящей Лицензии. Если в процессе исполнения произведения на дисплей выводится знак охраны авторского права, Лицензиат обязан включить в него знак охраны авторского права в отношении Библиотеки, а также ссылки, следуя которым пользователь может ознакомиться с экземпляром настоящей Лицензии.
d) если распространение экземпляра произведения осуществляется путем предоставления доступа для копирования его из определенного места, такое распространение должно сопровождаться предложением равноценного доступа для копирования из этого же места материалов, указанных в подпункте «а» пункта 6;
6. Как исключение из положений предыдущих пунктов настоящей Лицензии Лицензиат вправе объединить или связать Произведение, использующее Библиотеку, с Библиотекой, в результате чего будет создано произведение, содержащее части Библиотеки. Лицензиат вправе распространять такое произведение на любых условиях, при этом за пользователем должно сохраняться право вносить изменения в произведение в целях его адаптации для собственных нужд, а также право осуществлять восстановление структурной схемы алгоритма работы по исходным текстам произведения для отладки внесенных изменений.
На каждом экземпляре такого произведения Лицензиат обязан поместить уведомление, содержащее указание на то, что данное произведение использует Библиотеку, распространение, модификация и использование которой осуществляется в соответствии с настоящей Лицензией. Лицензиат также обязан к каждому экземпляру произведения приложить копию настоящей Лицензии. Если в процессе исполнения произведения на дисплей выводится знак охраны авторского права, Лицензиат обязан включить в него знак охраны авторского права в отношении Библиотеки, а также ссылки, следуя которым пользователь может ознакомиться с экземпляром настоящей Лицензии. Лицензиат обязан также выполнить одно из следующих условий:
Использует ли PVS-Studio библиотеку под LGPL? — да.
Выполняет ли оно один из последующих пунктов a-e? — нет.
Отмахивание формальностями, специфичными для разных стран, распространение информации о способе получения объектных файлов в комментариях на хабре, непредоставление копии лицензии — это что угодно, но не дружба с opensource-сообществом.
Нет, я серьёзно не понимаю, почему opensource-проектам нужно вставлять в себя для проверки унизительные комментарии, а вам — так сложно выполнить два ужасно простых требования лицензии? У вас от этого убавится?
- Она проставляла комментерии во все файлы, включая AssemblyInfo.cs и *.Designer.cs, хотя анализатор не ругается, если их там нет — я это убрал
- Не добавляла пустую строку после себя — пришлось добавить
PVS-Studio и GitHub-сообщество: начало дружбы