К сожалению (или к счастью) мы живем в глобальном мире глобального рынка, а РФ на текущий момент не производит в полном цикле практически ничего, что нужно было бы (раннему) пенсионеру. Внутри еды заложен импортный семенной материал и техника, внутри промышленной продукции - импортные технологии и станки, внутри лекарств - импортные технологии и сырье, и т.п.
Все эти импортные вещи торгуются за доллар и юань, поэтому "долгосрочные цели в рублях" - это очень странный предмет, он вроде есть - оп, и его уже нет. В фиате вообще странно хранить деньги (это средство обмена, а не накопления), но ставить долгосрочные цели в слабой нестабильной валюте - это опять же огромный риск, никак не покрывающий упомянутые вами.
Нужно еще добавить, что подобные ПИФы на развивающихся рынках (а рынок РФ - именно такой) хоть и приносят относительно высокую доходность, но при этом имеют очень значительный системный риск, связанный и с особенностями рынка, и с курсом локальной валюты, и с политическим климатом, и с постоянно меняющимися правилами. Эти 9-10% - это в рублях с непонятным (т.е. "очень надеемся, что работающим") хеджированием инфляции и непонятными страховыми перспективами. Если вот это называть надежным, то что тогда ненадежное...
Есть относительно надежный способ получать около 3-6%, но не в виде конкретно дивидендов (потому что они генерируют налоговые события, и этим зачастую неудобны) - широкие пассивные индексные фонды, либо американские (но тогда лучше иметь американское же налоговое резидентство, чтобы не попасть под налоги неприятные, или, в крайнем случае, жить в стране с низкими процентами по dual taxation treaty, вроде Болгарии), либо ирландские (в них уже учтены американские налоги на дивиденды и интерес в 15%, и можно взять накапливающий вариант того же фонда вместо распределяющего). У меня самого сейчас весь портфель сделан из VTSAX (основной источник премии за риск), VBTLX (хедж на случай сильного падения рынка акций) и AAPL (надо продать, но налоги пока слишком высокие, жду возможности оптимизации). Если налоговое резидентство США получить не вариант, можно купить у любого европейского брокера те же самые широкие фонды, только с ирландским домицилем (VEVE и аналоги, justETF поможет выбрать).
С российскими брокерами и ПИФами посоветую не связываться, даже без учета всех нынешних проблем с санкциями, потому что у них совершенно сумасшедшие комиссии (1% и выше). Максимум - дальнейшая диверсификация в собственный портфель из местных акций и облигаций, с оплатой самому себе за управление портфелем, но это уже не пассивный доход, а полу-пассивный, потому что работать над ребалансировкой придется все равно.
Скорее всего, пытаются успеть занять освободившуюся нишу как можно быстрее, а затем уже думать, как монетизировать доработки под конкретных корпоративных пользователей, продавать плагины, поддержку и т.п. Если сразу делать фремиум - пользователи могут уйти к опенсорсным конкурентам, и потому занять нишу не получится.
Радость от программирования (а оно реально в радость, это акт творения, причем один из самых простых в реализации, потому что бороться с ограничениями физического мира для него не нужно), радость от решения проблемы (офигеть, теперь вместо 20 минут в хекс-редакторе можно сделать то же самое за 20 секунд, и оно работает или также, или лучше, потому что программа меньше ошибается), радость от благодарности пользователей и повышения репутации и создания доброго имени ("ага, знаю этого чувака, он вообще крутой") - достаточные мотиваторы для многих людей, чтобы не требовать еще и денег.
Я не согласен с тем, что эти мы "плодим халявщиков", или "отнимаем поляну у кустарей", потому что халявщики таким же способом спиратили бы платное ПО, и при этом не вернули бы разработчикам вообще ничего (кроме, может быть, общедоступного кряка, чтобы остальным халявщикам удобнее стало). В опенсорсе же пользователи - это не только обуза, но и благо, потому что они предоставляют бесплатное тестирование, бесплатный фидбэк, а некоторые даже код сами правят и фичи сами реализовывают, становясь полноценными участниками проекта.
Короче, хотите денег - занимайтесь их зарабатыванием. Мне за опенсорс деньги не нужны, я им решаю для себя совсем другие задачи и массирую им совсем другую часть системы поощрения внутри головы. За деньги я работаю на корпорацию, которая намного лучше меня самого умеет монетизировать мой труд, а мне оставляет ту часть работы, от которой я получаю какое-то удовольствие (потому что это тоже акт творения, и тоже помогает пользователям), а всю остальную работу полностью берет на себя. Сделка вполне честная, на мой взгляд, а то, что она вредит "кустарям" - это так работает капитализм, разделение труда, специализация, найм профессионалов и так далее. Кустарям же от себя посоветую не на опенсорс злиться, а объединяться в собственные корпорации и конкурировать уже с другими такими же, на своей поляне. Там и денег сильно больше заработаете, если работать умеете, и опенсорс будет с вами на одной стороне баррикад, а не на разных.
Я когда свой проект стартовал в 2013 году, был на последнем курсе магистратуры, и деньги мне тогда были не нужны, нужны были прикладные знания и навыки в области Software Engineering и Software Development, которые я и пошел получать и тренировать наилучшим, на мой тогдашний взгляд, способом. При этом и процесс, и результат этого труда были нужны именно мне (я тогда занимался модификацией UEFI-совместимых прошивок в качестве хобби), а альтернатив хороших, кросс-платформенных, с открытым кодом и графическим интерфейсом тогда не было.
В итоге получилось и свой C и C++/Qt улучшить заметно, и проблему достаточно эффективно решить, и научиться не только программированию, но и сопровождению, и заиметь определенную репутацию в своих узких кругах, благодаря которой получилось устроиться и на первую серьезную работу (разработчиком прошивок), а затем и в мегакорпорацию (специалистом по безопасности эти самых).
Если бы я заранее рассчитывал на монетизацию этого проекта, то не стал бы за него садиться, потому что у среднего пользователя нет денег на такую ерунду, а имеющиеся альтернативы (PhoenixTool, например) уже тогда были и бесплатными, и работоспособными, а из недостатков имели только закрытый код и привязанность к .Net 3 (т.е. к Windows).
Более того, товарно-денежные отношения для подавляющего большинства людей подразумевают (хотя бы частичную) передачу контроля на проектными решениями и приоритетами, т.е. задачей разработчика становится "делать пользователю зашибись". У меня такой задачи нет, и я делаю зашибись в первую очередь себе самому, а пользователям хотя и очень рад (они, например, тестируют твой софт на конфигурациях, которые ты сам у себя в подвале гарантированно собирать не станешь), но ничего не должен. И донаты не беру по этой же примерно причине.
Корпорации, кстати, это тоже хорошие пользователи, и то, что они каким-то образом делают на моем коде деньги - да на здоровье, я бы эти деньги все равно не сделал, потому что не желаю смешивать работу за деньги с работой для души. Уважение коллег заработал - отлично, пользователи сказали "спасибо" - замечательно, попал в десятку лучших в мире специалистов по разбору UEFI-совместимых прошивок на составные части, потому что за 10 лет работы над их разбором насмотрелся на любые и всякие - тоже хорошо, теперь эту специализацию можно продать тем, кому она для чего-то нужна.
Абсолютно уверен, что если бы я вместо опенсорса и работы с сообществом написал бы какой-нибудь UEFITool PRO и попытался его продать, заработал бы сейчас значительно меньше, если что-либо вообще. А так и с деньгами проблем больше нет, и проект стал стандартом де-факто в своей микроскопической нише. Понятно, что это все результат скорее случайных процессов и удачных таймингов, и потому может быть проигнорировано как "ошибка выжившего", но получилось как получилось, и мне нравится этот результат.
Советы неплохие, но начинаются с середины, и еще сильно до того, как идти выбирать лицензию и т.д. по тексту, нужно для себя прояснить очень хорошо примерно следующее: - какую именно проблему решает проект, является ли эта проблема реальной, нужно ли решение лично вам как автору, и кому еще это решение может пригодиться - какие имеются альтернативы и в чем их фатальные недостатки, из за которых именно вам нужно решать проблему заново, и не будет ли лучше присоединиться к разработке уже существующего проекта, а не садиться за написание нового - сколько у вас ресурсов и сможете ли вы тратить главный невосполнимый ресурс (время вашей жизни) не только на fun-части проекта (написание кода, решение проблемы, прием благодарностей и донатов), но и на slog-части (настройка и отладка сборочной системы, тестирование, создание и поддержка CI/CD-пайплайна, общение с пользователями, разгребание сообщений об ошибках, фич- и пулл-реквестов и т.п.). - ожидаете ли вы роста пользовательской базы, и если да, то готовы ли к тому, что проект станет отнимать значительно больше ресурсов, чем в начале? - готовы ли вы к конфликтам, форкам, драме, оскорблениям, необоснованным требованиям по немедленной доставке фич, немедленному исправлению багов, немедленной реакции на инциденты, потенциальным проблемам с патентами, адвокатами, письмами cease and desist, DMCA-тейкдаунами, GDPR-совместимостью, бану вашей юрисдикции гитхабом, неадекватам всех сортов и мастей, и прочим прелестям взаимодействия с большой группой бездельников в интернете?
Если ко всему готовы и все для себя решили - могу только порадоваться за вас, добро пожаловать, коллега. Постараюсь воспользоваться результатами вашего альтруизма и вашим весомым вкладом в будущее человеческой цивилизации. Искреннее больше спасибо. Если не готовы и не решили - тоже спасибо, меньше разочарованных авторов и мейнтейнеров. Попробуйте себя в чем-нибудь другом.
Продолжайте переходить на личности, обсуждать мою типичность, растовость и выдуманную "безопасность". Общаться с вами не намерен, искать вам примеры проблем безопасности, вызванные C++ UB тоже. Ступайте своей дорогой.
Пока что, к сожалению, кроме переставления кроватей никаких других вариантов нет, как и "других писателей", так что переставлять в любом случае приходится, так или иначе. Выиграет ли от этого бордель - будем посмотреть, пока что выигрывает, по крайней мере из моего погреба видится именно так.
Ну и если уж говорить конкретно про UEFI и другие популярные продукты похожего уровня, то большая часть серьезных эксплуатируемых проблем с ними за последние 5 лет - это именно "детские" проблемы C-подобных языков: - Intel ME 11.x INTEL-SA-00086 - переполнение стека при чтении файла с MFS. - UEFI BootHole - переполнение кучи в GRUB при чтении конфигурационного файла, потому что в результате ручной проверки на это переполнение было только сообщение в лог. - UEFI LogoFail - переполнение кучи и чтение за пределами буфера в парсерах изображений. - Apple iBoot checkm8 - use-after-free в драйвере USB DFU.
Ошибок в логике тоже было море, и я ни в коем случае не пытаюсь тут сказать, что от использования более современных "безопасных" ЯП они все исчезнут, как по волшебству, и разработчики на них неожиданно перестанут быть людьми и делать ошибки. Не перестанут, конечно, но удаление целых классов ошибок из списка вероятных (а с ростом кодовой базы эта вероятность быстро приближается к 100%) - это несомненное благо, с какой стороны не смотри.
У меня с тех пор много воды утекло, и я насмотрелся на нынешнем месте работы уже именно на проблемы, вызванные непосредственно недостатками С и C++, а точнее сочетанием необходимости сохранять нечеловеческий уровень концентрации для написания на них безопасного работающего кода с крупномасштабной потоковой разработкой, 500 пулл-реквестами в сутки, очень разным уровнем разработчиков и т.п. Не могу сказать, что у меня есть примеры кодовых баз похожего размера и активности на более новых "безопасных" языках, но пока что решительно все попытки замены C и C++ на FireBloom и embedded Swift, в которых я участвовал и с которыми имел дело, показывают однозначное улучшение по большинству метрик, особенно по количеству эксплуатируемых проблем с памятью, состояний гонок, и самодеятельностей компилятора. При этом внедрение это - крайне недешевое во всех смыслах мероприятие, идущее тем не менее полным ходом.
Мне, честно сказать, давно уже ультрафиолетовы конкретные инструменты, потому что мне необходимо уметь пользоваться любыми. В данном случае я вижу, что ничего, буквально ничего, не спасает большие проекты на С и С++ от "решета", и потому я уже давно пришел к тому, чтобы не начинать новых проектов на ЯП, доказавших практикой собственную ограниченность у всех участников индустрии. Лошадь сдохла - слезь.
Стоило, я думаю, написать об этом в предисловии, вместо "выбор языка программирования для нашего приложения был очевиден". Ну и в действительно любую кофеварку лучше получилось бы внедрить подмножество C99, а не C++17, если уж выбирать и по этому критерию тоже. И разработчики были бы еще дешевле, и тулинг весь или тот же самый, или лучше.
Я искренне желаю вам удачи, и надеюсь, что C++ не станет для вас "чемоданом без ручки" в тот момент, когда ваша кодовая база перерастет 10М строк, из проекта уволятся его оригинальные разработчики, и прошивка накопит достаточно мертвого кода, чтобы перестать влезать на кофеварки. Пока что мой собственный опыт показывает, что писать хороший поддерживаемый низкоуровневый продолжительно работающий код на С++ не умеет примерно никто. Язык банально слишком сложный для и так уже весьма непростой предметной области, вариантов выстрелить себе в лицо слишком много, и оптимизирующий компилятор слишком много на себя берет.
Overall, despite these challenges and limitations, we’ve still found Rust to be a significant improvement over C (or C++), both in terms of safety and productivity, in all the bare-metal use cases where we’ve tried it so far. We plan to use it wherever practical. (Google Security Blog)
Хорошая статья и подходы верные, только вот с выбором C++ все равно согласиться не могу, потому что вы тратите кучу ресурсов на борьбу с его недостатками, и при этом никаких его преимуществ, кроме, возможно, большего количества профессиональных разработчиков на локальном рынке, и "проверенности временем", не используете.
У вас нет интеропа с непонятным легаси-кодом на С, у вас нет существующей кодовой базы на миллионы строк, у вас нет экзотических архитектур, сумасшедших требований к производительности, отказоустойчивости, безопасности (security), безопасности (safety) и т.д.
Посмотрите на TamaGo, на Embedded Rust, на SPARK и прочие альтернативы. Я понимаю, что вы не стартап, а корпорация, но подход "мы обвесим C или C++ достаточным количеством тулинга, и он станет нормальным" - не работает. Он не работает у Microsoft, он не работает у Google, он не работает у Apple, и у вас он тоже не заработает. Чем раньше вы (и ваш менеджмент) это поймете, тем меньше у меня, инженера по обеспечению безопасности прошивок, будет новой работы. Жаль только жить в эту пору прекрасную...
На работе стараюсь и сам не писать говна, и не допускать говна к интеграции. Дома в свободное время пишу свободное ПО для души и вечности, самостоятельно управляя его качеством.
Не могу сказать, что прямо смирился полностью (не писал бы сюда ничего, если бы смирился), но пока что на качество результата никто не жаловался, и в основном хвалят, что на работе, что вне работы. Корпорация компенсирует свои хотелки деньгами, сообщество - признанием и уважением коллег.
У меня нет никаких претензий к написанию достаточно качественного ПО доступными средствами, пока это ПО и мы сами находимся на одной стороне баррикад с пользователями этого ПО, и оба стремимся к общей цели.
Проблема же именно капитализма в том, что цель любой деятельности в нем - это получение прибыли, и не слишком важно, от кого эта прибыль получается, каким способом, насколько этот способ этичен, морален, человечен, эксплуатирует ли он самые животные потребности, использует ли "баги в прошивке" пользователей, и т.п. Там, где критерием успеха становится получение прибыли любой ценой, больше нет места заботе о пользователе, заботе о поставщике, заботе об окружающей среде, сохранению гомеостаза с остальной жизнью на планете, и т.п.
В результате действий "рациональных экономических агентов" уже сейчас большая часть ПО специально написана так, чтобы максимально затруднить его замену при наличии альтернатив, максимально привязать существующих пользователей к "платформе", максимально привязать денежные потоки к той же "платформе", использовать исключительно подписочную модель, запускать основную часть ПО исключительно у себя в облаке, чтобы пользователь не мог изучить ее или как-либо взаимодействовать с ней, решительно запретить изучение, декомпиляцию, дизассемблирование, обратную разработку, используя для этого любые инструменты, как программно-аппаратные, так и легально-маркетинговые, зачастую нанося прямой ущерб потребительским качествам собственного ПО.
Эпоха shareware закончилась, и вместо нее наступила эпоха платформ, в которой пользователь не владеет ничем, и вынужден платить постоянно, и теряет доступ к любой "купленной" продукции по мановению руки "правообладателя".
Над "потребности пользователя увеличиваются" работает нынче больше людей, чем собственно над ПО, закрывающим текущие потребности пользователей. Примерно 90% этих "потребностей" пользователю успешно навязаны извне, причем для этого используются самые грязные психологические трюки, FOMO, торговля "стилем жизни" и прочие эффективные приемы заставить пользователя в очередной раз купить продукт.
Новое значит лучшее, купи самый новый гаджет, а то будешь ходить со старым, как лох и нищеброд... Пацаны не поймут, девчонки отвернутся, покупай скорее, чего стоишь?! Вырази свою яркую индивидуальность при помощи цвета чехла и формы накладок на зеркала! Выделись из серой массы покупкой массового продукта! Ты этого достойна!
Пока что бизнес вокруг меня делает именно так, а тот, который не делает - либо очень нишевый, либо уже загнулся. Sun Microsystems вон делали хорошо - где они теперь? VmWare вон тоже неплохо делали, а теперь их купил бизнес побольше, и немедленно прекратил продажи бессрочных лицензий. Пользователь приучен этим же бизнесом к тому, что если продуктовая линейка не обновляется каждые полгода-год, значит производитель уже умер, потому что новое всегда лучше, чем такое же, только 200-400 дней назад. При этом тотальная эншитификация всего подряд - это, с точки зрения бизнеса, не просто отлично, а буквально необходимо, Diablo Immortal не даст соврать.
В производстве действительно качественного ПО самым главным механизмом обеспечения качества является не QA, и не TDD, и не прочие аббревиатуры, а предельно ясное понимание всеми участниками производства двух вещей: - что именно производится - каковы критерии успеха
Подавляющая часть современного ПО не производится, она выращивается из прототипов, которые затем переписываются на ходу, без какого-либо четкого плана, без критериев приемки, и без какой-либо цели кроме "может быть вот эта новая фича сделает еще полтора пользователя немного счастливее" или "может быть вот эта новая фича наконец приведет к повышению по карьерной лестнице". Фичи добавляются ради самих фич, разработка ведется ради самой разработки, каждые полгода меняется дизайн, все делается для удержания внимания пользователя, а не для решения его задач. И это все - неизбежно, потому что это приносит больше прибыли, и потому неизбежно задавит все альтернативы даже в самых зарегулированных нишах вроде автомобилестроения и авиации.
ПО - это не продукт, а сервис, и потому делать его законченным, цельным, отлаженным, быстрым, т.п. - не выгодно, потому что его купят один раз и будут пользоваться в таком виде. Поэтому жизненно необходимо выпускать новые версии, менять дизайн, добавлять фич, даже если продукт давно уже не просто "готов", а "трижды пережеван".
Всю эту индустрию, как и практически все остальные, пожирает один и тот же рак по имени "капитализм", и "нас не учили писать качественное ПО" - это потому, что никому не нужно качественное ПО, его очень дорого делать и оно никогда не принесет столько денег, сколько приносит некачественное ПО, которое получилось выпустить на рынок на полгода раньше, прорекламировать лучше, всучить хитрее, внедрить глубже и т.п. Некачественное ПО - это не вина исполнителей, это прямой результат того, что скорость доставки изменений (без лишних вопросов о том, если ли какой-то смысл в этих изменениях) - это главный критерий успеха.
Подход "move fast and break things" Цукерберга уже давно сожрал рынок ПО заживо, а вместо Computer Science и Software Engineering у нас теперь в основном Software Development и Continuous Delivery/Integration.
Очень мало в каких странах прогрессивный налог на Long Term Capital Gain, и в таких на пенсии можно не жить. Более того, достаточно много стран (из европейских можно выделить Кипр и Мальту), где этого налога нет вообще, и потому платить придется только налог у источника в США (в случае с Кипром и Мальтой - 15%).
Если не выпадать из статуса US person (т.е. либо жить внутри США как resident alien, либо получить ВНЖ или гражданство), необлагаемый порог estate tax составляет почти $13M, т.е. в принципе проблемой не является почти ни для кого.
Если из статуса все же выпадать (потому что каждый год налоги американские оформлять грустно, или санкции не хочется исполнять, или еще что) - отлично работает открытие trust-фонда.
Если вам искренне нравится ваша работа/бизнес/ремесло, то можно сохранять источник активного дохода сильно дольше. Тогда момент выхода на пенсию получится строить не от “мне нужно Х денег для выхода на пенсию”, а от “когда активный доход будет увеличивать капитал меньше чем на Y%, то я больше не буду работать”. Лично мне такое число ощутить гораздо проще.
Еще лучше перестроить оба эти утверждения следующим образом: "каждые дополнительные 350к долларов на американской фондовой бирже - это в среднем дополнительная тысяча долларов в месяц до конца жизни", и дальше уже смотреть, сколько вам нужно, 5к в месяц, или 10к, или 20к, или 50к, и от этого плясать уже. Это получается примерно "правило 3%", т.е достаточно безопасно, если про слишком черных лебедей не думать.
К сожалению (или к счастью) мы живем в глобальном мире глобального рынка, а РФ на текущий момент не производит в полном цикле практически ничего, что нужно было бы (раннему) пенсионеру. Внутри еды заложен импортный семенной материал и техника, внутри промышленной продукции - импортные технологии и станки, внутри лекарств - импортные технологии и сырье, и т.п.
Все эти импортные вещи торгуются за доллар и юань, поэтому "долгосрочные цели в рублях" - это очень странный предмет, он вроде есть - оп, и его уже нет. В фиате вообще странно хранить деньги (это средство обмена, а не накопления), но ставить долгосрочные цели в слабой нестабильной валюте - это опять же огромный риск, никак не покрывающий упомянутые вами.
Нужно еще добавить, что подобные ПИФы на развивающихся рынках (а рынок РФ - именно такой) хоть и приносят относительно высокую доходность, но при этом имеют очень значительный системный риск, связанный и с особенностями рынка, и с курсом локальной валюты, и с политическим климатом, и с постоянно меняющимися правилами. Эти 9-10% - это в рублях с непонятным (т.е. "очень надеемся, что работающим") хеджированием инфляции и непонятными страховыми перспективами. Если вот это называть надежным, то что тогда ненадежное...
Есть относительно надежный способ получать около 3-6%, но не в виде конкретно дивидендов (потому что они генерируют налоговые события, и этим зачастую неудобны) - широкие пассивные индексные фонды, либо американские (но тогда лучше иметь американское же налоговое резидентство, чтобы не попасть под налоги неприятные, или, в крайнем случае, жить в стране с низкими процентами по dual taxation treaty, вроде Болгарии), либо ирландские (в них уже учтены американские налоги на дивиденды и интерес в 15%, и можно взять накапливающий вариант того же фонда вместо распределяющего). У меня самого сейчас весь портфель сделан из VTSAX (основной источник премии за риск), VBTLX (хедж на случай сильного падения рынка акций) и AAPL (надо продать, но налоги пока слишком высокие, жду возможности оптимизации). Если налоговое резидентство США получить не вариант, можно купить у любого европейского брокера те же самые широкие фонды, только с ирландским домицилем (VEVE и аналоги, justETF поможет выбрать).
Вообще, на BoggleHeads Wiki есть отличный набор статей, советую почитать их все.
С российскими брокерами и ПИФами посоветую не связываться, даже без учета всех нынешних проблем с санкциями, потому что у них совершенно сумасшедшие комиссии (1% и выше). Максимум - дальнейшая диверсификация в собственный портфель из местных акций и облигаций, с оплатой самому себе за управление портфелем, но это уже не пассивный доход, а полу-пассивный, потому что работать над ребалансировкой придется все равно.
Скорее всего, пытаются успеть занять освободившуюся нишу как можно быстрее, а затем уже думать, как монетизировать доработки под конкретных корпоративных пользователей, продавать плагины, поддержку и т.п. Если сразу делать фремиум - пользователи могут уйти к опенсорсным конкурентам, и потому занять нишу не получится.
Радость от программирования (а оно реально в радость, это акт творения, причем один из самых простых в реализации, потому что бороться с ограничениями физического мира для него не нужно), радость от решения проблемы (офигеть, теперь вместо 20 минут в хекс-редакторе можно сделать то же самое за 20 секунд, и оно работает или также, или лучше, потому что программа меньше ошибается), радость от благодарности пользователей и повышения репутации и создания доброго имени ("ага, знаю этого чувака, он вообще крутой") - достаточные мотиваторы для многих людей, чтобы не требовать еще и денег.
Я не согласен с тем, что эти мы "плодим халявщиков", или "отнимаем поляну у кустарей", потому что халявщики таким же способом спиратили бы платное ПО, и при этом не вернули бы разработчикам вообще ничего (кроме, может быть, общедоступного кряка, чтобы остальным халявщикам удобнее стало). В опенсорсе же пользователи - это не только обуза, но и благо, потому что они предоставляют бесплатное тестирование, бесплатный фидбэк, а некоторые даже код сами правят и фичи сами реализовывают, становясь полноценными участниками проекта.
Короче, хотите денег - занимайтесь их зарабатыванием. Мне за опенсорс деньги не нужны, я им решаю для себя совсем другие задачи и массирую им совсем другую часть системы поощрения внутри головы. За деньги я работаю на корпорацию, которая намного лучше меня самого умеет монетизировать мой труд, а мне оставляет ту часть работы, от которой я получаю какое-то удовольствие (потому что это тоже акт творения, и тоже помогает пользователям), а всю остальную работу полностью берет на себя. Сделка вполне честная, на мой взгляд, а то, что она вредит "кустарям" - это так работает капитализм, разделение труда, специализация, найм профессионалов и так далее. Кустарям же от себя посоветую не на опенсорс злиться, а объединяться в собственные корпорации и конкурировать уже с другими такими же, на своей поляне. Там и денег сильно больше заработаете, если работать умеете, и опенсорс будет с вами на одной стороне баррикад, а не на разных.
Just for fun, конечно.
Я когда свой проект стартовал в 2013 году, был на последнем курсе магистратуры, и деньги мне тогда были не нужны, нужны были прикладные знания и навыки в области Software Engineering и Software Development, которые я и пошел получать и тренировать наилучшим, на мой тогдашний взгляд, способом. При этом и процесс, и результат этого труда были нужны именно мне (я тогда занимался модификацией UEFI-совместимых прошивок в качестве хобби), а альтернатив хороших, кросс-платформенных, с открытым кодом и графическим интерфейсом тогда не было.
В итоге получилось и свой C и C++/Qt улучшить заметно, и проблему достаточно эффективно решить, и научиться не только программированию, но и сопровождению, и заиметь определенную репутацию в своих узких кругах, благодаря которой получилось устроиться и на первую серьезную работу (разработчиком прошивок), а затем и в мегакорпорацию (специалистом по безопасности эти самых).
Если бы я заранее рассчитывал на монетизацию этого проекта, то не стал бы за него садиться, потому что у среднего пользователя нет денег на такую ерунду, а имеющиеся альтернативы (PhoenixTool, например) уже тогда были и бесплатными, и работоспособными, а из недостатков имели только закрытый код и привязанность к .Net 3 (т.е. к Windows).
Более того, товарно-денежные отношения для подавляющего большинства людей подразумевают (хотя бы частичную) передачу контроля на проектными решениями и приоритетами, т.е. задачей разработчика становится "делать пользователю зашибись". У меня такой задачи нет, и я делаю зашибись в первую очередь себе самому, а пользователям хотя и очень рад (они, например, тестируют твой софт на конфигурациях, которые ты сам у себя в подвале гарантированно собирать не станешь), но ничего не должен. И донаты не беру по этой же примерно причине.
Корпорации, кстати, это тоже хорошие пользователи, и то, что они каким-то образом делают на моем коде деньги - да на здоровье, я бы эти деньги все равно не сделал, потому что не желаю смешивать работу за деньги с работой для души. Уважение коллег заработал - отлично, пользователи сказали "спасибо" - замечательно, попал в десятку лучших в мире специалистов по разбору UEFI-совместимых прошивок на составные части, потому что за 10 лет работы над их разбором насмотрелся на любые и всякие - тоже хорошо, теперь эту специализацию можно продать тем, кому она для чего-то нужна.
Абсолютно уверен, что если бы я вместо опенсорса и работы с сообществом написал бы какой-нибудь UEFITool PRO и попытался его продать, заработал бы сейчас значительно меньше, если что-либо вообще. А так и с деньгами проблем больше нет, и проект стал стандартом де-факто в своей микроскопической нише. Понятно, что это все результат скорее случайных процессов и удачных таймингов, и потому может быть проигнорировано как "ошибка выжившего", но получилось как получилось, и мне нравится этот результат.
Советы неплохие, но начинаются с середины, и еще сильно до того, как идти выбирать лицензию и т.д. по тексту, нужно для себя прояснить очень хорошо примерно следующее:
- какую именно проблему решает проект, является ли эта проблема реальной, нужно ли решение лично вам как автору, и кому еще это решение может пригодиться
- какие имеются альтернативы и в чем их фатальные недостатки, из за которых именно вам нужно решать проблему заново, и не будет ли лучше присоединиться к разработке уже существующего проекта, а не садиться за написание нового
- сколько у вас ресурсов и сможете ли вы тратить главный невосполнимый ресурс (время вашей жизни) не только на fun-части проекта (написание кода, решение проблемы, прием благодарностей и донатов), но и на slog-части (настройка и отладка сборочной системы, тестирование, создание и поддержка CI/CD-пайплайна, общение с пользователями, разгребание сообщений об ошибках, фич- и пулл-реквестов и т.п.).
- ожидаете ли вы роста пользовательской базы, и если да, то готовы ли к тому, что проект станет отнимать значительно больше ресурсов, чем в начале?
- готовы ли вы к конфликтам, форкам, драме, оскорблениям, необоснованным требованиям по немедленной доставке фич, немедленному исправлению багов, немедленной реакции на инциденты, потенциальным проблемам с патентами, адвокатами, письмами cease and desist, DMCA-тейкдаунами, GDPR-совместимостью, бану вашей юрисдикции гитхабом, неадекватам всех сортов и мастей, и прочим прелестям взаимодействия с большой группой бездельников в интернете?
Если ко всему готовы и все для себя решили - могу только порадоваться за вас, добро пожаловать, коллега. Постараюсь воспользоваться результатами вашего альтруизма и вашим весомым вкладом в будущее человеческой цивилизации. Искреннее больше спасибо.
Если не готовы и не решили - тоже спасибо, меньше разочарованных авторов и мейнтейнеров. Попробуйте себя в чем-нибудь другом.
Продолжайте переходить на личности, обсуждать мою типичность, растовость и выдуманную "безопасность". Общаться с вами не намерен, искать вам примеры проблем безопасности, вызванные C++ UB тоже. Ступайте своей дорогой.
Пока что, к сожалению, кроме переставления кроватей никаких других вариантов нет, как и "других писателей", так что переставлять в любом случае приходится, так или иначе. Выиграет ли от этого бордель - будем посмотреть, пока что выигрывает, по крайней мере из моего погреба видится именно так.
Ну и если уж говорить конкретно про UEFI и другие популярные продукты похожего уровня, то большая часть серьезных эксплуатируемых проблем с ними за последние 5 лет - это именно "детские" проблемы C-подобных языков:
- Intel ME 11.x INTEL-SA-00086 - переполнение стека при чтении файла с MFS.
- UEFI BootHole - переполнение кучи в GRUB при чтении конфигурационного файла, потому что в результате ручной проверки на это переполнение было только сообщение в лог.
- UEFI LogoFail - переполнение кучи и чтение за пределами буфера в парсерах изображений.
- Apple iBoot checkm8 - use-after-free в драйвере USB DFU.
Ошибок в логике тоже было море, и я ни в коем случае не пытаюсь тут сказать, что от использования более современных "безопасных" ЯП они все исчезнут, как по волшебству, и разработчики на них неожиданно перестанут быть людьми и делать ошибки. Не перестанут, конечно, но удаление целых классов ошибок из списка вероятных (а с ростом кодовой базы эта вероятность быстро приближается к 100%) - это несомненное благо, с какой стороны не смотри.
У меня с тех пор много воды утекло, и я насмотрелся на нынешнем месте работы уже именно на проблемы, вызванные непосредственно недостатками С и C++, а точнее сочетанием необходимости сохранять нечеловеческий уровень концентрации для написания на них безопасного работающего кода с крупномасштабной потоковой разработкой, 500 пулл-реквестами в сутки, очень разным уровнем разработчиков и т.п. Не могу сказать, что у меня есть примеры кодовых баз похожего размера и активности на более новых "безопасных" языках, но пока что решительно все попытки замены C и C++ на FireBloom и embedded Swift, в которых я участвовал и с которыми имел дело, показывают однозначное улучшение по большинству метрик, особенно по количеству эксплуатируемых проблем с памятью, состояний гонок, и самодеятельностей компилятора. При этом внедрение это - крайне недешевое во всех смыслах мероприятие, идущее тем не менее полным ходом.
Мне, честно сказать, давно уже ультрафиолетовы конкретные инструменты, потому что мне необходимо уметь пользоваться любыми. В данном случае я вижу, что ничего, буквально ничего, не спасает большие проекты на С и С++ от "решета", и потому я уже давно пришел к тому, чтобы не начинать новых проектов на ЯП, доказавших практикой собственную ограниченность у всех участников индустрии. Лошадь сдохла - слезь.
Стоило, я думаю, написать об этом в предисловии, вместо "выбор языка программирования для нашего приложения был очевиден". Ну и в действительно любую кофеварку лучше получилось бы внедрить подмножество C99, а не C++17, если уж выбирать и по этому критерию тоже. И разработчики были бы еще дешевле, и тулинг весь или тот же самый, или лучше.
Я искренне желаю вам удачи, и надеюсь, что C++ не станет для вас "чемоданом без ручки" в тот момент, когда ваша кодовая база перерастет 10М строк, из проекта уволятся его оригинальные разработчики, и прошивка накопит достаточно мертвого кода, чтобы перестать влезать на кофеварки. Пока что мой собственный опыт показывает, что писать хороший поддерживаемый низкоуровневый продолжительно работающий код на С++ не умеет примерно никто. Язык банально слишком сложный для и так уже весьма непростой предметной области, вариантов выстрелить себе в лицо слишком много, и оптимизирующий компилятор слишком много на себя берет.
Не могу сказать, что более современные альтернативы лишены всех этих недостатков, или не имеют собственных новых, но не замечать того, что практически все вокруг люди, команды и компании уже начали перевод своих прошивок и ОС с С-подобных языков на более современные и безопасные, я не могу. Nvidia переходит на SPARK, Microsoft переходит на Rust, Ядро Linux добавляет экспериментальную Rust-подсистему, Google начинает использование Rust в Android, имя им легион.
Хорошая статья и подходы верные, только вот с выбором C++ все равно согласиться не могу, потому что вы тратите кучу ресурсов на борьбу с его недостатками, и при этом никаких его преимуществ, кроме, возможно, большего количества профессиональных разработчиков на локальном рынке, и "проверенности временем", не используете.
У вас нет интеропа с непонятным легаси-кодом на С, у вас нет существующей кодовой базы на миллионы строк, у вас нет экзотических архитектур, сумасшедших требований к производительности, отказоустойчивости, безопасности (security), безопасности (safety) и т.д.
Посмотрите на TamaGo, на Embedded Rust, на SPARK и прочие альтернативы. Я понимаю, что вы не стартап, а корпорация, но подход "мы обвесим C или C++ достаточным количеством тулинга, и он станет нормальным" - не работает. Он не работает у Microsoft, он не работает у Google, он не работает у Apple, и у вас он тоже не заработает. Чем раньше вы (и ваш менеджмент) это поймете, тем меньше у меня, инженера по обеспечению безопасности прошивок, будет новой работы. Жаль только жить в эту пору прекрасную...
На работе стараюсь и сам не писать говна, и не допускать говна к интеграции. Дома в свободное время пишу свободное ПО для души и вечности, самостоятельно управляя его качеством.
Не могу сказать, что прямо смирился полностью (не писал бы сюда ничего, если бы смирился), но пока что на качество результата никто не жаловался, и в основном хвалят, что на работе, что вне работы. Корпорация компенсирует свои хотелки деньгами, сообщество - признанием и уважением коллег.
У меня нет никаких претензий к написанию достаточно качественного ПО доступными средствами, пока это ПО и мы сами находимся на одной стороне баррикад с пользователями этого ПО, и оба стремимся к общей цели.
Проблема же именно капитализма в том, что цель любой деятельности в нем - это получение прибыли, и не слишком важно, от кого эта прибыль получается, каким способом, насколько этот способ этичен, морален, человечен, эксплуатирует ли он самые животные потребности, использует ли "баги в прошивке" пользователей, и т.п. Там, где критерием успеха становится получение прибыли любой ценой, больше нет места заботе о пользователе, заботе о поставщике, заботе об окружающей среде, сохранению гомеостаза с остальной жизнью на планете, и т.п.
В результате действий "рациональных экономических агентов" уже сейчас большая часть ПО специально написана так, чтобы максимально затруднить его замену при наличии альтернатив, максимально привязать существующих пользователей к "платформе", максимально привязать денежные потоки к той же "платформе", использовать исключительно подписочную модель, запускать основную часть ПО исключительно у себя в облаке, чтобы пользователь не мог изучить ее или как-либо взаимодействовать с ней, решительно запретить изучение, декомпиляцию, дизассемблирование, обратную разработку, используя для этого любые инструменты, как программно-аппаратные, так и легально-маркетинговые, зачастую нанося прямой ущерб потребительским качествам собственного ПО.
Эпоха shareware закончилась, и вместо нее наступила эпоха платформ, в которой пользователь не владеет ничем, и вынужден платить постоянно, и теряет доступ к любой "купленной" продукции по мановению руки "правообладателя".
Над "потребности пользователя увеличиваются" работает нынче больше людей, чем собственно над ПО, закрывающим текущие потребности пользователей. Примерно 90% этих "потребностей" пользователю успешно навязаны извне, причем для этого используются самые грязные психологические трюки, FOMO, торговля "стилем жизни" и прочие эффективные приемы заставить пользователя в очередной раз купить продукт.
Новое значит лучшее, купи самый новый гаджет, а то будешь ходить со старым, как лох и нищеброд... Пацаны не поймут, девчонки отвернутся, покупай скорее, чего стоишь?! Вырази свою яркую индивидуальность при помощи цвета чехла и формы накладок на зеркала! Выделись из серой массы покупкой массового продукта! Ты этого достойна!
Пока что бизнес вокруг меня делает именно так, а тот, который не делает - либо очень нишевый, либо уже загнулся. Sun Microsystems вон делали хорошо - где они теперь? VmWare вон тоже неплохо делали, а теперь их купил бизнес побольше, и немедленно прекратил продажи бессрочных лицензий. Пользователь приучен этим же бизнесом к тому, что если продуктовая линейка не обновляется каждые полгода-год, значит производитель уже умер, потому что новое всегда лучше, чем такое же, только 200-400 дней назад. При этом тотальная эншитификация всего подряд - это, с точки зрения бизнеса, не просто отлично, а буквально необходимо, Diablo Immortal не даст соврать.
В производстве действительно качественного ПО самым главным механизмом обеспечения качества является не QA, и не TDD, и не прочие аббревиатуры, а предельно ясное понимание всеми участниками производства двух вещей:
- что именно производится
- каковы критерии успеха
Подавляющая часть современного ПО не производится, она выращивается из прототипов, которые затем переписываются на ходу, без какого-либо четкого плана, без критериев приемки, и без какой-либо цели кроме "может быть вот эта новая фича сделает еще полтора пользователя немного счастливее" или "может быть вот эта новая фича наконец приведет к повышению по карьерной лестнице". Фичи добавляются ради самих фич, разработка ведется ради самой разработки, каждые полгода меняется дизайн, все делается для удержания внимания пользователя, а не для решения его задач. И это все - неизбежно, потому что это приносит больше прибыли, и потому неизбежно задавит все альтернативы даже в самых зарегулированных нишах вроде автомобилестроения и авиации.
ПО - это не продукт, а сервис, и потому делать его законченным, цельным, отлаженным, быстрым, т.п. - не выгодно, потому что его купят один раз и будут пользоваться в таком виде. Поэтому жизненно необходимо выпускать новые версии, менять дизайн, добавлять фич, даже если продукт давно уже не просто "готов", а "трижды пережеван".
Всю эту индустрию, как и практически все остальные, пожирает один и тот же рак по имени "капитализм", и "нас не учили писать качественное ПО" - это потому, что никому не нужно качественное ПО, его очень дорого делать и оно никогда не принесет столько денег, сколько приносит некачественное ПО, которое получилось выпустить на рынок на полгода раньше, прорекламировать лучше, всучить хитрее, внедрить глубже и т.п. Некачественное ПО - это не вина исполнителей, это прямой результат того, что скорость доставки изменений (без лишних вопросов о том, если ли какой-то смысл в этих изменениях) - это главный критерий успеха.
Подход "move fast and break things" Цукерберга уже давно сожрал рынок ПО заживо, а вместо Computer Science и Software Engineering у нас теперь в основном Software Development и Continuous Delivery/Integration.
Очень мало в каких странах прогрессивный налог на Long Term Capital Gain, и в таких на пенсии можно не жить. Более того, достаточно много стран (из европейских можно выделить Кипр и Мальту), где этого налога нет вообще, и потому платить придется только налог у источника в США (в случае с Кипром и Мальтой - 15%).
Если не выпадать из статуса US person (т.е. либо жить внутри США как resident alien, либо получить ВНЖ или гражданство), необлагаемый порог estate tax составляет почти $13M, т.е. в принципе проблемой не является почти ни для кого.
Если из статуса все же выпадать (потому что каждый год налоги американские оформлять грустно, или санкции не хочется исполнять, или еще что) - отлично работает открытие trust-фонда.
Еще лучше перестроить оба эти утверждения следующим образом: "каждые дополнительные 350к долларов на американской фондовой бирже - это в среднем дополнительная тысяча долларов в месяц до конца жизни", и дальше уже смотреть, сколько вам нужно, 5к в месяц, или 10к, или 20к, или 50к, и от этого плясать уже. Это получается примерно "правило 3%", т.е достаточно безопасно, если про слишком черных лебедей не думать.