Pull to refresh

Comments 96

Кстати. Как по мне, так честный счетчик для оплаты сделать невозможно. Не «сложно», не «громоздко» — просто невозможно.
Каждый раз, как только он «вроде работает» будет вылезать очередной бок — всё таки, любая область после всех упрощений становится сферой, а сфера, как известно, является бесконечногранником.
Спасибо за комментарий! Я кстати, наверное, согласен даже с этим. А что если упростить и говорить«честный с точки зрения продавца»? Все-равно невозможно?
А «с точки зрения продавца» у вас уже было.
Сделайте онлайн сервис, с не длительной оплатой подписки, что бы, если пользователи планируют пользоваться программой долго — им было выгоднее купить лицензию.
Вы имеете ввиду залить исходники на сайт для проверки?
Кто-то по такой модели уже работает. Veracode, кажется.
Я думаю это не так. Никто не будет заливать свои исходники на чужой сайт для проверки. Ведь риск утечки не просто большой, а фактически это и есть утечка. И тут вопрос не в доверии компании, а просто во всех корпоративных документах запрещается прямым текстом утечка исходников.
Ну некоторые конторы хранят на гитхабе свои исходники. Это и есть утечка. И их она устраивает.
Онлайн-сервис проверки «вашего гитхаба» вполне может оказаться востребован.
Ну все-таки согласитесь, что 1С свой код на github не держит и никогда не будет. И подобные компании (с подобным кодом) не будут.
Что не отменяет ценности гитхаба, разумеется.
Цель онлайн-сервиса — охватить отнюдь не 1С и иже с ними (для них остаётся прежняя модель лицензирования Site), а для охвата мелочи — повысить продаваемость в массовом сегменте.

Плюс, оно сразу может гадить в тот же github issues / bitbucket и онлайн-сервисы типа pivotaltracker и аналоги.

в общем, молодЕжь стала очень ленивой — и готовый предконфигурированный сервис реально востребован, у реальных контор, с реальными деньгами. вы зря так отказываетесь от этой модели.
Я вижу 3 большие проблемы у такого сервиса. Первую — отдачу исходников на сторону, уже обсудили. Однако, есть две другие большие проблемы.

2) Сложность создания сервиса.
3) Сложность его использования.

Сейчас поясню.

2) Для работы нам необходимы сторонние библиотеки, чтобы осуществлять препроцессировние. Если препроцессирование не осуществлять, это сильно ухудшит качество анализа и потребует серьезных переделок самого анализатора. Плохой вариант. Значит надо, автоматически «подсовывать» библиотеки, которые только могут потребоваться (boost, jpeg, zlib и так до бесконечности). А как угадать, с какой версией этот проект собирается, а с какой нет? В общем, на автомате невозможно угадать, какие библиотеки и каких версий нужны, и где их взять. Значит, пользователь должен вручную залить все требуемые библиотеки, прописать всякие пути и настройки. И это приведет к проблеме 3.

3) Поскольку непросто настроить и поддерживать окружение, чтобы проверять проект, это будет всё неинтересно. Не получится то самое простое «залил быстренько и проверил». И привлекательность сразу теряется. Более того, статический анализ это инструмент регулярного использования. А раз так, проще настраивать работы с PVS-Studio у себя, чем постоянно ходить обновлять библиотеки и настройки где-то там…

