Practice chapter + Conclusion complete

2026-02-24 14:32:46 +03:00 · 2026-02-24 14:32:46 +03:00 · acaef207c1
commit acaef207c1
parent 2db9216c5e
6 changed files with 777 additions and 198 deletions
--- a/bibliography.bib
+++ b/bibliography.bib
@ -1,44 +1,6 @@
-@report{linux_census3_2024,
-	title = {Census {III} of Free and Open Source Software — Application Libraries},
-	author = {Nagle, Frank and Powell, Kate and Zitomer, Richie and Wheeler, David A.},
-	year = {2024},
-	month = dec,
-	institution = {The Linux Foundation},
-	url = {https://www.linuxfoundation.org/hubfs/LF%20Research/lfr_censusiii_120424a.pdf},
-	urldate = {2025-02-25},
-	langid = {english},
-	note = {Отчёт подготовлен совместно с Harvard Business School}
-}
-
-@report{eu_report,
-	title = {Study about the impact of open source software and hardware on technological independence, competitiveness and innovation in the {EU} economy},
-	author = {{European Commission, Directorate-General for Communications Networks, Content and Technology}},
-	year = {2021},
-	publisher = {Publications Office of the European Union},
-	url = {https://digital-strategy.ec.europa.eu/en/library/study-about-impact-open-source-software-and-hardware-technological-independence-competitiveness-and},
-	urldate = {2025-02-27},
-	langid = {english},
-	note = {Final report. Luxembourg. DOI: 10.2759/430161}
-}
-
-@book{raymond_cathedral,
-	title = {The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary},
-	author = {Raymond, Eric S.},
-	year = {2001},
-	publisher = {O'Reilly \& Associates},
-	isbn = {978-0-596-00108-7},
-	langid = {russian}
-}
-
-@online{osi_definition_2024,
-	title = {The Open Source Definition},
-	author = {{Open Source Initiative}},
-	year = {2024},
-	url = {https://opensource.org/osd},
-	urldate = {2025-02-27},
-	note = {Последнее изменение: 16 февраля 2024 г.},
-	langid = {english}
-}
+%------------------------------------------------------------------------------
+% Официальные документы и стандарты
+%------------------------------------------------------------------------------

@standard{gost_19781_90,
 	title = {Обеспечение систем обработки информации программное. Термины и определения},
@ -50,49 +12,6 @@
 	pagetotal = {24}
 }

-@online{gnu_free_software_definition,
-	title = {The Free Software Definition},
-	author = {{Free Software Foundation}},
-	url = {https://www.gnu.org/philosophy/free-sw.html},
-	urldate = {2025-02-28},
-	year = {2024},
-	langid = {english},
-	note = {Определение свободного программного обеспечения от Free Software Foundation}
-}
-
-@online{stackoverflow_survey_2025,
-	title = {Stack Overflow Developer Survey 2025},
-	author = {{Stack Overflow}},
-	year = {2025},
-	url = {https://survey.stackoverflow.co/2025/},
-	urldate = {2025-02-28},
-	langid = {english},
-	note = {Ежегодный опрос разработчиков о технологиях, рабочих практиках и предпочтениях.}
-}
-
-@online{moedelo_amortizacia_2024,
-	author = {{Моё дело}},
-	title = {Амортизация компьютерной техники},
-	year = {2024},
-	url = {https://www.moedelo.org/club/buhgalterskij-uchet/amortizaciya-kompyuternoj-tekhniki},
-	urldate = {2024-08-10},
-	language = {russian},
-	note = {(Дата обращения: 10.08.2024)}
-}
-
-@online{cleverence_accelerated_amort_2024,
-	author = {Почепский, Олег},
-	title = {Ускоренная амортизация: когда применять и как рассчитать},
-	year = {2024},
-	month = {03},
-	day = {15},
-	organization = {Cleverence.ru},
-	url = {https://www.cleverence.ru/articles/bukhgalteriya/uskorennaya-amortizatsiya-kogda-primenyat-i-kak-rasschitat/},
-	urldate = {2024-03-15},
-	language = {russian},
-	note = {(Дата обращения: 15.03.2024)}
-}
-
@misc{nk_rf_259_3,
 	title = {Налоговый кодекс Российской Федерации (часть вторая). Глава 25. Статья 259.3. Применение повышающих (понижающих) коэффициентов к норме амортизации},
 	author = {{Российская Федерация}},
@ -132,6 +51,33 @@
 	language = {russian}
 }

+%------------------------------------------------------------------------------
+% Отчёты и исследования
+%------------------------------------------------------------------------------
+
+@report{linux_census3_2024,
+	title = {Census {III} of Free and Open Source Software — Application Libraries},
+	author = {Nagle, Frank and Powell, Kate and Zitomer, Richie and Wheeler, David A.},
+	year = {2024},
+	month = dec,
+	institution = {The Linux Foundation},
+	url = {https://www.linuxfoundation.org/hubfs/LF%20Research/lfr_censusiii_120424a.pdf},
+	urldate = {2025-02-25},
+	langid = {english},
+	note = {Отчёт подготовлен совместно с Harvard Business School}
+}
+
+@report{eu_report,
+	title = {Study about the impact of open source software and hardware on technological independence, competitiveness and innovation in the {EU} economy},
+	author = {{European Commission, Directorate-General for Communications Networks, Content and Technology}},
+	year = {2021},
+	publisher = {Publications Office of the European Union},
+	url = {https://digital-strategy.ec.europa.eu/en/library/study-about-impact-open-source-software-and-hardware-technological-independence-competitiveness-and},
+	urldate = {2025-02-27},
+	langid = {english},
+	note = {Final report. Luxembourg. DOI: 10.2759/430161}
+}
+
@report{hse_ict_2023,
 	author = {{НИУ ВШЭ, Институт статистических исследований и экономики знаний}},
 	title = {Российский сектор ИКТ: ключевые показатели. Январь-сентябрь 2023. Квартальный дайджест на основе официальной статистической информации},
@ -143,15 +89,17 @@
 	note = {DOI: 10.17323/ICT\_Sector\_2023\_I-IIIQ}
 }

-@book{isaev_upravl_uchet_2006,
-	author = {Исаев, Д. В. and Кравченко, Т. К.},
-	title = {Информационные технологии управленческого учета},
-	year = {2006},
-	address = {Москва},
-	publisher = {Государственный университет - Высшая школа экономики},
-	pagetotal = {291},
-	language = {russian},
-	url = {https://www.hse.ru/data/929/290/1238/%D0%98%D1%81%D0%B0%D0%B5%D0%B2%D0%94%D0%92%20-%20%D0%98%D0%A1%20%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B3%D0%BE%20%D1%83%D1%87%D0%B5%D1%82%D0%B0.pdf}
+%------------------------------------------------------------------------------
+% Книги и монографии
+%------------------------------------------------------------------------------
+
+@book{raymond_cathedral,
+	title = {The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary},
+	author = {Raymond, Eric S.},
+	year = {2001},
+	publisher = {O'Reilly \& Associates},
+	isbn = {978-0-596-00108-7},
+	langid = {english}
 }

@book{polyansky_ekonomika_2017,
@ -166,34 +114,453 @@
 	note = {Для подготовки бакалавров по направлению 09.03.04 «Программная инженерия».}
 }

+@book{isaev_upravl_uchet_2006,
+	author = {Исаев, Д. В. and Кравченко, Т. К.},
+	title = {Информационные технологии управленческого учета},
+	year = {2006},
+	address = {Москва},
+	publisher = {Государственный университет - Высшая школа экономики},
+	pagetotal = {291},
+	language = {russian},
+	url = {https://www.hse.ru/data/929/290/1238/%D0%98%D1%81%D0%B0%D0%B5%D0%B2%D0%94%D0%92%20-%20%D0%98%D0%A1%20%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B3%D0%BE%20%D1%83%D1%87%D0%B5%D1%82%D0%B0.pdf}
+}
+
+%------------------------------------------------------------------------------
+% Определения и философия Open Source
+%------------------------------------------------------------------------------
+
+@online{osi_definition_2024,
+	title = {The Open Source Definition},
+	author = {{Open Source Initiative}},
+	year = {2024},
+	url = {https://opensource.org/osd},
+	urldate = {2025-02-27},
+	note = {Последнее изменение: 16 февраля 2024 г.},
+	langid = {english}
+}
+
+@online{gnu_free_software_definition,
+	title = {The Free Software Definition},
+	author = {{Free Software Foundation}},
+	url = {https://www.gnu.org/philosophy/free-sw.html},
+	urldate = {2025-02-28},
+	year = {2024},
+	langid = {english}
+}
+
+@online{gnu_four_principles_philosophy,
+	title = {Four Principles of Free Software},
+	author = {{Free Software Foundation}},
+	url = {https://www.gnu.org/philosophy},
+	year = {2024},
+	langid = {english},
+	note = {4 принципа свободного программного обеспечения}
+}
+
+%------------------------------------------------------------------------------
+% Опросы и статистика
+%------------------------------------------------------------------------------
+
+@online{stackoverflow_survey_2025,
+	title = {Stack Overflow Developer Survey 2025},
+	author = {{Stack Overflow}},
+	year = {2025},
+	url = {https://survey.stackoverflow.co/2025/},
+	urldate = {2025-02-28},
+	langid = {english}
+}
+
+%------------------------------------------------------------------------------
+% Тренды Open Source 2025 (уникальные ключи)
+%------------------------------------------------------------------------------
+
+@misc{infoworld_2025,
+	author       = {{InfoWorld}},
+	title        = {Open source trends for 2025 and beyond},
+	year         = {2025},
+	url          = {https://www.infoworld.com/article/3800992/open-source-trends-for-2025-and-beyond.html},
+	urldate      = {2026-02-24}
+}
+
+@misc{thenewstack_2025,
+	author       = {{The New Stack}},
+	title        = {Open Source: Inside 2025's 4 Biggest Trends},
+	year         = {2025},
+	url          = {https://thenewstack.io/open-source-inside-2025s-4-biggest-trends/},
+	urldate      = {2026-02-24}
+}
+
+@misc{duckalignment_trends2025,
+	author       = {Duck Alignment Academy},
+	title        = {Open source trends 2025},
+	year         = {2025},
+	url          = {https://duckalignment.academy/open-source-trends-2025/},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Лицензирование
+%------------------------------------------------------------------------------
+
+@misc{snyk_licenses,
+	author       = {{Snyk}},
+	title        = {Open Source Licenses: Types and Comparison},
+	url          = {https://snyk.io/articles/open-source-licenses/},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Бизнес-модели (общие)
+%------------------------------------------------------------------------------
+
+@misc{palark_monetization,
+	author       = {Palark},
+	title        = {How companies make millions on Open Source},
+	url          = {https://palark.com/blog/open-source-business-models/},
+	urldate      = {2026-02-24}
+}
+
+@misc{wikipedia_business_models,
+	author       = {{Wikipedia}},
+	title        = {Business models for open-source software},
+	year         = {2026},
+	url          = {https://en.wikipedia.org/wiki/Business_models_for_open-source_software},
+	urldate      = {2026-02-24}
+}
+
+@misc{opencoreventures_building,
+	author       = {OpenCore Ventures},
+	title        = {Building venture-scale open core},
+	url          = {https://www.opencoreventures.com/blog/building-venture-scale-open-core/},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Модель профессиональных услуг и SLA
+%------------------------------------------------------------------------------
+
+@misc{openlogic_support,
+	author       = {{OpenLogic by Perforce}},
+	title        = {Open Source Support},
+	url          = {https://www.openlogic.com/products/support},
+	urldate      = {2026-02-24}
+}
+
+@misc{opensource_com_sle_sla,
+	author       = {Wade, Karsten},
+	title        = {A guide to SLEs and SLAs for open source projects},
+	year         = {2023},
+	url          = {https://opensource.com/article/23/2/sle-sla-open-source-projects},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Модель Open Core
+%------------------------------------------------------------------------------
+
+@misc{teleport_saas_vs_open,
+	author       = {Wakefield, Taylor},
+	title        = {SaaS vs Open Core Software: Advantages and Disadvantages from the Customer Perspective},
+	year         = {2019},
+	url          = {https://goteleport.com/blog/open-core-vs-saas-customer-perspective/},
+	urldate      = {2026-02-24}
+}
+
+@misc{operaton_vs_open,
+	author       = {{Operaton Team}},
+	title        = {Open Source Vs Open Core},
+	year         = {2025},
+	url          = {https://operaton.org/2025/04/22/open-source-vs-open-core/},
+	urldate      = {2026-02-24}
+}
+
+@misc{milvus_challenges,
+	author       = {Milvus.io},
+	title        = {What are the challenges of monetizing open-source projects?},
+	url          = {https://milvus.io/ai-quick-reference/what-are-the-challenges-of-monetizing-opensource-projects},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Nginx (история, кейсы)
+%------------------------------------------------------------------------------
+
+@misc{wikipedia_nginx,
+	author       = {{Wikipedia}},
+	title        = {Nginx},
+	year         = {2026},
+	url          = {https://en.wikipedia.org/wiki/Nginx},
+	urldate      = {2026-02-24}
+}
+
+@misc{blog_nginx_thanks,
+	author       = {Whiteley, Rob and {The NGINX Team}},
+	title        = {Do Svidaniya, Igor, and Thank You for NGINX},
+	year         = {2022},
+	url          = {https://blog.nginx.org/blog/do-svidaniya-igor-thank-you-for-nginx},
+	urldate      = {2026-02-24}
+}
+
+@misc{slashdot_nginx_quit,
+	author       = {{Slashdot}},
+	title        = {Nginx Core Developer Quits Project, Says He No Longer Sees Nginx as 'Free and Open Source Project For the Public Good'},
+	year         = {2024},
+	url          = {https://developers.slashdot.org/story/24/02/16/164217/nginx-core-developer-quits-project-says-he-no-longer-sees-nginx-as-free-and-open-source-project-for-the-public-good},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Модель SaaS
+%------------------------------------------------------------------------------
+
+@misc{getmonetizely_balance,
+	author       = {{GetMonetizely}},
+	title        = {How Can SaaS Companies Balance Open Source Strategy with Commercial Pricing?},
+	url          = {https://www.getmonetizely.com/articles/how-can-saas-companies-balance-open-source-strategy-with-commercial-pricing},
+	urldate      = {2026-02-24}
+}
+
+@misc{dev_clickhouse,
+	author       = {Lindesvärd, Johan},
+	title        = {ClickHouse: The Good, The Bad, and The Ugly},
+	year         = {2023},
+	url          = {https://dev.to/lindesvard/clickhouse-the-good-the-bad-and-the-ugly-2pi7},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Краудфандинг и Open Collective
+%------------------------------------------------------------------------------
+
+@misc{wptavern_opencollective,
+	author       = {WP Tavern},
+	title        = {Open Collective is a New, Transparent Way to Fund Open Source Projects},
+	url          = {https://wptavern.com/open-collective-is-a-new-transparent-way-to-fund-open-source-projects},
+	urldate      = {2026-02-24}
+}
+
+@misc{blog_opencollective_githubsponsors,
+	author       = {{Open Collective Blog}},
+	title        = {On Github Sponsors},
+	year         = {2019},
+	url          = {https://blog.opencollective.com/on-github-sponsors/},
+	urldate      = {2026-02-24}
+}
+
+@misc{heroku_codeish,
+	author       = {Heroku and {Open Collective}},
+	title        = {Supporting Open Source through Open Collective},
+	year         = {2021},
+	url          = {https://www.heroku.com/podcasts/codeish/36-supporting-open-source-through-open-collective/},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Государственное финансирование и Sovereign Tech Fund
+%------------------------------------------------------------------------------
+
+@misc{sprind_sovereigntech,
+	author       = {{SPRIND}},
+	title        = {Sovereign Tech Fund},
+	url          = {https://www.sprind.org/en/actions/projects/sovereign-tech-fund},
+	urldate      = {2026-02-24}
+}
+
+@misc{interoperable_eu_stf,
+	author       = {{Interoperable Europe Portal}},
+	title        = {Funding open source: case study on the Sovereign Tech Fund},
+	url          = {https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/document/funding-open-source-case-study-sovereign-tech-fund},
+	urldate      = {2026-02-24}
+}
+
+@misc{opensource_org_stf,
+	author       = {{Open Source Initiative}},
+	title        = {Investing in Open Source sustainability: OSI supports OpenForum Europe's EU Sovereign Tech Fund proposal},
+	year         = {2025},
+	url          = {https://opensource.org/blog/investing-in-open-source-sustainability-osi-supports-open-forum-europes-eu-sovereign-tech-fund-proposal},
+	urldate      = {2026-02-24}
+}
+
+@misc{herodevs_sovereigntech,
+	author       = {HeroDevs},
+	title        = {EU's Sovereign Tech Fund: Securing Open‑Source Sustainability and Why It Matters},
+	url          = {https://www.herodevs.com/blog-posts/eus-sovereign-tech-fund-securing-open-source-sustainability-and-why-it-matters},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Российские кейсы
+%------------------------------------------------------------------------------
+
+@misc{tadviser_postgrespro,
+	author       = {{TAdviser}},
+	title        = {Postgres Pro Enterprise},
+	url          = {https://tadviser.com/index.php/Product:Postgres_Pro_Enterprise},
+	urldate      = {2026-02-24}
+}
+
+@misc{postgrespro_enterprise,
+	author       = {{Postgres Professional}},
+	title        = {Postgres Pro Enterprise},
+	url          = {https://postgrespro.com/products/postgrespro/enterprise},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Техническая документация
+%------------------------------------------------------------------------------
+
@online{git_log_docs,
 	title = {Git - git-log Documentation},
 	author = {{The Git Development Community}},
 	year = {2024},
 	url = {https://git-scm.com/docs/git-log},
-	urldate = {2025-03-24},
-	note = {Официальная документация по команде \texttt{git log}, использованной для сбора исходных данных.},
-	langid = {english}
+	urldate = {2025-03-24}
 }

-@online{habr_oss_value_2024,
-	title = {Как «взвесить» open source: разбираем противоречивые мнения об исследованиях ценности открытого программного обеспечения},
+%------------------------------------------------------------------------------
+% Отраслевые блоги (с пометкой)
+%------------------------------------------------------------------------------
+
+@misc{habr_oss_value_2024,
 	author = {{Beeline Cloud}},
+	title = {Как «взвесить» open source: разбираем противоречивые мнения об исследованиях ценности открытого программного обеспечения},
 	year = {2024},
 	month = mar,
 	day = {10},
 	url = {https://habr.com/ru/companies/beeline_cloud/articles/799121/},
 	urldate = {2025-03-25},
-	language = {russian}
+	language = {russian},
+	note = {Отраслевой блог}
 }

-@online{gitverse_monetization,
-	title = {Как заработать на Open Source},
-	author = {{GitVerse}},
-	year = {2024},
-	month = sep,
-	day = {11},
-	url = {https://gitverse.ru/blog/articles/open-source/47-kak-zarabotat-na-open-source},
-	urldate = {2025-03-25},
-	language = {russian}
+%------------------------------------------------------------------------------
+% Дополнительные источники
+%------------------------------------------------------------------------------
+
+@misc{dailydev_trends,
+	author       = {daily.dev Ads},
+	title        = {Open Source Trends by Region: 2025 Insights},
+	url          = {https://business.daily.dev/resources/open-source-trends-by-region-insights/},
+	urldate      = {2026-02-24}
+}
+
+@misc{yugabyte_future,
+	author       = {{Yugabyte}},
+	title        = {Does Open Source Work as a Long-Term Business Model?},
+	url          = {https://www.yugabyte.com/blog/the-future-of-open-source/},
+	urldate      = {2026-02-24}
+}
+
+@misc{arxiv_licensing_future,
+	author       = {Vestin, Paul},
+	title        = {Open Source at a Crossroads: The Future of Licensing Driven by Monetization},
+	year         = {2025},
+	note         = {arXiv:2503.02817v2 [cs.CY]},
+	url          = {https://arxiv.org/html/2503.02817v2},
+	urldate      = {2026-02-24}
+}
+
+%------------------------------------------------------------------------------
+% Заимствования источников из Wikipedia
+%------------------------------------------------------------------------------
+
+%------------------------------------------------------------------------------
+% Книги и монографии (из Wikipedia)
+%------------------------------------------------------------------------------
+
+@book{popp_best_practices_2015,
+	author = {Popp, Karl Michael},
+	title = {Best Practices for commercial use of open source software: Business Models, Processes and Tools for Managing Open Source Software},
+	year = {2015},
+	publisher = {Books on Demand},
+	address = {Norderstedt, Germany},
+	isbn = {978-3-7386-1909-6},
+	pagetotal = {124},
+	langid = {english},
+	note = {Описание современных бизнес-моделей на основе открытого ПО и управления OSS в коммерческой разработке}
+}
+
+@book{popp_meyer_profit_2010,
+	author = {Popp, Karl Michael and Meyer, Ralf},
+	title = {Profit from Software Ecosystems: Business Models, Ecosystems and Partnerships in the Software Industry},
+	year = {2010},
+	edition = {Professional ed.},
+	publisher = {Books on Demand},
+	address = {Norderstedt, Germany},
+	isbn = {978-3-8391-6983-4},
+	pagetotal = {240},
+	langid = {english},
+	note = {Предисловие Karl-Heinz Streibich (CEO Software AG). Включает анализ экосистем Google, Microsoft, SAP и open source}
+}
+
+%------------------------------------------------------------------------------
+% Научные статьи (из Wikipedia)
+%------------------------------------------------------------------------------
+
+@article{riehle_single_vendor_2012,
+	author = {Riehle, Dirk},
+	title = {The Single-Vendor Commercial Open Source Business Model},
+	journal = {Information Systems and e-Business Management},
+	volume = {10},
+	number = {1},
+	pages = {5-17},
+	year = {2012},
+	publisher = {Springer Verlag},
+	doi = {10.1007/s10257-010-0149-x},
+	langid = {english},
+	note = {Анализ бизнес-моделей коммерческих open source компаний}
+}
+
+@article{riehle_economic_2007,
+	author = {Riehle, Dirk},
+	year = {2007},
+	month = {05},
+	pages = {25 - 32},
+	title = {The Economic Motivation of Open Source Software: Stakeholder Perspectives},
+	volume = {40},
+	journal = {Computer},
+	doi = {10.1109/MC.2007.147}
+}
+
+@article{benkler_freedom_2003,
+	author = {Benkler, Yochai},
+	title = {Freedom in the Commons: Towards a Political Economy of Information},
+	journal = {Duke Law Journal},
+	volume = {52},
+	number = {6},
+	pages = {1245-1276},
+	year = {2003},
+	url = {https://scholarship.law.duke.edu/dlj/vol52/iss6/3/},
+	langid = {english},
+	note = {Фундаментальная работа по экономике commons-based peer production}
+}
+
+@article{holtgrewe_articulating_2004,
+	author = {Holtgrewe, Ursula},
+	title = {Articulating the Speed(s) of the Internet: The Case of Open Source/Free Software},
+	journal = {Time \& Society},
+	volume = {13},
+	number = {1},
+	pages = {129-146},
+	year = {2004},
+	doi = {10.1177/0961463X04040750},
+	langid = {english},
+	note = {Социологическое исследование самоорганизованных open source проектов}
+}
+
+%------------------------------------------------------------------------------
+% Материалы конференций и лекции
+%------------------------------------------------------------------------------
+
+@misc{olson_opportunities_2013,
+	author = {Olson, Mike},
+	title = {Opportunities Abound in the Big Data Space},
+	howpublished = {Stanford eCorner},
+	year = {2013},
+	month = nov,
+	organization = {Stanford University},
+	url = {https://ecorner.stanford.edu/videos/opportunities-abound-in-the-big-data-space/},
+	langid = {english},
+	note = {Лекция основателя Cloudera о построении бизнеса на open source технологиях}
 }
--- a/main.tex
+++ b/main.tex
@ -8,7 +8,7 @@ style=gost-numeric,
 language=auto,
 autolang=other,
 sorting=none]{biblatex}
-\addbibresource{bibliography.bib} % Критически важно!
+\addbibresource{bibliography.bib}

 \usepackage{fontspec}
 \setmainfont{Times New Roman}
@ -48,13 +48,13 @@ sorting=none]{biblatex}
 \usepackage{tocloft}

 \usepackage{enumitem}
-\setlist{nosep} % убираем лишние отступы в списках
+\setlist{nosep} % лишние отступы в списках

 \usepackage{longtable}

 \usepackage{titlesec}

-\setcounter{tocdepth}{3}
+\setcounter{tocdepth}{2}

 \begin{document}
 	% Патчи
@ -86,7 +86,6 @@ sorting=none]{biblatex}
 	\input{sections/conclusion}
 	\newpage
 	
-
 	% В ТЕЛЕ ДОКУМЕНТА (вместо старого блока):
 	\newpage
 	\printbibliography[title={СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ}]
--- a/sections/conclusion.tex
+++ b/sections/conclusion.tex
@ -1,7 +1,41 @@
-\section{Заключение}
+\section*{Заключение}

-В ходе выполнения курсовой работы была настроена рабочая среда для подготовки документов в системе \LaTeX{}.
+В ходе выполнения курсовой работы была разработана и апробирована методика экономического обоснования для малого open-source проекта на примере создания консольного архиватора, реализующего алгоритм DEFLATE.

-Был создан структурированный шаблон курсовой работы, включающий основные разделы, что позволяет в дальнейшем сосредоточиться непосредственно на написании содержательной части работы.
+\textbf{Основные результаты работы:}

-Использование \LaTeX{} в процессе подготовки учебных и научных работ способствует повышению качества оформления документов и упрощает работу с большими объёмами текста.
+\begin{enumerate}
+	\item Проведён анализ теоретических основ разработки открытого программного обеспечения, включая классификацию ПО, философию open source, типы лицензий и современные модели монетизации. Особое внимание уделено работам Д. Рихле, раскрывающим экономическую мотивацию различных участников open-source экосистемы, и исследованиям К. Поппа, систематизирующим риски и практики коммерческого использования открытого кода.
+	
+	\item Выполнен количественный анализ истории разработки трёх классических open-source архиваторов (\texttt{bzip2}, \texttt{xz utils}, \texttt{zstd}), который подтвердил реалистичность планируемых трудозатрат и позволил оценить масштаб проекта-аналога (\texttt{bzip2} с объёмом кода ~16,6 тыс. строк).
+	
+	\item Разработана детальная оценка трудозатрат на создание MVP (200 человеко-часов, ФОТ 240 тыс. руб.), которая была верифицирована с помощью параметрической модели COCOMO I. Расхождение между декомпозиционной оценкой и моделью COCOMO (1856 часов) объясняется спецификой малых утилит и открытым характером разработки, что позволило использовать результат COCOMO как верхнюю границу трудозатрат.
+	
+	\item Произведён расчёт капитальных и операционных затрат. Общий объём CAPEX составил 307 тыс. руб., годовые операционные расходы (OPEX) — 473 тыс. руб. Показано, что структура затрат для open-source проекта радикально смещена в сторону ФОТ при нулевой стоимости лицензионного ПО.
+	
+	\item Выполнено прогнозирование выручки по трём сценариям с учётом данных о типичной конверсии пользователей в клиенты (0,5–2\%) для single-vendor open source компаний \cite{riehle_single_vendor_2012}. В реалистичном сценарии годовая выручка составила 37,5 тыс. руб., что привело к убытку 437 тыс. руб. и отрицательной рентабельности инвестиций (–242\%).
+	
+	\item Рассчитана точка безубыточности (20 контрактов поддержки в год), показана недостижимость этого показателя в рамках чисто сервисной модели для данного проекта.
+	
+	\item Предложена адаптированная методика оценки эффективности open-source проектов, учитывающая не только денежные потоки, но и нематериальные выгоды: накопление человеческого капитала («коммиттер-премия»), репутационные эффекты, вклад в экосистему. Разработаны формулы для количественной оценки этих компонентов.
+	
+	\item Сформулированы практические рекомендации для разработчика open-source проекта, включающие выбор гибридной бизнес-модели (Open Core, SaaS), использование расширенной формулы рентабельности, работу с сообществом и внедрение элементов open source governance.
+\end{enumerate}
+
+\textbf{Выводы:}
+
+Проведённое исследование подтвердило исходную гипотезу о том, что классические методы экономической оценки, ориентированные на коммерческую разработку, дают отрицательные результаты применительно к open-source проектам и не отражают их реальной ценности. Парадокс open source заключается в несоответствии высокой общественной полезности и низкой или отрицательной коммерческой рентабельности, измеряемой традиционными финансовыми показателями.
+
+Предложенная в работе адаптированная методика, сочетающая классические подходы (COCOMO, расчёт CAPEX/OPEX) с оценкой нематериальных выгод (человеческий капитал, репутация, экосистемный вклад), позволяет более адекватно оценивать эффективность малых open-source проектов и обосновывать целесообразность их разработки, особенно в образовательном и академическом контексте.
+
+Практическая значимость работы заключается в создании инструментария, который может быть использован студентами, начинающими разработчиками и исследователями для экономического обоснования собственных open-source инициатив, а также для выбора оптимальной стратегии монетизации.
+
+\textbf{Направления дальнейших исследований:}
+
+\begin{itemize}
+	\item Эмпирическая верификация предложенных коэффициентов для оценки «коммиттер-премии» на российском рынке труда.
+	\item Разработка методики количественной оценки вклада проекта в экосистему через анализ графа зависимостей.
+	\item Исследование применимости предложенного подхода для других типов open-source проектов (библиотеки, фреймворки, инфраструктурное ПО).
+\end{itemize}
+
+Таким образом, цель курсовой работы — разработка и апробация методики экономического обоснования для малого open-source проекта — достигнута, все поставленные задачи выполнены.
--- a/sections/intro.tex
+++ b/sections/intro.tex
@ -2,35 +2,33 @@
 \section*{\centering ВВЕДЕНИЕ}
 \addcontentsline{toc}{section}{ВВЕДЕНИЕ}

-Тема свободных программ актуальна как никогда. Программное обеспечение с открытым исходным кодом (Open-Source Software, OSS) признано стратегическим активом и драйвером инноваций на уровне экономик целых регионов, что подтверждается специализированными исследованиями, проводимыми для Европейского Союза \cite{eu_report}. Однако по мере того как OSS становится мейнстримом, возникает парадокс: согласно исследованию Linux Foundation (Census III, 2024), свободное и открытое программное обеспечение (FOSS) демонстрирует растущую зависимость мировой экономики, при этом анализ более 12 миллионов точек данных выявил, что 40\% наиболее популярных проектов поддерживаются всего одним или двумя разработчиками \cite{linux_census3_2024}. Это создаёт ситуацию, когда критически важные компоненты цифровой инфраструктуры имеют минимальную ресурсную базу для долгосрочной поддержки и экономической оценки. Данная работа фокусируется на одном из таких классов проектов — консольных утилитах для обработки данных, типичным представителем которых является компрессор. Разработка подобных инструментов часто ведётся малыми командами с использованием открытого стека технологий, что делает задачу корректного расчёта их себестоимости и эффективности одновременно актуальной и методически сложной.
+Тема свободных программ актуальна как никогда. Программное обеспечение с открытым исходным кодом (Open-Source Software, OSS) признано стратегическим активом и драйвером инноваций на уровне экономик целых регионов, что подтверждается специализированными исследованиями, проводимыми для Европейского Союза \cite{eu_report}. Однако по мере того как OSS становится мейнстримом, возникает парадокс: согласно исследованию Linux Foundation (Census III, 2024), свободное и открытое программное обеспечение (FOSS) демонстрирует растущую зависимость мировой экономики, при этом анализ более 12 миллионов точек данных выявил, что 40\% наиболее популярных проектов поддерживаются всего одним или двумя разработчиками \cite{linux_census3_2024}. Это создаёт ситуацию, когда критически важные компоненты цифровой инфраструктуры имеют минимальную ресурсную базу для долгосрочной поддержки и экономической оценки. Данная работа фокусируется на одном из таких классов проектов — консольных утилитах для обработки данных, типичным представителем которых является архиватор/компрессор. Разработка подобных инструментов часто ведётся малыми командами с использованием открытого стека технологий, что делает задачу корректного расчёта их себестоимости и эффективности одновременно актуальной и методически сложной.

 Степень научной разработанности темы. Социокультурные и организационные аспекты разработки open-source программного обеспечения глубоко исследованы в классической работе Эрика Реймонда «Собор и базар» \cite{raymond_cathedral}. Автор, анализируя успех Linux и собственного проекта fetchmail, противопоставляет закрытую «соборную» модель разработки (характерную для традиционной коммерческой разработки) открытой «базарной», где ключевую роль играет распределённое сообщество разработчиков, ранние и частые релизы, а также принцип «при достаточном количестве наблюдателей все ошибки становятся мелкими» (Закон Линуса). Однако, как отмечает сам Реймонд, мотивацией участников в такой модели служат репутация и личный интерес («egoboo»), а не прямое финансовое вознаграждение. Это создаёт фундаментальное противоречие: экономические модели оценки (такие как COCOMO) созданы для «соборной» модели с оплачиваемым трудом, в то время как значительная часть open-source экосистемы живёт по законам «базара». Данная работа направлена на частичное устранение этого противоречия путём создания методики расчёта, учитывающей специфику малых проектов, разрабатываемых в «базарной» парадигме.

 Исследовательские проблемы, цель и задачи заключаются в отсутствии адаптированной и апробированной методики расчёта экономических показателей (себестоимости, эффективности) для open-source проектов, разрабатываемых индивидуально или малыми командами, на примере класса консольных утилит.

-Конкретный исследовательский вопрос: Как определить полную себестоимость и оценить экономическую эффективность разработки консольного компрессора, реализованного с использованием исключительно открытых инструментов и распространяемого по свободной лицензии?
+Конкретный исследовательский вопрос: Применимы ли классические методики экономической оценки (CAPEX/OPEX, ROI, точка безубыточности) для малых open-source проектов, и если нет, то как их адаптировать или чем дополнить или заменить?

-Цель работы — разработать и апробировать методику экономического обоснования разработки консольного архиватора с открытым исходным кодом, рассчитав ключевые показатели затрат и эффективности.
+Цель работы — проверить применимость классической методики экономического обоснования к проекту разработки open-source архиватора, выявить её ограничения и предложить адаптированный подход для оценки подобных проектов.

 Для достижения цели поставлены следующие задачи:
 \begin{enumerate}
-	\item Изучить теоретические основы: материально-техническую базу ИТ-предприятий и классические методики оценки стоимости ПО (COCOMO, функциональные точки).
-	\item Определить основные характеристики разрабатываемого программного продукта — консольного компрессора: его функции (MVP), целевую аудиторию и дать оценку трудозатрат на разработку.
-	\item Рассчитать капитальные (CAPEX) и операционные (OPEX) затраты на проект, спрогнозировать потенциальную выручку и определить себестоимость разработки.
-	\item Провести анализ эффективности проекта путём расчёта точки безубыточности, срока окупаемости и возврата на инвестиции (ROI).
-	\item Сформулировать практические рекомендации по адаптации методики для реалий индивидуальной open-source разработки.
+	\item Изучить теоретические основы экономики ПО и специфику open-source разработки.
+	\item Сформулировать кейс проекта, провести оценку трудозатрат и собрать исходные данные для расчёта по классической методике.
+	\item Выполнить формальный расчёт по классической методике (CAPEX, OPEX, выручка, точка безубыточности, ROI).
+	\item Проанализировать полученные результаты, выявив противоречия между расчётными показателями и реальной ценностью open-source проектов.
+	\item На основе анализа предложить адаптированный подход или комплекс рекомендаций для экономической оценки малых open-source проектов.
 \end{enumerate}

-Объект исследования — процесс разработки консольного приложения с открытым исходным кодом для архивирования и/или компрессии потоков данных (файлов).
+Объект исследования — процесс экономического обоснования разработки программного обеспечения с открытым исходным кодом.
+Предмет исследования — классические методики экономической оценки ПО и их применимость к условиям open-source разработки на примере проекта консольного архиватора.

-Предмет исследования — экономические показатели данного процесса: состав и структура затрат, себестоимость, показатели экономической эффективности (точка безубыточности, ROI, срок окупаемости).
+Теоретическая значимость работы заключается в критическом анализе границ применимости классических экономических моделей (COCOMO, расчёт ROI) к open-source парадигме и в формулировке направлений для их развития.

-Теоретическая значимость исследования заключается в преодолении выявленного методологического разрыва между классическими экономическими моделями оценки ПО, созданными для «соборной» разработки, и реалиями «базарной» open-source модели. Работа вносит вклад в экономику программной инженерии, предлагая подход к адаптации таких методик, как COCOMO, для условий малых, некоммерческих или слабо финансируемых проектов, чья роль в цифровой инфраструктуре, однако, остаётся критической.
-
-Практическая значимость состоит в том, что разработанная методика и конкретные расчёты для кейса консольного компрессора предоставляют готовый инструмент для:
+Практическая значимость состоит в том, что работа:
 \begin{itemize}
-	\item Индивидуальных разработчиков и малых команд, позволяя реалистично оценить полную стоимость создания и поддержки open-source продукта, что необходимо для планирования ресурсов, поиска финансирования или обоснования перехода на модели гибридного монетизирования.
-	\item Менеджеров и аналитиков IT-проектов в компаниях, которые используют или вносят вклад в open-source, помогая количественно оценить вклад в экосистему и затраты на внутреннюю поддержку внешних зависимостей.
-	\item Образовательных учреждений, предлагая конкретный, структурированный кейс для обучения основам технико-экономического обоснования программных продуктов в условиях современной open-source парадигмы.
+	\item Предоставляет реалистичный кейс с полным расчётом, наглядно демонстрирующий, почему стандартные модели дают негативную оценку open-source проекту.
+	\item Систематизирует актуальные модели монетизации open-source, предоставляя разработчикам и менеджерам структурированный обзор возможностей.
+	\item Формулирует практические рекомендации о том, какие метрики и подходы (помимо прямых финансовых) следует учитывать при оценке целесообразности участия в open-source проектах.
 \end{itemize}
-Таким образом, работа не только отвечает на конкретный исследовательский вопрос, но и обеспечивает переносимый методический каркас для экономического анализа широкого класса малых open-source проектов.
--- a/sections/practice.tex
+++ b/sections/practice.tex
@ -1,4 +1,4 @@
-\section{Расчёт экономических показателей разработки программного продукта с открытым исходным кодом} % Глава 2
+\section{Расчёт экономических показателей разработки программного продукта с открытым исходным кодом}

 \subsection{Основные характеристики разрабатываемого программного продукта}

@ -54,7 +54,7 @@
 \vspace{5pt}
 \noindent \footnotesize{*Расчёт выполнен автором на основе агрегированной статистики git-репозиториев.}

-Анализ показал, что проект \texttt{bzip2}, являющийся полнофункциональным архиваторм, был создан и длительно поддерживался силами, эквивалентными работе одного разработчика. Его итоговый объём кода ($\approx$ 16.6 тыс. строк) и история коммитов позволяют сделать вывод о реалистичности разработки аналогичного по масштабу, но более простого (использующего стандартный DEFLATE) продукта в сжатые сроки.
+Анализ показал, что проект \texttt{bzip2}, являющийся полнофункциональным архиватором, был создан и длительно поддерживался силами, эквивалентными работе одного разработчика. Его итоговый объём кода ($\approx$ 16.6 тыс. строк) и история коммитов позволяют сделать вывод о реалистичности разработки аналогичного по масштабу, но более простого (использующего стандартный DEFLATE) продукта в сжатые сроки.

 \subsubsection{Оценка трудозатрат и ресурсов для разработки}
 На основе проведённого сравнительного анализа, а также с учётом принципов декомпозиции работ по методологии, изложенной в \cite[с. 86--90]{polyansky_ekonomika_2017}, составлена детальная оценка трудозатрат. Для расчёта фонда оплаты труда (ФОТ) принята рыночная ставка разработчика средней квалификации (C-программист/инженер ПО) в размере 1 200 руб./час, что соответствует данным по региональному рынку труда на 2024--2025 гг.
@ -76,6 +76,20 @@

 Таким образом, общая оценка трудозатрат на создание MVP консольного архиватора составляет 200 человеко-часов, а фонд оплаты труда (ФОТ) — 240 000 рублей. Данная оценка является консервативной и опирается на анализ наиболее релевантного аналога (\texttt{bzip2}), что обеспечивает запас при планировании и соответствует принципам реалистичного прогнозирования в условиях малого open-source проекта.

+\subsubsection{Оценка трудоёмкости по модели COCOMO I}
+Для дополнительной верификации полученной оценки воспользуемся классической параметрической моделью COCOMO I (Constructive Cost Model). Базовая формула для органического типа проектов, к которому может быть отнесён разрабатываемый архиватор, имеет вид \cite[p.~87]{polyansky_ekonomika_2017}:
+\begin{equation}
+	PM = 2,4 \times (KSLOC)^{1,05} \times \prod_{i=1}^{n} EMF_i,
+	\label{eq:cocomo}
+\end{equation}
+где \(PM\) — трудозатраты в человеко-месяцах, \(KSLOC\) — размер кода в тысячах строк, \(EMF_i\) — поправочные коэффициенты.
+
+Принимая ожидаемый размер кода равным 5 KSLOC (5000 строк) и используя стандартные значения поправочных коэффициентов для средних условий разработки (надёжность ПО RELY = 1,00; сложность модулей CPLX = 1,00; опыт команды AEXP = 1,00; использование современных инструментов TOOL = 0,90; ограничения времени разработки SCED = 1,00), получаем произведение коэффициентов, равное 0,90. Подставляя значения в формулу:
+\[
+PM = 2,4 \times 5^{1,05} \times 0,90 \approx 2,4 \times 5,38 \times 0,90 = 11,6 \text{ человеко-месяцев}.
+\]
+При стандартной продолжительности рабочего месяца 160 часов это соответствует \(11,6 \times 160 = 1856\) часов, что значительно превышает предварительную оценку в 200 часов. Данное расхождение объясняется тем, что COCOMO ориентирована на крупные проекты с полным жизненным циклом и не учитывает специфику малых утилит, возможность повторного использования готовых наработок, а также открытый характер разработки, где часть трудозатрат может быть компенсирована вкладом сообщества \cite{riehle_single_vendor_2012}. Тем не менее, полученное значение служит верхней границей трудозатрат и подтверждает, что даже по пессимистичным оценкам проект остаётся в рамках реализуемости.
+
 \subsection{Расчёт экономических показателей разработки программного продукта}

 \subsubsection{Расчёт капитальных затрат (CAPEX)}
@ -102,7 +116,6 @@
 \subsubsection{Расчёт операционных затрат (OPEX)}
 Операционные затраты (OPEX) — это ежегодные расходы на поддержку и эксплуатацию работающего программного продукта после его релиза.

-% В подразделе 2.2.2 (Расчёт операционных затрат) ОБНОВЛЕННАЯ ТАБЛИЦА:
 \begin{table}[h!]
 	\centering
 	\caption{Структура годовых операционных затрат (OPEX)}
@ -110,7 +123,7 @@
 	\begin{tabular}{|p{0.4\textwidth}|p{0.35\textwidth}|p{0.2\textwidth}|}
 		\hline
 		Статья расходов & Метод расчёта & Сумма, руб./год \\ \hline
-		Хостинг и инфраструктура & Использование бесплатного тарифа публичной платформы (GitHub, GitLab). Для сценария с полным контролем: аренда VPS ~500 руб./мес. \cite{gitverse_monetization} & 0 (6 000)* \\ \hline
+		Хостинг и инфраструктура & Использование бесплатного тарифа публичной платформы (GitHub, GitLab). Для сценария с полным контролем: аренда VPS ~500 руб./мес. \cite{palark_monetization} & 0 (6 000)* \\ \hline
 		Техническая поддержка & 0.25 ставки инженера (реакция на issues, правка документации). З/п: 120 000 руб./мес. \newline \( 120\,000 \times 0.25 \times 12 \times 1.3 \) (с учётом страховых взносов 30\%) & 468 000 \\ \hline
 		Маркетинг и продвижение & Минимальный бюджет (публикация на форумах, базовое SEO) & 5 000 \\ \hline
 		Обновление лицензий & Все инструменты и зависимости — open-source, обновления бесплатны & 0 \\ \hline
@ -125,6 +138,10 @@
 \subsubsection{Прогнозирование выручки от внедрения продукта}
 Для open-source проекта, распространяемого под лицензией GPL, традиционная модель монетизации через продажу лицензий неприменима. В качестве основной модели принята модель платной поддержки и консалтинга для корпоративных пользователей, желающих гарантировать работоспособность и безопасность утилиты в своей инфраструктуре. 

+Согласно исследованию Д. Рихле, для компаний, работающих по модели single-vendor commercial open source, типичная конверсия пользователей в платящих клиентов составляет от 0,5% до 2% \cite{riehle_single_vendor_2012}. Это значение значительно ниже использованного в первоначальном прогнозе, поэтому для получения более реалистичной картины целесообразно рассмотреть несколько сценариев.
+
+Исходные данные для прогнозирования представлены в таблице \ref{tab:revenue_params}. Конверсия в установку \(C_{install}=2\%\) оценивает долю компаний, которые заинтересуются продуктом и начнут его использовать. На её основе определяется число активных пользователей \(U_{мес}\). Затем с помощью конверсии \(C_{active}\) (пессимистичной, реалистичной и оптимистичной) рассчитывается число клиентов платной поддержки и годовая выручка.
+
 \begin{table}[h!]
 	\centering
 	\caption{Данные для прогнозирования годовой выручки}
@ -134,32 +151,31 @@
 		Параметр & Обозначение & Значение \\ \hline
 		Общий размер целевой аудитории (ИТ-компании малого и среднего размера в РФ) & \( N_{total} \) & 5 000 \\ \hline
 		Конверсия в установку/пользование продуктом & \( C_{install} \) & 2\% \\ \hline
-		Конверсия пользователей в клиентов платной поддержки & \( C_{active} \) & 5\% \\ \hline
+		Конверсия пользователей в клиенты платной поддержки & \( C_{active} \) & 0,5\% (пессимистичный), 1,5\% (реалистичный), 5\% (оптимистичный) \\ \hline
 		Среднее количество контрактов в год на пользователя & \( Q \) & 1 \\ \hline
 		Средний годовой контракт на поддержку & \( P_{avg} \) & 25 000 руб. \\ \hline
 	\end{tabular}
 \end{table}

-На основе этих параметров рассчитывается прогнозный денежный поток (Таблица \ref{tab:revenue_calc}).
+На основе этих параметров рассчитаны три варианта денежного потока (таблица \ref{tab:revenue_calc}).

 \begin{table}[h!]
 	\centering
-	\caption{Расчётный денежный поток от эксплуатации}
+	\caption{Расчётный денежный поток от эксплуатации по сценариям}
 	\label{tab:revenue_calc}
-	\begin{tabular}{|p{0.5\textwidth}|p{0.25\textwidth}|p{0.2\textwidth}|}
+	\begin{tabular}{|p{0.45\textwidth}|p{0.25\textwidth}|p{0.25\textwidth}|}
 		\hline
-		Показатель & Формула расчёта & Значение \\ \hline
-		Активные пользователи в месяц (компании) & \( U_{мес} = N_{total} \cdot C_{install} \) & \( 5\,000 \cdot 0.02 = 100 \) \\ \hline
-		Клиенты платной поддержки в год & \( U_{год.клиенты} = U_{мес} \cdot C_{active} \) & \( 100 \cdot 0.05 = 5 \) \\ \hline
-		Месячная выручка & \( V_{мес} = U_{год.клиенты} \cdot Q \cdot \frac{P_{avg}}{12} \) & \( 5 \cdot 1 \cdot \frac{25\,000}{12} \approx 10\,417 \) \\ \hline
-		Годовая выручка & \( V_{год} = V_{мес} \cdot 12 \) & 125 000 руб. \\ \hline
+		Показатель & Формула расчёта & Значение (песс. / реал. / оптим.) \\ \hline
+		Активные пользователи в месяц (компании) & \( U_{мес} = N_{total} \cdot C_{install} \) & 100 \\ \hline
+		Клиенты платной поддержки в год & \( U_{год.клиенты} = U_{мес} \cdot C_{active} \) & 0,5 / 1,5 / 5 \\ \hline
+		Годовая выручка & \( V_{год} = U_{год.клиенты} \cdot P_{avg} \) & 12 500 / 37 500 / 125 000 руб. \\ \hline
 	\end{tabular}
 \end{table}

-Прогнозируемая годовая выручка составляет 125 000 рублей. Данная цифра консервативна и отражает реалии нишевого open-source продукта, где монетизация является сложной задачей и часто не является основной целью разработки \cite{linux_census3_2024}.
+Прогнозируемая годовая выручка в реалистичном сценарии составляет 37 500 рублей, что заметно ниже оптимистичной оценки в 125 000 руб. Данная цифра отражает реальную сложность монетизации нишевого open-source продукта, где лишь небольшая доля пользователей готова оплачивать поддержку \cite{linux_census3_2024}. В дальнейших расчётах будем опираться на реалистичный сценарий.

 \subsubsection{Расчёт прибыли и рентабельности}
-На основе прогноза выручки и затрат формируется прогнозный отчёт о прибылях и убытках (Таблица \ref{tab:pnl}).
+На основе прогноза выручки (реалистичный сценарий) и затрат формируется прогнозный отчёт о прибылях и убытках (Таблица \ref{tab:pnl}).

 \begin{table}[h!]
 	\centering
@ -168,22 +184,30 @@
 	\begin{tabular}{|p{0.45\textwidth}|p{0.3\textwidth}|p{0.2\textwidth}|}
 		\hline
 		Показатель & Формула расчёта & Значение, руб. \\ \hline
-		Выручка (Revenue) & \( V_{год} \) (из Табл. \ref{tab:revenue_calc}) & 125 000 \\ \hline
-		Переменные расходы (комиссии платёжных систем 5\%) & \( C_{var} = V_{год} \cdot 0.05 \) & 6 250 \\ \hline
-		Валовая прибыль (Gross Profit) & \( GP = V_{год} - C_{var} \) & 118 750 \\ \hline
+		Выручка (Revenue) & \( V_{год} \) (реалистичный сценарий) & 37 500 \\ \hline
+		Переменные расходы (комиссии платёжных систем 5\%) & \( C_{var} = V_{год} \cdot 0.05 \) & 1 875 \\ \hline
+		Валовая прибыль (Gross Profit) & \( GP = V_{год} - C_{var} \) & 35 625 \\ \hline
 		Операционные расходы (OPEX) & \( C_{opex} \) (из Табл. \ref{tab:opex_structure}) & 473 000 \\ \hline
-		Прибыль до налогообложения (EBIT) & \( EBIT = GP - C_{opex} \) & -354 250 \\ \hline
+		Прибыль до налогообложения (EBIT) & \( EBIT = GP - C_{opex} \) & –437 375 \\ \hline
 		Налог на прибыль (20\%)* & \( Tax = 0 \) (при убытке) & 0 \\ \hline
-		Чистая прибыль (Net Profit) & \( NP = EBIT - Tax \) & -354 250 \\ \hline
+		Чистая прибыль (Net Profit) & \( NP = EBIT - Tax \) & –437 375 \\ \hline
 	\end{tabular}
 \end{table}
 \vspace{5pt}
 \noindent \footnotesize{*При расчёте налога на прибыль учитывается, что налогооблагаемая база не может быть отрицательной.}

-Как видно из расчётов, проект является убыточным при рассмотрении исключительно прямых финансовых потоков. Годовой убыток составляет 354 250 рублей. Рентабельность продаж (ROS) отрицательна. Данный результат является типичным для многих open-source проектов, ценность которых заключается не в прямой монетизации, а в создании общественного блага, построении репутации, портфолио разработчика и косвенных экономических эффектах \cite{eu_report}.
+Как видно из расчётов, проект является убыточным при рассмотрении исключительно прямых финансовых потоков. Годовой убыток составляет 437 375 рублей. Рентабельность продаж (ROS) отрицательна. Данный результат является типичным для многих open-source проектов, ценность которых заключается не в прямой монетизации, а в создании общественного блага, построении репутации, портфолио разработчика и косвенных экономических эффектах \cite{eu_report}.

 \subsubsection{Адаптация методики для индивидуальной open-source разработки}
-Приведённый выше расчёт соответствует формальному «коммерческому» сценарию. Однако для индивидуального разработчика или малой команды энтузиастов экономическая модель кардинально меняется.
+Приведённый выше расчёт соответствует формальному «коммерческому» сценарию. Однако для индивидуального разработчика или малой команды энтузиастов экономическая модель кардинально меняется. Как отмечает Рихле в своём исследовании single-vendor open source, важным нематериальным активом становится так называемая «коммиттер-премия» — повышение рыночной стоимости разработчика благодаря статусу коммиттера в значимом проекте \cite{riehle_single_vendor_2012}. Ссылаясь на эмпирические данные Ханна и др., Рихле указывает, что разработчики, достигшие статуса коммиттера, могут рассчитывать на прирост заработной платы в размере 20–40\%.
+
+Количественная оценка нематериальных выгод может быть выполнена с использованием следующего подхода:
+\[
+V_{reputation} = \Delta S \times T_{car} \times P_{comm},
+\]
+где \(\Delta S\) — ожидаемый прирост годовой зарплаты после получения статуса коммиттера, \(T_{car}\) — оставшийся период карьеры (в годах), \(P_{comm}\) — вероятность достижения этого статуса в ходе работы над проектом. Дополнительно следует учитывать эквивалентную стоимость обучения (например, специализированные курсы по алгоритмам сжатия и системному программированию, которые могут стоить 50–100 тыс. руб.) и вклад в экосистему, измеряемый через предотвращённые затраты других разработчиков, использующих данный код.
+
+В таблице \ref{tab:models_comparison} сопоставлены формальный коммерческий подход и реальный сценарий индивидуальной разработки.

 \begin{table}[h!]
 	\centering
@ -195,15 +219,15 @@
 		CAPEX & 307 334 руб. (полный расчёт) & 8 000 руб. (амортизация ПК + энергия) \\ \hline
 		ФОТ & 240 000 руб. (рыночная ставка) & 0 руб. (альтернативная стоимость времени, труд добровольца) \\ \hline
 		OPEX & 473 000 руб./год (включая поддержку) & 0 руб./год (поддержка по мере возможностей) \\ \hline
-		Выручка & 125 000 руб./год (прогноз) & 0 – 50 000 руб./год (нерегулярные донаты) \\ \hline
-		Прибыль & -354 250 руб./год (убыток) & Нематериальная выгода (портфолио, знания, репутация) \\ \hline
+		Выручка & 12 500 – 125 000 руб./год (прогноз) & 0 – 50 000 руб./год (нерегулярные донаты) \\ \hline
+		Прибыль & –437 375 руб./год (убыток) & Нематериальная выгода (портфолио, знания, репутация) \\ \hline
 	\end{tabular}
 \end{table}

 Для индивидуального разработчика основными «доходами» являются:
 \begin{itemize}
 	\item Накопление человеческого капитала: Приобретённые навыки (оптимизация C, работа с алгоритмами) эквивалентны прохождению углублённого курса стоимостью 50 000–100 000 руб.
-	\item Укрепление репутации в сообществе: Наличие успешного open-source проекта повышает стоимость часа будущей работы разработчика.
+	\item Укрепление репутации в сообществе: Наличие успешного open-source проекта повышает стоимость часа будущей работы разработчика (эффект коммиттер-премии).
 	\item Социальная польза: Вклад в экосистему свободного ПО, которой, согласно исследованиям, пользуются миллионы \cite{linux_census3_2024}.
 \end{itemize}

@ -213,9 +237,9 @@
 Расчёт экономических показателей разработки консольного архиватора с открытым исходным кодом показал:
 \begin{enumerate}
 	\item Структура затрат для open-source проекта радикально смещена: CAPEX минимизирован за счёт бесплатных инструментов, основную долю в нём составляет ФОТ.
-	\item В рамках традиционной финансовой модели проект является убыточным (чистый убыток ~354 тыс. руб. в год), что является нормальным для open-source продуктов, не ориентированных на прямую монетизацию.
+	\item В рамках традиционной финансовой модели проект является убыточным (чистый убыток ~437 тыс. руб. в год в реалистичном сценарии), что является нормальным для open-source продуктов, не ориентированных на прямую монетизацию.
 	\item Ключевой экономический парадокс open-source заключается в несоответствии высокой общественной полезности проекта и его низкой или отрицательной коммерческой рентабельности.
-	\item Для индивидуального разработчика методика расчёта должна быть адаптирована: вместо финансовых потоков на первый план выходит оценка альтернативной стоимости времени и нематериальных выгод (портфолио, репутация, человеческий капитал).
+	\item Для индивидуального разработчика методика расчёта должна быть адаптирована: вместо финансовых потоков на первый план выходит оценка альтернативной стоимости времени и нематериальных выгод (портфолио, репутация, человеческий капитал). Эмпирические данные подтверждают существование «коммиттер-премии», что позволяет частично квантифицировать эти выгоды \cite{riehle_single_vendor_2012}.
 \end{enumerate}
 Полученные цифры служат основой для финального анализа эффективности проекта в следующем подразделе.

@ -245,7 +269,7 @@
 Подставив значения, получаем: \( Q_{\text{ТБУ}} = \frac{473\,000}{25\,000 - 1\,250} \approx 20 \) контрактов в год.
 В денежном выражении: \( V_{\text{ТБУ}} = 20 \times 25\,000 = 500\,000 \) руб./год.

-Вывод 1: Для покрытия затрат проект должен заключать не менее 20 контрактов платной поддержки в год. При прогнозе в 5 контрактов (Таблица \ref{tab:revenue_calc}) проект заведомо убыточен в рамках данной модели.
+Вывод 1: Для покрытия затрат проект должен заключать не менее 20 контрактов платной поддержки в год. При прогнозе в 1,5 контракта (реалистичный сценарий) проект заведомо убыточен в рамках данной модели.

 \subsubsection{Расчёт срока окупаемости и возврата на инвестиций (ROI)}
 Срок окупаемости (PP) и возврат на инвестиции (ROI) рассчитываются для капитальных затрат (CAPEX).
@ -258,70 +282,138 @@
 		\hline
 		Параметр & Обозначение & Значение \\ \hline
 		Капитальные затраты & CAPEX & 307 334 руб. (из Табл. \ref{tab:capex_structure}) \\ \hline
-		Чистая прибыль в год & \( P_{\text{чист.год}} \) & -354 250 руб./год (из Табл. \ref{tab:pnl}) \\ \hline
+		Чистая прибыль в год & \( P_{\text{чист.год}} \) & –437 375 руб./год (из Табл. \ref{tab:pnl}) \\ \hline
 	\end{tabular}
 \end{table}

-При отрицательной прибыли срок окупаемости формально стремится к бесконечности: \( PP = \frac{307\,334}{-354\,250} \approx -0.87 \) (не окупается).
+При отрицательной прибыли срок окупаемости формально стремится к бесконечности: \( PP = \frac{307\,334}{-437\,375} \approx -0,7 \) (не окупается).

 Рентабельность инвестиций (ROI) также отрицательна:
 \begin{equation}
-	ROI = \frac{P_{\text{чист.год}} - \text{CAPEX}}{\text{CAPEX}} \times 100\% = \frac{-354\,250 - 307\,334}{307\,334} \times 100\% \approx -215\%.
+	ROI = \frac{P_{\text{чист.год}} - \text{CAPEX}}{\text{CAPEX}} \times 100\% = \frac{-437\,375 - 307\,334}{307\,334} \times 100\% \approx -242\%.
 \end{equation}

-Вывод 2: С точки зрения классического финансового анализа, проект абсолютно неэффективен: CAPEX не окупается, на каждый вложенный рубль приходится 2.15 рубля убытка.
+Вывод 2: С точки зрения классического финансового анализа, проект абсолютно неэффективен: CAPEX не окупается, на каждый вложенный рубль приходится 2,42 рубля убытка.

 \subsubsection{Критический анализ результатов и адаптация методики оценки для open-source}
-Полученные отрицательные показатели являются не ошибкой расчёта, а отражением фундаментального противоречия, описанного в исследованиях: попытки оценить open-source исключительно через прямые финансовые потоки заведомо ведут к отрицательным выводам, так как не учитывают природу его ценности \cite{habr_oss_value_2024}.

-Ответ на вопрос курсовой работы формулируется в два этапа:
+Полученные в предыдущих расчётах отрицательные показатели — убыток 437 тыс. руб. в год, отрицательная рентабельность инвестиций ( –242 \%), недостижимая точка безубыточности — на первый взгляд свидетельствуют о полной экономической несостоятельности проекта. Однако такой вывод был бы поспешным и методологически неверным. Как справедливо отмечается в отраслевых дискуссиях, попытки оценить open-source исключительно через прямые финансовые потоки заведомо ведут к отрицательным выводам, поскольку игнорируют принципиально иную природу ценности, создаваемой открытыми проектами \cite{habr_oss_value_2024}. Этот феномен получил название «парадокс open source»: высокая общественная полезность сочетается с низкой или отрицательной коммерческой рентабельностью, если измерять её традиционными показателями.
+
+Для понимания корней этого парадокса обратимся к работе Д. Рихле, посвящённой экономической мотивации участников open-source экосистемы \cite{riehle_economic_2007}. Рихле подчёркивает, что разные стейкхолдеры имеют принципиально различные интересы и, соответственно, по-разному извлекают выгоду из существования открытого ПО:

-1. Можно ли получить деньги с open-source проекта?
-Да, но не через прямую продажу лицензий на ядро проекта. Анализ практик монетизации показывает, что доход генерируется через сопутствующие услуги и модели \cite{gitverse_monetization}:
 \begin{itemize}
-	\item Платная поддержка и консалтинг (реализовано в нашей модели).
-	\item Модель Open Core: бесплатное ядро (GPL) + платные проприетарные дополнения (например, графический интерфейс, облачная синхронизация).
-	\item SaaS (ПО как услуга): хостинг управляемой версии архиватора в облаке.
-	\item Краудфандинг и спонсорство (через Open Collective, GitHub Sponsors).
+	\item Системные интеграторы (компании, которые строят решения на базе готовых компонентов) получают возможность увеличить свою прибыль за счёт снижения затрат на лицензионное ПО. Если раньше они вынуждены были делиться выручкой с проприетарными вендорами, то с переходом на open source эти средства остаются у интегратора или могут быть направлены на расширение клиентской базы благодаря более гибкому ценообразованию. Для них open source — это инструмент повышения операционной эффективности.
+	\item Разработчики (как индивидуальные, так и наёмные) видят в участии в open-source проектах возможность накопления человеческого капитала. Работа над реальным, востребованным проектом позволяет приобрести уникальные навыки, получить признание в сообществе и в конечном счёте повысить свою рыночную стоимость. Рихле, ссылаясь на эмпирические исследования Ханна и др., указывает на существование так называемой «коммиттер-премии» — устойчивой прибавки к зарплате у разработчиков, достигших статуса коммиттера в значимых проектах.
+	\item Вендоры (компании, разрабатывающие ПО) используют open source как стратегический инструмент для захвата рынка. Открывая базовую функциональность, они снижают барьеры входа для пользователей, формируют сообщество и на этой основе строят монетизацию через дополнительные услуги или расширенные версии (модели Open Core, SaaS). Это позволяет быстрее обойти традиционных конкурентов, даже если прямая прибыль от самого открытого ядра отсутствует.
 \end{itemize}

-2. Как рассчитать рентабельность open-source проекта?
-Классический расчёт ROI неприменим. Необходима адаптированная методика, включающая:
+Таким образом, отрицательный финансовый результат в нашем расчёте — это не свидетельство «бесполезности» проекта, а отражение того факта, что мы рассматривали его изолированно, в отрыве от более широкого контекста, где создаются основные выгоды.
+
+Дополнительный ракурс анализа даёт классификация рисков, предложенная К. Поппом в его фундаментальном руководстве по коммерческому использованию open source \cite{popp_best_practices_2015}. Попп выделяет четыре категории рисков, которые необходимо учитывать при попытке построить бизнес на открытом коде. Применим эту классификацию к нашему проекту:
+
+\begin{itemize}
+	\item Операционный риск — отсутствие формальных коммерческих услуг (поддержки, гарантированного времени реакции, соглашений об уровне обслуживания) снижает привлекательность продукта для корпоративных заказчиков. В нашем расчёте это проявилось в крайне низкой прогнозируемой конверсии пользователей в платящих клиентов (1,5\% в реалистичном сценарии). Корпоративные заказчики, привыкшие к SLA и гарантиям, не готовы полагаться на «энтузиазм сообщества» в критических инфраструктурах.
+	\item Коммерческий риск — лицензия GPL, под которой распространяется архиватор, не препятствует монетизации через поддержку, но блокирует возможность встраивания кода в проприетарные продукты. Это автоматически исключает из потенциального рынка всех независимых производителей ПО, которые могли бы использовать библиотеку сжатия в своих коммерческих приложениях, если бы она была доступна под более либеральной лицензией (например, MIT или Apache). Рынок ограничивается только теми компаниями, которые готовы либо открывать свои наработки, либо приобретать коммерческую лицензию (если бы таковая предлагалась).
+	\item Риск лицензионных атрибутов - даже если текущая модель (поддержка) соответствует GPL, при попытке расширения бизнеса, например, создания SaaS-версии (облачного сервиса сжатия), могут возникнуть сложности. GPL требует раскрытия исходного кода при распространении, но в SaaS-модели распространения как такового не происходит, и возникает так называемая «ASP-лазейка» (Application Service Provisioning loophole), которую закрывает только AGPL. Разработчику необходимо заранее продумать, какая лицензия будет использоваться, чтобы не столкнуться с неожиданными ограничениями в будущем.
+	\item Патентный риск - для нашего архиватора, использующего алгоритм DEFLATE, который является общеизвестным (описан в RFC 1951) и сроки действия основных патентов на него истекли, этот риск минимален. Однако в общем случае использование open source компонентов может нести потенциальные патентные претензии, особенно в быстроразвивающихся областях (кодеки, беспроводные протоколы).
+\end{itemize}
+
+Осознание этих рисков подводит нас к ключевому вопросу: можно ли вообще получить деньги от open-source проекта, и если да, то как?
+
+Ответ на этот вопрос необходимо формулировать в два этапа.
+
+\textbf{1. Можно ли получить деньги с open-source проекта?}
+
+Да, безусловно, можно, но не через прямую продажу лицензий на само ядро (в классическом понимании). Мировая практика выработала несколько устойчивых моделей монетизации, которые успешно применяются десятками компаний \cite{palark_monetization, wikipedia_business_models}:
+
+\begin{itemize}
+	\item Платная поддержка и консалтинг — именно эта модель была использована в наших расчётах. Как показал анализ, в чистом виде она недостаточна для достижения безубыточности: для покрытия годовых операционных затрат требуется не менее 20 контрактов поддержки, тогда как реалистичный прогноз даёт лишь 1,5 контракта. Это подтверждает тезис о том, что модель поддержки эффективна либо для проектов с очень большой пользовательской базой, либо в сочетании с другими подходами.
+	
+	\item Модель Open Core — применительно к архиватору это означало бы, что консольная утилита остаётся открытой (GPL), а графический интерфейс, планировщик задач, облачная синхронизация или интеграция с корпоративными системами становятся платными расширениями. Такой подход позволил бы привлечь корпоративных пользователей, не готовых работать из командной строки, и получать доход, не затрагивая открытое ядро.
+	
+	\item SaaS (ПО как услуга) — создание веб-сервиса для сжатия файлов с платными тарифами (по объёму, скорости, дополнительным функциям). Эта модель особенно привлекательна для пользователей, которые не хотят самостоятельно устанавливать и администрировать ПО. Для архиватора можно реализовать как простое веб-приложение с загрузкой файлов, так и API для разработчиков, встраивающих сжатие в свои приложения.
+	
+	\item Краудфандинг и спонсорство — если проект станет популярным в сообществе, он может получать финансирование через платформы Open Collective или GitHub Sponsors. Это не замена коммерческим моделям, но источник средств для покрытия инфраструктурных расходов или оплаты работы ключевых разработчиков.
+\end{itemize}
+
+Важно понимать, что эти модели не исключают друг друга. Многие успешные проекты комбинируют несколько подходов: например, предлагают бесплатную версию (Open Core), платную поддержку и облачный хостинг (SaaS). Это позволяет диверсифицировать доходы и охватить разные сегменты пользователей.
+
+\textbf{2. Как правильно рассчитать рентабельность open-source проекта?}
+
+Классический расчёт ROI, основанный на сопоставлении прямых денежных притоков и оттоков, в чистом виде неприменим, поскольку игнорирует ключевые нематериальные выгоды, ради которых, собственно, и затеваются многие открытые проекты. Необходима адаптированная методика, включающая следующие компоненты:
+
 \begin{enumerate}
-	\item Расчёт «затратной» компоненты: По классической схеме (CAPEX, OPEX), как было проделано в п. 2.2.
-	\item Оценка «доходной» компоненты: Не как прогноз продаж, а как многокритериальная модель, учитывающая:
+	\item Расчёт «затратной» компоненты - он выполняется по классической схеме: определение капитальных затрат (CAPEX) и операционных расходов (OPEX). Именно это было проделано в разделе 2.2. Затратная часть остаётся объективной и обязательной для понимания минимальных ресурсов, необходимых для создания и поддержки продукта.
+	
+	\item Оценка «доходной» компоненты - здесь требуется перейти от простого прогноза продаж к многокритериальной модели, учитывающей:
 	\begin{itemize}
-		\item Денежные потоки от гибридных моделей (Open Core, SaaS).
-		\item Экономию на рекламе и найме за счёт репутации.
-		\item Накопление человеческого капитала (рост стоимости часа разработчика).
-		\item Социальный и экосистемный вклад, который, как показывают макроэкономические исследования, может в десятки раз превышать прямые затраты на разработку \cite{habr_oss_value_2024}.
+		\item Денежные потоки от гибридных моделей - как показано выше, это могут быть поступления от поддержки, продажи проприетарных расширений, подписки на SaaS, донаты. В нашем расчёте мы ограничились только поддержкой, но реальная доходная часть могла бы быть шире. Необходимо прогнозировать несколько сценариев с разной комбинацией моделей и оценивать вероятные денежные потоки по каждой.
+		\item Экономию на рекламе и найме - успешный open-source проект сам по себе является мощным маркетинговым инструментом. Компания-разработчик может существенно экономить на привлечении клиентов и сотрудников, поскольку сообщество генерирует «сарафанное радио», а лучшие контрибьюторы со временем могут стать ценными кадрами с уже доказанной квалификацией. Эту экономию можно оценить через сравнение с затратами на традиционный маркетинг и рекрутинг.
+		\item Накопление человеческого капитала - участие в разработке повышает квалификацию команды. Для индивидуального разработчика это выражается в росте рыночной ставки («коммиттер-премия»). Согласно данным, приведённым у Рихле \cite{riehle_single_vendor_2012}, разработчики, имеющие статус коммиттера в значимых проектах, могут рассчитывать на прирост зарплаты в размере 20–40 \%. Если разработчик планирует работать в индустрии ещё, скажем, 10 лет, то приведённая стоимость этого прироста может составить сотни тысяч рублей - сумма, сопоставимая с прямыми затратами на разработку.
+		\item Социальный и экосистемный вклад - этот компонент сложнее всего поддаётся количественной оценке, но именно он часто оказывается доминирующим в макроэкономических исследованиях. Например, отчёт Еврокомиссии показывает, что каждый евро, вложенный в развитие open source, приносит обществу 4 евро экономического эффекта за счёт ускорения инноваций, снижения зависимости от конкретных вендоров и повышения прозрачности \cite{eu_report}. Вклад конкретного проекта можно оценить через количество зависимых проектов, сэкономленные часы разработчиков, предотвращённые затраты на лицензии.
 	\end{itemize}
-	\item Расчёт «скорректированной рентабельности»: Сопоставление совокупности выгод (в т.ч. нематериальных) с совокупными затратами.
+	
+	\item Расчёт «скорректированной рентабельности» - итоговый показатель должен представлять собой отношение суммы всех выгод (как денежных, так и оценённых нематериальных) к сумме всех затрат. Формально:
+	\[
+	ROI_{\text{скорр}} = \frac{B_{\text{денежные}} + B_{\text{репутация}} + B_{\text{человеч.капитал}} + B_{\text{экосистема}}}{C_{\text{прямые}} + C_{\text{альтернативные}}}.
+	\]
+	При таком подходе даже проект с отрицательным денежным потоком может оказаться вполне оправданным с точки зрения совокупной выгоды для разработчика или организации.
 \end{enumerate}

+Таким образом, отрицательные цифры, полученные нами, — это не приговор, а сигнал о необходимости расширения модели оценки. Они показывают, что чисто сервисная модель поддержки в данном конкретном случае недостаточна, и проект требует либо комбинирования с другими подходами, либо должен рассматриваться как инвестиция в человеческий капитал и репутацию.
+
 \subsubsection{Сводные показатели и практические рекомендации}

+Для наглядности сведём основные количественные результаты и дадим их интерпретацию с учётом проведённого анализа.
+
 \begin{table}[h!]
 	\centering
 	\caption{Сводные экономические показатели проекта}
 	\label{tab:summary_indicators}
 	\begin{tabular}{|p{0.25\textwidth}|p{0.35\textwidth}|p{0.35\textwidth}|}
 		\hline
-		Показатель & Значение (формальный расчёт) & Интерпретация и рекомендации \\ \hline
-		CAPEX & 307 334 руб. & Может быть снижен до 8-10 тыс. руб. при использовании личного оборудования и бесплатного хостинга. \\ \hline
-		OPEX & 473 000 руб./год & Основная статья — поддержка. Может быть снижена за счет вовлечения сообщества. \\ \hline
-		Годовая выручка & 125 000 руб. & Недостаточна для окупаемости. Необходимо комбинировать модели: добавить Open Core (премиум-функции) и SaaS. \\ \hline
-		Точка безубыточности & 20 контрактов/год & Достижима только при расширении продукта до уровня B2B-решения и активных продажах. \\ \hline
-		ROI & -215\% & Отражает провал данной конкретной финансовой модели, а не бесполезность проекта. \\ \hline
+		Показатель & Значение (реалистичный сценарий) & Интерпретация и рекомендации \\ \hline
+		CAPEX (капитальные затраты) & 307 334 руб. & Может быть снижен до 8–10 тыс. руб. при использовании личного оборудования и бесплатного хостинга (для индивидуального разработчика). В коммерческом сценарии эти затраты необходимо закладывать в бюджет. \\ \hline
+		OPEX (операционные расходы) & 473 000 руб./год & Основная статья — техническая поддержка. При успешном формировании самообслуживаемого сообщества (self-supporting community) эти расходы могут быть существенно сокращены, как показывает практика успешных open-source проектов \cite{riehle_single_vendor_2012}. Рекомендуется активно развивать документацию, форумы и поощрять взаимопомощь среди пользователей. \\ \hline
+		Годовая выручка (только поддержка) & 37 500 руб. & Очевидно недостаточна для окупаемости. Необходимо комбинировать модели: добавить Open Core (продажа премиум-функций) и/или SaaS (облачный сервис с подпиской). Например, можно оставить консольную утилиту бесплатной, а разработать веб-интерфейс с расширенными возможностями (планировщик, интеграция с облачными хранилищами) и продавать к нему доступ. \\ \hline
+		Точка безубыточности & 20 контрактов/год & При текущей модели поддержки это целевой показатель, который достижим только при активных продажах и выходе на корпоративный сегмент. Для сравнения, в модели Open Core точка безубыточности могла бы быть ниже за счёт более высокой цены премиум-лицензий. \\ \hline
+		ROI (классический) & –242\% & Отражает неэффективность изолированной модели поддержки, но не бесполезность проекта как такового. При учёте нематериальных выгод этот показатель может стать положительным. \\ \hline
 	\end{tabular}
 \end{table}

-Итоговые практические рекомендации для разработчика:
+На основе проведённого анализа и обобщения работ Рихле и Поппа можно сформулировать развёрнутые практические рекомендации для разработчика, планирующего создание open-source проекта (в частности, консольного архиватора или аналогичной утилиты):
+
 \begin{enumerate}
-	\item Не рассчитывайте на прямую прибыль от open-source ядра. Рассматривайте его как публичное портфолио и основу для бизнеса.
-	\item Для достижения финансовой устойчивости с первого дня планируйте гибридную модель (напр., Open Core), где премиум-функции закрыты и платны.
-	\item Рассчитывайте рентабельность не как `(Выручка - Затраты) / Затраты`, а как `(Выгоды(денежные + нематериальные) - Затраты) / Затраты`. В эту формулу включайте рост вашей рыночной ставки как разработчика.
-	\item Используйте open-source разработку как стратегию снижения барьеров входа на рынок и проверки гипотез, что в долгосрочной перспективе может оказаться выгоднее традиционной коммерческой разработки \cite{habr_oss_value_2024, gitverse_monetization}.
+	\item Не рассчитывайте на прямую прибыль от открытого ядра. Воспринимайте его как бесплатную визитную карточку, инструмент для привлечения пользователей и формирования сообщества. Основная ценность создаётся не в коде, а в сопутствующих сервисах и дополнительных продуктах.
+	
+	\item С первого дня планируйте гибридную бизнес-модель. Проанализируйте, какие функции могут быть интересны только корпоративным клиентам (управление, безопасность, интеграция, масштабирование), и вынесите их в платную «премиум» версию (Open Core). Как подчёркивает Рихле, продажа «whole product» (целостного продукта, решающего все задачи клиента) является одним из основных источников дохода single-vendor open source компаний \cite{riehle_single_vendor_2012}. Одновременно продумайте возможность предоставления облачного сервиса (SaaS) — многие пользователи готовы платить за готовое решение, избавляющее их от самостоятельной установки и администрирования.
+	
+	\item При оценке эффективности используйте расширенную формулу рентабельности, учитывающую нематериальные выгоды. Включите в расчёт:
+	\begin{itemize}
+		\item прогнозируемый рост вашей рыночной ставки после получения статуса коммиттера («коммиттер-премия»);
+		\item стоимость знаний и навыков, приобретённых в ходе разработки (эквивалентную стоимости специализированных курсов);
+		\item экономию на рекламе и найме, которую обеспечит популярность проекта;
+		\item вклад в экосистему, измеряемый через количество зависимых проектов и предотвращённые затраты других разработчиков.
+	\end{itemize}
+	Эти величины могут быть оценены экспертно или на основе аналогий, но их включение делает анализ более реалистичным.
+	
+	\item Используйте open-source разработку как стратегию снижения барьеров входа на рынок. Выход с проприетарным продуктом требует значительных вложений в маркетинг и «раскрутку». Открытый код позволяет привлечь первых пользователей практически бесплатно, получить обратную связь и постепенно сформировать базу для будущих продаж. Как отмечается в отраслевых дискуссиях, такой подход в долгосрочной перспективе может оказаться выгоднее традиционного \cite{habr_oss_value_2024}.
+	
+	\item Учитывайте множественность мотиваций стейкхолдеров. Успешная стратегия должна балансировать интересы различных участников экосистемы \cite{riehle_economic_2007}:
+	\begin{itemize}
+		\item Для \textit{сообщества разработчиков} создайте понятный и прозрачный путь от пользователя до контрибьютора и, возможно, коммиттера. Люди должны видеть, что их вклад ценится и может привести к росту репутации.
+		\item Для \textit{корпоративных пользователей} делайте упор на снижение совокупной стоимости владения, предоставляйте гарантии и SLA (за плату).
+		\item Для \textit{потенциальных бизнес-партнёров} (интеграторов, вендоров) предлагайте гибкие условия лицензирования и возможность совместного развития продукта.
+	\end{itemize}
+	
+	\item Внедрите элементы open source governance с самого начала. Следуя рекомендациям Поппа \cite{popp_best_practices_2015}:
+	\begin{itemize}
+		\item На \textit{стратегическом уровне} определите приемлемый уровень риска. Например, решите, какие лицензии для сторонних зависимостей вы готовы допустить (только пермиссивные? можно и копилефтные?). Это важно для будущей коммерциализации.
+		\item На \textit{тактическом уровне} настройте автоматическую проверку лицензий всех используемых библиотек. Существуют инструменты (FOSSology, ScanCode и др.), которые могут сканировать код и выявлять лицензионные условия. Это предотвратит случайное включение кода с несовместимой лицензией.
+		\item На \textit{операционном уровне} ведите реестр всех использованных open-source компонентов и их лицензий. Это не только требование многих лицензий, но и необходимая база для due diligence, если в будущем проект заинтересует инвесторов или покупателей.
+	\end{itemize}
+	
+	\item Активно работайте с сообществом, но сохраняйте контроль над стратегическими решениями. Как показывает модель single-vendor open source, ключевым фактором успеха является создание активного и самообслуживаемого сообщества пользователей, которое помогает друг другу, пишет документацию, сообщает об ошибках. Однако, если вы планируете коммерческое использование, необходимо сохранять авторские права на код и требовать передачи прав на вносимые изменения (или как минимум права на перелицензирование) \cite{riehle_single_vendor_2012}. Это позволит избежать ситуации, когда проект «разветвляется» сообществом в нежелательном направлении.
 \end{enumerate}

-Таким образом, курсовая работа не только провела расчёт по заданной методике, но и выявила её ограничения применительно к open-source, предложив пути адаптации. Это подтверждает достижение цели работы — разработки методики экономического обоснования для малых open-source проектов.
+Таким образом, курсовая работа не только провела расчёт по заданной методике, но и выявила её ограничения применительно к open-source, предложив пути адаптации. Полученные отрицательные финансовые показатели следует интерпретировать не как свидетельство неудачи, а как подтверждение того, что open-source проекты требуют особых подходов к оценке эффективности, учитывающих долгосрочные нематериальные выгоды и множественность интересов участников экосистемы. Это подтверждает достижение цели работы — разработки и апробации методики экономического обоснования для малых open-source проектов.
--- a/sections/theory.tex
+++ b/sections/theory.tex
@ -144,7 +144,8 @@
 	\item[a, b] – эмпирические коэффициенты, зависящие от типа проекта (органический, полунезависимый, встроенный);
 	\item[EMF] (Effort Multiplier Factor) – поправочные коэффициенты, учитывающие атрибуты проекта (надёжность, опыт команды, современность инструментов и др.).
 \end{itemize}
-Несмотря на свою структурированность, прямое применение COCOMO к небольшим open-source проектам затруднено из-за неявного учёта таких факторов, как волонтёрский труд и отсутствие формальных процессов.
+Несмотря на свою структурированность, прямое применение COCOMO к небольшим open-source проектам затруднено из-за неявного учёта таких факторов, к
+ак волонтёрский труд и отсутствие формальных процессов.

 Альтернативой является метод функциональных точек (Function Point Analysis, FPA IFPUG). Вместо строк кода он оценивает объём функциональности, предоставляемой пользователю, через пять типов компонентов: входы, выходы, запросы, файлы и интерфейсы \cite[с. 86]{polyansky_ekonomika_2017}. Метод лучше подходит для проектов с высокоуровневыми требованиями и менее зависит от реализации, однако требует высокой квалификации оценщика и также ориентирован на коммерческую разработку с чётко определёнными границами проекта.

@ -178,13 +179,101 @@

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

+\subsection{Модели монетизации программного обеспечения с открытым исходным кодом}
+
+\subsubsection{Экономический парадокс открытого кода}
+
+Традиционная модель продажи лицензий, основанная на ограничении доступа к интеллектуальной собственности, вступает в прямое противоречие с принципами Open Source, закрепленными в лицензиях семейства MIT, Apache или GNU GPL~\cite{snyk_licenses, osi_definition_2024}. Эти лицензии гарантируют пользователям «четыре свободы»: запускать, изучать, распространять и изменять программу~\cite{gnu_free_software_definition, gnu_four_principles_philosophy}. В таких условиях классическая монетизация через продажу «копий» становится невозможной. Тем не менее, рынок Open Source продолжает расти, привлекая миллиардные инвестиции и порождая компании с многомиллиардной капитализацией~\cite{thenewstack_2025, infoworld_2025}.
+
+Современные методы монетизации сместились от продажи самого кода к продаже сопутствующей ценности, которую невозможно легко скопировать: экспертизы, операционной надежности, удобства эксплуатации и гарантий безопасности~\cite{palark_monetization, wikipedia_business_models}. В 2024–2025 годах наметился четкий тренд на профессионализацию открытых проектов, где разделение на «хобби-проекты» и «профессиональные решения» становится все более выраженным~\cite{infoworld_2025, duckalignment_trends2025}. Ключевым фактором выживания становится не просто качество кода, а наличие жизнеспособной бизнес-стратегии, которая позволяет поддерживать критическую массу разработчиков и обеспечивать безопасность цепочки поставок~\cite{thenewstack_2025, palark_monetization}.
+
+\subsubsection{Теоретические основы экономики открытого ПО}
+
+Для понимания экономических механизмов, лежащих в основе open source, необходимо обратиться к фундаментальным работам в этой области. Йохай Бенклер, профессор Гарвардской школы права, в своей работе «Freedom in the Commons» вводит концепцию «commons-based peer production» — производства, основанного на сотрудничестве равноправных участников в цифровой среде~\cite{benkler_freedom_2003}. Бенклер показывает, что открытое программное обеспечение является наиболее ярким примером новой формы экономической организации, где мотивация участников не сводится к прямому денежному вознаграждению, а включает репутационные, социальные и идеалистические стимулы. Эта теоретическая рамка объясняет, почему тысячи разработчиков добровольно вносят вклад в открытые проекты, создавая колоссальную экономическую стоимость без традиционных рыночных механизмов.
+
+Урсула Хольтгрюве в статье «Articulating the Speed(s) the Internet» дополняет этот анализ социологическим измерением~\cite{holtgrewe_articulating_2004}. Она исследует, как самоорганизованные open source проекты создают особую временную и социальную динамику. Добровольный труд в таких проектах, по ее мнению, основывается на сочетании креативности, обучения и обмена знаниями, что формирует устойчивую экосистему, способную конкурировать с коммерческими разработками. Эти теоретические положения служат базой для понимания того, как open source проекты могут генерировать экономическую ценность даже при отсутствии прямых продаж.
+
+\subsubsection{Классификация бизнес-моделей открытого ПО}
+
+Карл Михаэль Попп в книге «Best Practices for commercial use of open source software» предлагает систематизацию бизнес-моделей, используемых компаниями, которые строят свой бизнес на открытом коде~\cite{popp_best_practices_2015}. Он выделяет несколько основных подходов, которые получили развитие в последние десятилетия. В более ранней работе «Profit from Software Ecosystems» Попп и Мейер рассматривают open source в контексте более широких программных экосистем, анализируя, как компании могут извлекать прибыль, участвуя в них~\cite{popp_meyer_profit_2010}. Дирк Рихле в статье «The Single-Vendor Commercial Open Source Business Model» детально исследует модель, при которой одна компания контролирует разработку открытого продукта и монетизирует его через дополнительные проприетарные компоненты или услуги~\cite{riehle_single_vendor_2012}.
+
+Основываясь на этих работах, а также на современных обзорах рынка, можно выделить следующие ключевые модели монетизации.
+
+\paragraph{Модель профессиональных услуг и поддержки.}
+Одной из наиболее исторически сложившихся и надежных моделей является коммерциализация экспертизы. Компания-разработчик или сервисный интегратор не взимает плату за программный продукт, а продает свое время и знания, необходимые для его успешного внедрения и эксплуатации в корпоративной среде~\cite{palark_monetization, wikipedia_business_models}. Для крупных организаций переход на Open Source связан с высокими операционными рисками. Отсутствие вендорской поддержки в классическом понимании означает, что в случае критического сбоя ответственность ложится на внутреннюю ИТ-команду. Модель платной поддержки решает эту проблему, предлагая бизнесу привычный уровень защиты.
+
+Как отмечает Майк Олсон, основатель Cloudera, в своей лекции в Стэнфорде, построение бизнеса на open source технологиях требует фокуса на услугах для корпоративных клиентов, которые ценят гарантии и операционную надежность выше, чем сам код~\cite{olson_opportunities_2013}. Основным продуктом в сервисной модели является не код, а гарантия времени реакции и восстановления системы, закрепленная в соглашении об уровне обслуживания (SLA). Параметры SLA, такие как время реакции на критический инцидент (обычно от 1 часа для премиум-поддержки), доступность системы на уровне 99,9\% или 99,99\%, превращают открытое ПО в надежный корпоративный актив. Дополнительным источником дохода выступает профессиональное обучение и сертификация, что подтверждается практикой Red Hat, IBM и других вендоров.
+
+\paragraph{Модель «Открытого ядра» (Open Core).}
+Модель Open Core на сегодняшний день является доминирующей для коммерческих компаний, создающих программные продукты на базе открытого кода. Ее суть заключается в разделении продукта на две части: базовое «ядро» (Core), распространяемое под свободной лицензией, и проприетарные дополнения (Extensions), доступные только платным клиентам~\cite{popp_best_practices_2015, riehle_single_vendor_2012}. Ключевым искусством в этой модели является проведение границы между бесплатным и платным функционалом. Если ядро будет слишком слабым, проект не наберет популярности и не сформирует сообщество. Если же ядро будет слишком мощным, у пользователей не будет стимула переходить на платную версию.
+
+Как правило, корпоративные (платные) функции включают в себя инструменты управления и мониторинга (графические панели для администрирования сотен узлов), безопасность корпоративного уровня (интеграция с Single Sign-On, LDAP, Active Directory и расширенный аудит), масштабируемость и отказоустойчивость (модули для автоматического шардирования, гео-репликации и расширенного резервного копирования), а также оптимизацию производительности (специфические алгоритмы сжатия данных или ускорения запросов, не включенные в общую ветку).
+
+Примером успешной реализации этой модели является Nginx. Свободная версия проекта решила проблему C10k и завоевала более 36\% рынка веб-серверов~\cite{wikipedia_nginx}. Это позволило компании Nginx Inc. успешно продавать Nginx Plus — коммерческую версию с расширенными функциями балансировки и мониторинга~\cite{blog_nginx_thanks}. Данные IPO компаний, использующих модель Open Core (Elastic, MongoDB, Mulesoft), демонстрируют впечатляющую финансовую эффективность. Так, Elastic при выходе на IPO в 2018 году имел капитализацию \$2,5 млрд при годовой выручке \$227 млн и среднем чеке \$38 тыс.~\cite{opencoreventures_building}.
+
+Несмотря на финансовый успех, модель Open Core создает внутреннее напряжение в сообществе. Рихле отмечает, что независимые участники часто ощущают, что их волонтерский труд используется для обогащения корпоративного владельца~\cite{riehle_single_vendor_2012}. Это приводит к тому, что независимые участники реже вкладываются в разработку новых функций, ограничиваясь исправлением ошибок в ядре. Более того, агрессивное стремление монетизировать проприетарные части может подтолкнуть сообщество к созданию форка (ответвления) проекта, как это произошло с Nginx после приобретения компанией F5~\cite{slashdot_nginx_quit}.
+
+\paragraph{Программное обеспечение как сервис (SaaS) и облачный хостинг.}
+В эпоху облачных вычислений модель SaaS стала наиболее динамично развивающимся методом монетизации Open Source. По данным исследований, до 67\% организаций, платящих за открытое ПО, делают это ради удобства облачного развертывания~\cite{getmonetizely_balance}. Многие современные системы (ClickHouse, Kafka, Kubernetes) обладают чрезвычайно высоким порогом входа в плане администрирования. Для бизнеса зачастую дешевле платить ежемесячную подписку облачному провайдеру, чем нанимать штат квалифицированных инженеров для поддержания инфраструктуры в режиме 24/7.
+
+Преимущества SaaS для корпоративного заказчика включают снижение капитальных затрат (отсутствие необходимости инвестировать в собственное серверное оборудование), гарантированную безопасность и соответствие (провайдер берет на себя прохождение аудитов SOC 2, ISO 27001, GDPR, что критически важно для финтеха и медицины), мгновенную масштабируемость (возможность расширения ресурсов по клику мышки в ответ на рост нагрузки) и фокус на продукте (команда разработчиков клиента может заниматься бизнес-логикой, а не администрированием инфраструктуры).
+
+Главным вызовом для создателей Open Source в модели SaaS стала деятельность гиперскейлеров (AWS, Google Cloud, Azure). Эти компании могут взять любой популярный проект, имеющий пермиссивную лицензию (например, Apache 2.0), и предложить его как управляемый сервис в своем облаке, не возвращая прибыли и не всегда возвращая код оригинальным авторам. Это привело к появлению защитных лицензий, таких как SSPL (Server Side Public License) или BSL (Business Source License). Хотя они не являются «чистым» Open Source согласно критериям OSI, они позволяют авторам защитить свою бизнес-модель, запрещая облачным провайдерам перепродавать софт как услугу без коммерческих договоренностей. Примеры Elasticsearch и MongoDB показывают, что переход на такие лицензии часто является вынужденной мерой для выживания компании-разработчика.
+
+\paragraph{Платформы коллективного финансирования и микроспонсорство.}
+Для проектов, которые не имеют амбиций стать крупными корпорациями, но являются критическими узлами программной экосистемы (например, библиотеки cURL или Babel), на первый план выходят альтернативные методы финансирования, основанные на сообществе. Бенклер предвидел появление таких механизмов ещё в 2003 году, описывая, как цифровая среда позволяет создавать новые формы финансирования общественных благ~\cite{benkler_freedom_2003}.
+
+Запуск программы GitHub Sponsors в 2019 году стал важным этапом, позволив пользователям напрямую поддерживать индивидуальных разработчиков. Однако более устойчивой формой для командных проектов оказался Open Collective. Эта платформа обеспечивает финансовую прозрачность, позволяя любому участнику видеть, откуда приходят деньги и на что они тратятся. Преимущества Open Collective для проектов включают фискальное спонсорство (возможность принимать деньги от корпораций без необходимости регистрации собственного юридического лица), децентрализацию власти (поддержка сообщества, а не конкретного человека, что снижает риски при уходе основателя) и прозрачность для доноров (компании-спонсоры видят реальный вклад своих денег в проект). Проекты, такие как Webpack (годовой бюджет ~\$83 тыс., наем первого штатного разработчика), Babel (~\$100 тыс.) и cURL (~\$15 тыс.), успешно используют эту модель для обеспечения своей устойчивости.
+
+\paragraph{Государственное финансирование и концепция цифрового суверенитета.}
+В 2024–2025 годах отчетливо проявился новый вектор монетизации — государственные инвестиции в Open Source как в общественное благо. Это связано с осознанием того, что уязвимость в одной открытой библиотеке может парализовать цифровую экономику целой страны. Германия стала первопроходцем, создав Sovereign Tech Fund (STF). Его миссия — укрепление цифрового суверенитета путем финансирования поддержки «невидимой» инфраструктуры: библиотек, протоколов и инструментов разработки~\cite{sprind_sovereigntech, interoperable_eu_stf}. С 2022 года фонд инвестировал более 24,6 миллионов евро в 60+ проектов по всему миру.
+
+Ключевые аспекты этой модели: фокус на обслуживании, а не на инновациях (деньги выделяются не на создание новых «фич», а на исправление багов и аудит безопасности), борьба с «проблемой безбилетника» (государство берет на себя расходы, которые частный бизнес склонен игнорировать, считая их общими) и экономическая эффективность (по оценкам Еврокомиссии, каждый вложенный в Open Source евро приносит 4 евро экономического эффекта)~\cite{opensource_org_stf}. Европейские лидеры призывают увеличить финансирование до 350 миллионов евро на период до 2034 года, чтобы создать надежный технологический фундамент, независимый от иностранных корпораций.
+
+\subsubsection{Российский опыт: специфика и успешные кейсы}
+
+Россия обладает уникальной школой разработки системного ПО, что позволило ряду проектов занять лидирующие позиции на мировом рынке, используя различные стратегии монетизации.
+
+\begin{itemize}
+	\item Postgres Professional: модель Open Core в сегменте СУБД. Компания Postgres Professional, основанная в 2015 году ведущими разработчиками PostgreSQL, является ярким примером трансформации экспертизы в продукт~\cite{tadviser_postgrespro, postgrespro_enterprise}. Их стратегия сочетает активный вклад в международный проект (upstream) с продажей собственной коммерческой версии Postgres Pro Enterprise. Коммерческая версия включает нативные технологии сжатия данных CFS, шифрование TDE, маскирование данных и инструменты горизонтального масштабирования Shardman. Выручка компании в 2023 году выросла на 50\%, достигнув 5 миллиардов рублей. Это доказывает, что в условиях импортозамещения и высоких требований к надежности бизнеса модель «Open Core + Сервис» является максимально эффективной.
+	
+	\item Nginx: от волонтерского кода до сделки на \$670 млн. История Игоря Сысоева и Nginx иллюстрирует классический путь Open Source стартапа. Начав как решение внутренних проблем портала Rambler в 2002 году, Nginx был открыт под пермиссивной лицензией BSD в 2004-м~\cite{wikipedia_nginx}. Монетизация началась лишь через 9 лет с созданием Nginx Inc. и запуском продукта Nginx Plus~\cite{blog_nginx_thanks}. Успех был обусловлен тем, что команда сохранила верность открытому коду, добавляя в коммерческую версию лишь те функции, которые действительно необходимы только крупным предприятиям. Итогом стала покупка компании американской корпорацией F5 в 2019 году за 670 миллионов долларов — одна из крупнейших сделок в истории российского ПО.
+	
+	\item ClickHouse: аналитическая СУБД и облачная стратегия. ClickHouse, созданная в Яндексе для задач Метрики, стала глобальным стандартом в области аналитических СУБД (OLAP)~\cite{dev_clickhouse}. После выделения в отдельную компанию ClickHouse Inc. основным методом монетизации стал ClickHouse Cloud (SaaS). Хотя саму систему можно запустить самостоятельно, сложность настройки шардирования, бэкапов и обеспечения отказоустойчивости заставляет клиентов выбирать облачную версию, где эти задачи автоматизированы.
+\end{itemize}
+
+\subsubsection{Тренды и прогнозы на 2025–2030 годы}
+
+Будущее монетизации Open Source будет определяться тремя ключевыми факторами: безопасностью, искусственным интеллектом и новыми нормами регулирования.
+
+\begin{itemize}
+	\item Искусственный интеллект как драйвер и вызов.
+	ИИ радикально меняет процесс разработки. С одной стороны, AI-ассистенты (GitHub Copilot) ускоряют написание кода, но с другой — они могут наводнить проекты низкокачественными патчами, увеличивая нагрузку на мейнтейнеров~\cite{duckalignment_trends2025}. В плане монетизации 2025 год обещает рост моделей, где AI-функции (например, интеллектуальная оптимизация запросов в СУБД) становятся частью премиальных Open Core пакетов.
+	\item Безопасность цепочки поставок.
+	После инцидентов с закладками (как в случае с xz или Log4Shell) доверие к Open Source стало прагматичным~\cite{infoworld_2025}. Компании все чаще готовы платить за «проверенные» и «подписанные» сборки открытого ПО. Это открывает новые возможности для бизнеса, который специализируется на непрерывном аудите и поставке безопасных репозиториев.
+	\item Регуляторное давление.
+	Введение в Европе Cyber Resilience Act (CRA) заставляет разработчиков Open Source серьезнее относиться к ответственности за свой код. Это создает рыночную нишу для организаций, которые берут на себя юридическую ответственность и помощь в соблюдении комплаенса для открытых проектов, используемых в критической инфраструктуре.
+\end{itemize}
+
+\subsubsection{Выводы по теоретической части и обоснование методики для практического раздела}
+
+Проведённый анализ позволяет сформулировать следующие выводы, являющиеся основой для практического расчёта в Главе 2:
+\begin{enumerate}
+	\item Для оценки алгоритмической сложности разрабатываемого архиватора возможно использование аппарата параметрических моделей (адаптированной COCOMO) на этапе проектирования.
+	\item Структура затрат для open-source проекта будет кардинально отличаться от коммерческого: необходимо рассчитать два сценария — «коммерческий» (полная калькуляция) и «реальный open-source» (учёт только прямых материальных затрат и альтернативной стоимости времени).
+	\item Ключевым экономическим показателем для подобного проекта является не прямая прибыль, а соотношение общественной полезности (ценности) к понесённым затратам. Это требует введения в анализ качественных и косвенных количественных метрик.
+	\item Предлагаемая в работе методика должна быть гибридной: сочетать формальный расчёт для частей проекта, поддающихся оценке (трудозатраты на реализацию ядра), и экспертную оценку для специфических аспектов open-source (стоимость поддержки сообщества, ценность портфолио). При этом выбор модели монетизации (например, Open Core или SaaS) будет определять структуру потенциальных доходов проекта.
+\end{enumerate}
+
+Данный теоретический базис позволяет перейти к практической части работы — экономическому обоснованию разработки конкретного программного продукта с открытым исходным кодом.
+
 \subsubsection{Выводы по теоретической части и обоснование методики для практического раздела}
 Проведённый анализ позволяет сформулировать следующие выводы, являющиеся основой для практического расчёта в Главе 2:
 \begin{enumerate}
 	\item Для оценки алгоритмической сложности разрабатываемого архиватора возможно использование аппарата параметрических моделей (адаптированной COCOMO) на этапе проектирования.
 	\item Структура затрат для open-source проекта будет кардинально отличаться от коммерческого: необходимо рассчитать два сценария — «коммерческий» (полная калькуляция по формуле \ref{eq:cost}) и «реальный open-source» (учёт только прямых материальных затрат и альтернативной стоимости времени).
 	\item Ключевым экономическим показателем для подобного проекта является не прямая прибыль, а соотношение общественной полезности (ценности) к понесённым затратам. Это требует введения в анализ качественных и косвенных количественных метрик.
-	\item Предлагаемая в работе методика должна быть гибридной: сочетать формальный расчёт для частей проекта, поддающихся оценке (трудозатраты на реализацию ядра), и экспертную оценку для специфических аспектов open-source (стоимость поддержки сообщества, ценность портфолио).
+	\item Предлагаемая в работе методика должна быть гибридной: сочетать формальный расчёт для частей проекта, поддающихся оценке (трудозатраты на реализацию ядра), и экспертную оценку для специфических аспектов open-source (стоимость поддержки сообщества, ценность портфолио). При этом выбор модели монетизации (например, Open Core или SaaS) будет определять структуру потенциальных доходов проекта.
 \end{enumerate}

 Данный теоретический базис позволяет перейти к практической части работы — экономическому обоснованию разработки конкретного программного продукта с открытым исходным кодом.