То есть я это всё к чему. «готовый предконфигурированный сервис реально востребован» — да это так. Вот только таким этот сервис не получится. Жаль.
Можно сделать CI сервер, в котором будет все это описываться + прогоняться тесты + проверка статическим анализатором. Платная подписка на такой сервис, плата в зависимости от кол-ва билдов в день, на пример
А зачем городить такой огород с сервисом? Проще установить PVS-Studio и использовать инкрементальный анализ, моментально находя ошибки при опечатках. Или, если хочется, настроить ночные проверки на компьютере, осуществляющем ночные сборки.
Всё просто. Вы работаете с продуктом давно, вы нашли реально максимально эффективный способ его использования.
Вот только это модель использования — как вам привычно. Современное поколение работает иначе.
Для меня это тоже непривычно и удивительно, это реально как по мне, так менее эффективно — однако это их выбор и их методика работы.
Зато они платят за использование, как им кажется, меньше, отдавая всё больше и больше на сторону с оплатой по каждому поклону.
Их это устраивает — так почему бы им не дать инструмент в привычном им форме?
Не надо переучивать людей — они этого не хотят.
А еще решится вопрос с кроссплатформенностью.
Не решится, а станет неподъемной задачей. Я про это писать не стал, так как не вижу смысла начинать ещё и эту тему. Даже в рамках поддержки VS2005-2012 есть ощущение, что работаем с разными платформами. Язык Си/Си++ везде немного свой. Это не заметно программисту, а вот нам очень тяжело. Не буду рассказывать почему. Поверьте. :)
Чем проще? Сделал пуш в репозиторий, CI тут же подтянул, собрал билд, прогнал тесты, PVS-Studio все проверила, лог можно и на почту скинуть. По мне так вообще шикарно, учитывая что сервера мощнее обычных ноутов.
Что ж, давайте посмотрим.
Если у вас проект лежит в гитхабе, значит вы либо (а) единственный разработчик, который хочет вести историю, (б) небольшая команда, которая работает над ним.
Начиная работать с VCS, подавляющее большинство не занимается обновлением библиотек.
В сях нет принятой схемы а-ля гемов рубей, поэтому чаще всего их либо подцепляют через git submodule (высший пилотаж), либо прямо хранят в репе (удобный случай), либо тупо в txt для «будущих поколений» записано «возьмите такую-то либу такой-то версии», причем список не полон и версии хорошо если указаны с которой когда-то собиралось.

В случаях (1) и (2) вопросы 2 и 3 — отпадают. И там и там для сервиса есть вся необходимая информация — checkout --depth 0 + проверка

В случае (3) я вижу только два способа решения 3го вопроса — это либо приведение репозитория к виду 1 или 2 (от чего команда сама выиграет), либо создание небольшого визарда, который будет детектировать используемые библиотеки по #include'ам, и предлагать выбор («последний stable», «самый последний», и несколько стандартных версий). Как ни странно, в большинстве случаев, «последний stable» будет досаточен.

Если смотреть со стороны linux мира, я, когда собираю что бы то ни было, оно очень часто сишное, я вопросы зависимостей решаю установкой последней доступной в репе сборки — то бишь «последний stable». В 99% случаев всё работает.

Поэтому, я хорошо представляю себе интерфейс и сложность создания такого сервиса.
У меня есть опыт создания онлайн сервиса, используя «обычные» windows программы, потому я вполне могу сказать, что сложности создания нет больших проблем, как ни странно.
«The best way to build and ship software, on your servers.»

Соответственно код на собственных серверах компании (в отличии от стандартного исопльзования где код в облаке) => никаких утечек
Прочитал вашу ветку ответов, считаю что мысль подписки предложенная выше действительно правильная, а вот предложенная реализация хромает. Вам ничто не мешает интегрировать лицензирование по подписки для маленьких компаний, перепишите компонент лицензирования на подписку, интегрируйтесь с веб-биллингом или напишите свой, и воля ваш сегмент маленьких компаний охвачен (если цены у Вас конечно будут приемлемо демократичны) Adobe Cloud CC работает же по подписке и это реально выгодно для конечных клиентов. Хотите можем Вас попроцессить у нас есть свой платежный шлюз (15+ способов оплаты).
Так одно ж другому не мешает! Можно И подписку на полную версию, И online-сервис, И Site License по текущей схеме.
Меня не надо, у меня тоже есть свой платежный шлюз :)
Вот только есть одно «но»: используя весь арсенал вариантов, становится похоже на попытку продаться «ну уж хоть как нибудь»…
Адоб, Юнити3д и другие, кто ввёл подписку делажт это не потому что у них проблема «продаться хотть как нибудь», а стараются охватить максимум рынка.
Я как-то не готов отдать треть, а то и половину месячного бюджета маленькой гейм-дев студии, пусть даже и на такую полезную тулзу.
В Амазоне можно сделать образ виртуалки с некоторым набором предустановленного софта и сдавать его в аренду на время (по часам, по месяцам). Вполне себе вариант — поставите туда PVS, настроите окружение, покажете, что «из коробки» работает проверка какого-нибудь Hello world, а нужные либы покупатель себе доставит, и код свой зальёт. Утечки кода нет (виртуалка не ваша, а пользователя), возможность конфигурации — есть.

Я вряд-ли когда-нибудь в жизни найду эти тыщи баксов на покупку PVS, но вот десятки-сотни на месячную аренду — вполне.
Это может взлететь как рекламная акция. Действительно отказаться от препроцессирования для гитхаба, собрать пауком 100500 проектов, загрузить ими свободное время сервера, отчеты с дефектами разослать авторам с объяснением, почему с препроцессированием (и регулярное использование, раз уж речь зашла) было бы еще круче.

Если бы мне пришло на почту, мол, в таком-то файле на такой-то строке дескриптор потек, я бы заинтересовался.
Тут не обойтись без ручной работы, так что 100500 отпадает.
Если по почте придёт ложное обвинение, что тут «дескриптор потёк», без вникания в ситуацию (а может автор в другом месте подстелил соломку), будет только хуже.
Кстати тема с гитхабом интересная… Крупным хостингам исходников такой дополнительный сервис может оказаться интересным, Вы не пробовали предложить свой сервис тому же гитхабу или битбакету?
Не пробовали. Поможете нам пробиться туда?
К сожалению, не имею отношения ни к тем, ни к другим :( Напишите им напрямую, «за спрос денег не берут»…
У нас в отраслевом стандарте прописана независимая верификация. То есть исходники не просто можно, а обязательно необходимо показать независимым специалистам.
Да, такой рынок есть, мы про него знаем и иногда подумываем там «половить рыбку». Но это к «онлайн-проверке» отношения ведь никакого не имеет, согласитесь.
Просто отвечаю на предыдущий комментарий. Раскрывать код — не страшно.
Тогда, с точки зрения маркетинга это будет еще одним плюсом полной и дорогой лицензии. Если не ошибаюсь, в топике то идет речь о мелкоте.
+1 за онлайн сервис + за синхронизацию с системами контроля версий для встраивания в CI и проверки каждого комита
Встраивание в CI давно есть и работает. Если есть проблемы с интеграцией — пишите в поддержку, подскажем.

Про онлайн-сервис ответил выше.
Самый ваш опасный конкурент — не Gimpel и Coverity, а CppCheck, как ни странно. Он открытый и у него 77 контрибьюторов. Да, он кривоват, и ложных срабатываний там многовато, и не все проверяется достаточно хорошо, но это живой проект, в который имеет смысл инвестириовать время и деньги. Лучше вложить в проект, который развивается сообществом и кастомизируется под наши нужды, чем в коммерческий проект, который сегодня есть — завтра кризис.

С другой стороны, определенная ниша CppCheck не покрывается. Например, у нас на фирме ветер дует в сторону внутреннего стандарта на С++. Потребуется инструмент для поддержки этого несуществующего стандарта. Вот перепилить Cppcheck под него можно, конечно, но получится плохо, долго и дорого. Потому что хорошо мы делаем железки для АЭС, а не статические аназизаторы. Нам проще, соотвественно, купить статический анализатор с грамотно кастомизированной сборкой правил, чем делать ее самостоятельно. И за это уже можно и заплатить хороших денег.
Очевидно, что всем нравится нельзя. Я как про PVS-Studio, так и про CppCheck. Кому CppCheck достаточно — так и прекрасно, надо использовать это решение. Кому по каким-то причинам его мало или требуется что-то такое, что он не умеет — другое решение возможно подойдет.
В каждом топике найдется кто-нибудь, кто склоняет «пацанов» в сторону open source модели. Их яростно плюсуют и т.д. Это глупость. Мне кажется идеальный вариант для «пацанов» — это форм-фактор какого-нибудь Codeclimate с баджиками и фришечкой для опенсурсников + standalone версия. Над форм-фактором надо подумать, конечно. Нет ничего нереализуемого.
Ни в коей мере не склоняю! Уж что-что, а второй Cppcheck никому точно не нужен. Наоборот, пытаюсь сказать, что конкуренция на поле статических анализаторов из коробки бесполезна, потому что с одной стороны PRQA и LDRA с огромным штатом и десятилетиями научной работы, а с другой стороны подпирает Cppcheck, который становится лучше и лучше и привлекает все больше людей. Надо выходить за рамки этого поля.

На самом деле, практически все крупные игроки уже предлагают инжениринговые услуги того или иного рода, но на этом поле вполне реально с ними потягаться. Например, в случае адаптации того же анализатора под внутренние стандарты большинству отечественных контор старой школы банально проще составить ТЗ на русском и по ЕСПД, чем залазить в дебри международного сотрудничества.
Понял о чем вы, согласен.
Что-то мне кажется, что с постами о PVS-Studio на хабре уже перебор. Стало напоминать назойливые промо страницы и вызывать желание засовывать их под адблок…
Предлагаю писать больше статей о Си++, паттернах, алгоритмах. Таких статей действительно мало. Вот и получается, что мы часто мелькаем перед глазами. А так, будем попадаться на глаз изредка. :)
аффтар, пеши исчо! Лучше больше статей о PVS-Studio и меньше о всяких РНР.
Выражу мысль чуть иначе: читать ваши статьи с разбором ошибок в коде на С++ — интересно. А вот топику о ценообразовании PVS место в блоге компании, а не в хабе «Разработка».
По-моему, ваша модель монетизации осталась в прошлом веке… Обращайте побольше внимания на то, как работают другие компании. Большинство современных компаний, даже самых крупных, работают по принципу не как продать дороже, а как продать большему количеству клиентов, а с такими конскими ценами у вас их никогда не будет много… Но как это делать дифференцированно… Ориентируйтесь не на крупных клиентов, а на мелких и средних, не на корпорации, а на людей, их больше, их значительно больше (это уже теория больших чисел)… Следуйте нынешним тенденциям и современным практикам, делите продукт на кусочки и продавайте по-модульно: базовые функции анализа — одна цена, стремящаяся к нулю (или, о боги, вообще бесплатно?), требуется дополнительная возможность проверки на потенциальные баги из условной категории багов условного класса А (не знаю, например, что-то с приведением типов, whatever) — отдельная небольшая цена на этот анализирующий модуль, требуется проверка именования переменных/методов (беру с потолка) — вот вам отдельный недорогой модуль, приобретите его в нашем in-app-purchase-магазинчике-дядюшки-Джо и тд… Модули можно продавать бандлами, по разным акциям и поводам проводить скидки, розыгрыши, дарить (как можно?!?) и т.д. В итоге, рисую прекрасное будущее: миллионы крестоносцев хлынут на ваш продукт, дикая популяризация, не слишком богатые буратины будут делать себе (и своим друзьям?) периодические подарки в виде покупки модуля или бандла на день программиста или к рождеству, и ощущать всеми фибрами насколько они становятся круче и профессиональнее с каждой покупкой, более серьезные компании будут приобретать более серьезные комплекты разом, совсем монстры — будут брать оптом (оптом — дешевле), что в сумме будет примерно выходить как те же 5 тыщ европейских ценностей… Беспрерывный поток монеток обеспечен… Еще, как вариант и достаточно часто практикующийся (но не очень мною любим) — подписки… Хотите наш сексуальный продукт? Приобретите подписку на год всего за 299 долларов 99 центов, если ваша ежегодная прибыль составляет менее 100 тыщ убитых енотов (что легко выявляется по косвенным признакам, и никто не мелочится с такими доходами, нервы и репутация дороже), приобретите подписку всего за 99 долларов 99 центов… И да, больше доверяйте людям, сейчас другое время, люди готовы платить, если вы готовы им предоставлять удобные гибкие и недорогие сервисы… Тогда при правильном подходе у вас даже будут покупатели, т.н. плюшкины, которые будут покупать, даже если им это не нужно, просто чтобы было, недорого ведь…

«Хау! Я все сказал!» ©
>Приобретите подписку на год всего за 299 долларов 99 центов, если ваша ежегодная прибыль составляет менее 100 тыщ убитых енотов (что легко выявляется по косвенным признакам, и никто не мелочится с такими доходами, нервы и репутация дороже), приобретите подписку всего за 99 долларов 99 центов

Приезжаете вы в магазин на мерседесе и тут для вас все цены в 2 раза дороже. Не, не катит. Должен быть либо другой магазин, либо другой сервис.
Вот, и вы купились на магию цифр )) На самом деле в 3 раза))
А по теме, посмотрите на ту же модель монетизации Unity3D. Там базовая версия вообще бесплатна, по достижении определенной планки ваших доходов вы обязаны приобрести Pro-версию… И при желании это легко отследить, любая компания, достигающая определенного уровня, начинает отсвечивать (показатели популярности и количества закачек их продукта, присутствие и положение в различных рейтингах и тд), но даже это не нужно, смысла химичить и рисковать с определенного уровня доходов у таких клиентов нет, цена вопроса не та, они с радостью заплатят ту уже относительно небольшую для них сумму (в сравнении с их доходами) и получат полнофункциональную версию с поддержкой… И да, у Unity продукт делится на модули, вы можете подобрать себе ту конфигурацию, которая нужна именно вам для ваших задач… Так же, как альтернатива, у них есть и месячные подписки на Pro-редакцию…
Основная фишка в монетизации многих современных компаний, таких как Unity в том, что для начала они дают возможность заработать своему клиенту, а уже потом предлагают ему поделиться радостью, что клиент делает с широкой улыбкой и приходит еще… А если изначально у вашего потенциального клиента денег мало или нет вообще (хотя он и рад бы заплатить, но нечем) — то вы оба остаётесь ни с чем…
Ну и цены на Юнити более божеские (по крайне мере если сразу на все платформы не грести).
Плюс есть помесячная подписка :)
> Плюс есть помесячная подписка :)
Ага, только сначала надо купить 12 месяцев. Просто взять, например, на 3 попробовать нельзя.
Ну что-ж, давайте попробуем так.
Приглашаем Вас и всех желающих на сайт www.cppcat.com.
Здесь Вы найдете альтернативу PVS-Studio ценой в $250.
Согласен с комментариями выше, что у крупняка и мелочи разная модель потребления. Если я лид в крупной конторе, то мне гораздо проще выбить несколько тысяч $ на покупку дорогого продукта, чем оплатить SAAS сервис по 100$ ежемесячно. Это законы бюрократического жанра :)
Т.е. это естественный способ сегментации клиентов и можно его использовать, если придумать, как продавать сервис по подписке.
Конечно, сделать сейчас версию опять за $500 не вариант. Я не буду приводить здесь все рассуждения и подсчеты. Поверьте на слово — мы будем зарабатывать меньше, а поддерживать большее количество людей.
Сделайте версию без поддержки. Например мне, как индивидуальному разработчику, она не нужна, а PVS-Studio для личного пользования за небольшую суму я бы купил.
Вот и я о том же, поддержка нужна в основном только крупным клиентам, особенно, если учитывать, что основная аудитория — гики, большинству она не нужна…
Торгуйте скоростью анализа: Сделайте версии, которые анализируют код очень медленно и версии, которые анализируют код быстро.
Как сделать медленно — напихайте лишних циклов, заюзайте 32 битный режим, один поток/ядро.
И получится, что за дешево — очень долго, а приемлемая скорость только за большие деньги.

Пример из жизни: Sony Vegas. 64 битная Pro версия в разы быстрее работает, чем любительская 32-х битная…
PC-Lint c одной стороны дешевле и пожизненный, с другой — гораздо менее удобный из-за слишком большого количества замечаний. Для «0 предупреждений» нужно писать на Lint, а не на С, как иногда про него шутят.
Coverity — гораздо дороже. И поэтому возможно не сильный конкурент. А вот Klocwork по цене вплотную подбирается к вашей текущей цене, а по функциональности и удобству, мне кажется, превосходит.

И есть ли у вас какой-нибудь способ преодолеть следующее: разработчики прекрасно понимают пользу анализатора и хотят его использовать, а вот те, кто могут одобрить трату денег, банально не видят в этом смысла, смотря на это как на невозвращаемую инвестицию — ибо метрики «качество кода» и «удовлетворенность заказчика», выраженной в денежном эквиваленте, пока еще не придумано, особенно для схемы проекта «time and material», когда сокращение времени на разработку приводит к явно видимому снижению дохода. Думаю, такая ситуация — отнюдь не редкость.
Точно. Была «Плохая идея №1», а перешли на «Плохая идея №2».
Я не понимаю почему Вы не предоставляете свой софт по модели SaaS, уже давно договорились бы с Amazon и Microsoft на счет стандартных образов для их облак — оплата за часы использования, по сути — софт сдается в аренду. Человек НЕ отправляет код на чужой сервер — т.к. это его собственный сервер, а с Вашей стороны нужно только проверять соответствие UUID виртуальных контейнеров и все.
Может это будет вам полезно: secure outsourced computation. Т.е. идея в том, что все вычисления с trusted authority можно провести без него, если использовать криптоалгоритмы. Сложность, конечно, возрастает, но сама идея довольно интересна.

Картинка хорошая, но меня не оставляет мысль, почему единорога рвет?
Вы когда-нибудь программировали?
Каждый видит в меру своей испорченности. Это его не рвет, это он питается радугой! :)
Скажите пожалуйста, есть ли где-нибудь сравнение PVS Studio с g++, CLang и т.д. которое объективно поакзывает насколько PVS Studio лучше?
Например, вот мы сравнение делали.

А если в двух словах — то мы в clang можем найти ошибки (и находим), а они в нас нет :-).
UFO just landed and posted this here
А три? Можно оответ в личку?
Команда проекта — три C++ прогера, пару художников, пару левел дизайнеров.
Кстати, пишите, пишите нам!
В конце концов, этот пост не для обсуждения github, а повод пообщаться с небольшими командами ;-).
Присоединяюсь к вопросу. В моем случае — один программист. Тематика схожа, объем проекта мал (менее 1 Мб кода), но ошибки в нем критичны.
Как я рад, что среди примеров ошибок не встретились PHP, Redis и Postgre :)
Или не проверяли?
Сейчас быстренько проверил Redis, так как там имеется *.sln файл. Другие проекты, как-нибудь потом попробуем посмотреть. К (своему) сожалению ничего интересного не нашлось. В глаза бросилась только пара пропущенных break:

int win32_pthread_join(pthread_t *thread, void **value_ptr)  {
    int result;
    HANDLE h = OpenThread(SYNCHRONIZE, FALSE, *thread);
    REDIS_NOTUSED(value_ptr);

    switch (WaitForSingleObject(h, INFINITE)) {
            case WAIT_OBJECT_0:
                    result = 0;
            case WAIT_ABANDONED:
                    result = EINVAL;
            default:
                    result = GetLastError();
    }

    CloseHandle(h);
    return result;
}
Забыл упомянуть обязательную мысль. Статический анализ, это инструмент постоянного использования, а не для однократных атак. Здесь ошибки найдены и устранены другими методами. Возможно, намного более дорогими.
Интересный код. Работает только потому, что в большинстве случаев WaitForSingleObject завершится успешно и GetLastResult также вернет 0.
Я думаю, что он работает скорее потому что, никому не интересна винда на серверах :)
А Redis все таки — сторадж, пусть и для небольших объемов данных.
а всё-же в нём есть sln-файл и WaitForSingleObject
Судя по статье (на которую ссылается вики) Redis портируется под винду сотрудниками Microsoft, а не самими разработчиками. Так что это не отменяет факта о ненужности винды на серверах :)
Удивительно, и как это Майкрософт не сделал собственную балалайку?
Это риторический вопрос? Наверное они разумно решили, что переписывать тонны софта с уже работающих решений на их собственные изобретения никто не будет.

Ну и плюсом, сделать свой storage-балалайку просто офигенно не тривиально, а они портом то занимались порядка двух лет.
Возможно скажу глупость, но может есть смысл «платить за ошибки»?
Т.е. вы продаете лицензию по которой программа может найти 10000 багов. Закончились — нужно докупить еще.

Идея проста для понимания, и приучает писать правильный код)) Кроме того удобно проводить разные акции и скидки просто раздавая купоны с «багами» :)
А как узнать, что найдено N багов?
Программа и будет их считать. Понятно что можно сделать crack для сброса кол-ва багов, но ведь так любую защиту можно взломать…
Я не про защиту. Как отличить баг от ложного срабатывания? Как узнать, что ошибку поправили?
Насчет ложных срабатываний — это дискуссионный вопрос. Ну, у вас же есть какая-то оценочная функция, выдающая уровень критичности найденного участка? Например, считать за баг только критичный уровень выше среднего… Или ложное срабатывание вообще может быть на голом месте? Тут без поллитра примеров не разобраться…
Согласен.
Плюс, баг ведь как-то привязывается к конкретному месту в программе, тогда в дальнейшем можно баг в этом месте не учитывать и все.

Насчет ложных срабатываний, это скорее вопрос к программе — насколько часто она ошибается? Можно давать «багов» с учетом ложных срабатываний, можно считать только критичные баги, можно наконец привлечь пользователей — «программа ошиблась? обоснуй и получи 1000 багов на свой счет»)))

Главное — перейти к модели когда пользователи платят за реальную пользу от программы, а не за время, кол-во рабочих мест или размер фирмы…
Рискну еще разок быть слитым)) Прогоняете анализ, идентифицируете каждый баг (по номеру строки, содержанию, типу, контексту и тп), сохраняете полученный список в таблицу багов конкретного проекта (файла проекта?), при следующем прогоне проверяете остались ли баги, найденные при предыдущем анализе, если нет, то исправленные баги удаляете из таблицы багов, их количество вычитаете из счетчика доступных клиенту для исправления багов, а вновь найденные и не идентифицированные ранее баги (отсутствующие в таблице) добавляете в таблицу багов и так по кругу, пока счетчик не закончится… Здесь, скорее, более актуальный вопрос как хранить счетчик доступных багов, вариантов может быть несколько, например — пользователь регистрирует у вас свой аккаунт, к аккаунту привязывается все остальное — в нем есть счетчик багов, те же таблицы идентификаторов (метаинформации) багов по проектам (файлам проекта?), в нем же совершаются и сами покупки онлайн, активируются скидочные купоны и т.д., а при входе в программу пользователь логинится под своей учеткой и студия загружает всю информацию по аккаунту и доступным ему возможностям, а точней — синхронизируется, и сохраняет изменения, причем, в таком случае, саму студию вообще ненужно продавать или привязывать к машине, а просто свободно распространять, вся монетизация будет производиться через аккаунты и любой человек на любой машине сможет воспользоваться продуктом под своей учеткой, а вы, в дополнение ко всему, еще и сможете собирать статистику по багам и тп. Возможны вариации и расширения функционирования, типа автономного режима работы, пока не исчерпается лимит, а затем будь добр залогинься и приобрети слудующую порцию багов. Я так вижу…
Согласен, примерно так я это себе и представлял)

Хотя можно дополнить. Для тех кому неудобно постоянно работать в онлайне — выдавать ключи активации. На ключе программа отработает положенное кол-во багов. Если нужно перенести лицензию на другой компьютер — программа генерирует новый ключ к котором «зашито» число оставшихся необработанными багов. Ставите систему, повторно активируете и все.
Если нужно работать на двух машинах — можно сгенерировать ключ в котором «зашить» не все оставшиеся баги, а скажем половину, вторая половина остается на первой машине. Активируете вторую машину этим полученным ключом и работаете. В ключе можно хранить также ID лицензии. Таким образом можно «разделить» купленные «баги» хоть на сотню машин, но все они будут идти по одной лицензии.

При подаче заявки в техподдержку — нужно требовать код из программы который будет содержать ID-лицензии, ID-ключа и кол-во багов. Тогда вы на своей стороне сможете отслеживать динамику работы и пресекать случаи мошенничества.
UFO just landed and posted this here
Спасибо за комментарий и за обсуждение в личке!
Мы готовы предложить вариант for fun за $250. Вот он — CppCat. С нетерпением будем ожидать ордер от Вас. :)
Sign up to leave a comment.