\section{Расчёт экономических показателей разработки программного продукта с открытым исходным кодом} % Глава 2

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

\subsubsection{Формулировка проблемы и постановка целей разработки}
Несмотря на обилие существующих решений для сжатия данных, анализ современного open-source ландшафта, проведённый в отчёте Linux Foundation (Census III), выявляет системную проблему: многие критически важные проекты, включая базовые утилиты, десятилетиями поддерживаются силами 1-2 разработчиков, что создаёт риски для безопасности и устойчивости цифровой инфраструктуры \cite{linux_census3_2024}. Парадокс заключается в том, что при высокой общественной ценности такие проекты не имеют прозрачных экономических моделей, позволяющих оценить реальную стоимость их создания и поддержки.

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

Целью практической части работы является разработка и апробация методики экономического обоснования для малого open-source проекта на примере создания консольного архиватора. Проект следует критериям SMART:
\begin{itemize}
	\item Specific (Конкретная): Разработать консольную утилиту, реализующую алгоритм DEFLATE для сжатия/распаковки отдельных файлов.
	\item Measurable (Измеримая): Достичь степени сжатия, сопоставимой с `gzip -6`, для эталонного набора данных.
	\item Achievable (Достижимая): Реализовать силами одного разработчика средней квалификации за 3 месяца.
	\item Relevant (Значимая): Создать открытый кейс для отработки методики расчёта, актуальной в условиях, описанных Census III.
	\item Time-bound (Ограниченная по времени): Срок полной разработки MVP — 3 календарных месяца.
\end{itemize}

\subsubsection{Анализ целевой аудитории и сценариев использования}
Разрабатываемый продукт позиционируется как учебно-демонстрационный, но его целевая аудитория отражает реальные сегменты потребителей подобных утилит:
\begin{enumerate}
	\item Студенты и начинающие разработчики: Для изучения основ алгоритмов сжатия, работы с файловыми системами и практики разработки на Си/C++.
	\item Системные администраторы и DevOps-инженеры: Для автоматизации резервного копирования и лог-менеджмента в средах, где предъявляются требования к лицензионной чистоте и минимализму зависимостей.
	\item Сообщество open-source: Как потенциальная основа для форка или экспериментальной площадки для тестирования новых модификаций алгоритмов сжатия.
\end{enumerate}

\subsubsection{Формирование требований к минимально жизнеспособному продукту (MVP)}
Минимально жизнеспособная версия продукта (MVP) включает следующий функционал, структурированный по модулям:
\begin{itemize}
	\item Модуль ввода/вывода: Чтение и запись данных из файлов, передача данных через стандартные потоки (stdin/stdout).
	\item Модуль алгоритма сжатия: Реализация алгоритма DEFLATE (LZ77 + кодирование Хаффмана) с одним предустановленным уровнем сжатия.
	\item Модуль интерфейса командной строки (CLI): Обработка аргументов для выбора режима работы (сжатие/распаковка), указания входного и выходного файлов.
	\item Модуль тестирования: Набор unit-тестов для проверки корректности работы ядра алгоритма.
\end{itemize}
Архитектура проекта сознательно упрощена по сравнению с промышленными аналогами (такими как `bzip2` или `xz`) и ориентирована на наглядность реализации и лёгкость оценки трудозатрат.

\subsubsection{Верификация оценки трудозатрат на основе анализа исторических данных аналогов}
Для обоснования реалистичности планируемых трудозатрат был проведён самостоятельный количественный анализ истории разработки трёх классических open-source архиваторов. Методология заключалась в сборе и обработке данных из публичных git-репозиториев с использованием скриптов на основе команд `git log` и `git diff` \cite{git_log_docs}.

\begin{table}[h!]
	\centering
	\caption{Результаты сравнительного анализа истории разработки open-source архиваторов (по данным git-репозиториев)}
	\label{tab:project_analysis}
	\begin{tabular}{|p{0.22\textwidth}|p{0.18\textwidth}|p{0.18\textwidth}|p{0.18\textwidth}|}
		\hline
		Критерий & \texttt{bzip2} & \texttt{xz utils} & \texttt{zstd} \\ \hline
		Период анализа (гг.) & 1997--2023 & 2009--2023 & 2015--2023 \\ \hline
		Общее число коммитов & 180 & > 1000 & > 3000 \\ \hline
		Ориентировочный чистый прирост строк кода* & $\approx$ 16 600 & Значительный & Наибольший \\ \hline
		Выявленная модель разработки & Индивидуальная, с переходом к поддержке сообществом & Распределённая с выделенным мейнтейнером & Промышленная, командная \\ \hline
		Оценка релевантности как аналога & Высокая (базовый кейс) & Умеренная (верхняя граница сложности) & Низкая (промышленный масштаб) \\ \hline
	\end{tabular}
\end{table}
\vspace{5pt}
\noindent \footnotesize{*Расчёт выполнен автором на основе агрегированной статистики git-репозиториев.}

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

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

\begin{table}[h!]
	\centering
	\caption{Оценка трудозатрат на разработку программного продукта}
	\label{tab:labor_estimation}
	\begin{tabular}{|p{0.35\textwidth}|p{0.2\textwidth}|p{0.15\textwidth}|p{0.15\textwidth}|}
		\hline
		Этап разработки & Трудозатраты, час & Ставка, руб./час & Стоимость, руб. \\ \hline
		Анализ требований и проектирование архитектуры & 40 & 1 200 & 48 000 \\ \hline
		Программирование (реализация модулей) & 100 & 1 200 & 120 000 \\ \hline
		Тестирование и отладка & 40 & 1 200 & 48 000 \\ \hline
		Написание документации и подготовка релиза & 20 & 1 200 & 24 000 \\ \hline
		Итого по ФОТ & 200 & {} & 240 000 \\ \hline
	\end{tabular}
\end{table}

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

\subsection{Расчёт экономических показателей разработки программного продукта}

\subsubsection{Расчёт капитальных затрат (CAPEX)}
Капитальные затраты (CAPEX) включают все единовременные инвестиции, необходимые для создания программного продукта. Для проекта, использующего исключительно открытые инструменты, структура CAPEX существенно отличается от типичной коммерческой разработки.

\begin{table}[h!]
	\centering
	\caption{Структура капитальных затрат (CAPEX)}
	\label{tab:capex_structure}
	\begin{tabular}{|p{0.4\textwidth}|p{0.35\textwidth}|p{0.2\textwidth}|}
		\hline
		\textbf{Статья расходов} & \textbf{Основание для расчёта} & \textbf{Сумма, руб.} \\ \hline
		Фонд оплаты труда (ФОТ) & Данные из Таблицы \ref{tab:labor_estimation} & 240 000 \\ \hline
		Лицензионное ПО и инструменты & Используется только open-source стек (NeoVim, GCC, Git, Forgejo) & 0 \\ \hline
		Оборудование (амортизация) & Ноутбук разработчика (80 000 руб.), срок службы 3 года, период разработки 3 мес. (0.25 года). \newline Амортизация: \( \frac{80\,000}{3} \times 0.25 = 6\,667 \) & 6 667 \\ \hline
		Накладные расходы & 15\% от ФОТ (аренда рабочего места дома, интернет, электричество) \newline \( 240\,000 \times 0.15 = 36\,000 \) & 36 000 \\ \hline
		Резервный фонд & 10\% от суммы прямых затрат (ФОТ + Оборудование) на непредвиденные расходы \newline \( (240\,000 + 6\,667) \times 0.10 = 24\,667 \) & 24 667 \\ \hline
		\textbf{ИТОГО CAPEX} &  & \textbf{307 334} \\ \hline
	\end{tabular}
\end{table}

Таким образом, общий объём капитальных вложений, необходимых для запуска проекта, составляет \textbf{307 334 рубля}. Критически важным отличием от коммерческого сценария является нулевая стоимость лицензионного ПО, что напрямую вытекает из философии открытого кода и является ключевым фактором снижения первоначального барьера для входа \cite{raymond_cathedral}.

\subsubsection{Расчёт операционных затрат (OPEX)}
Операционные затраты (OPEX) — это ежегодные расходы на поддержку и эксплуатацию работающего программного продукта после его релиза.

% В подразделе 2.2.2 (Расчёт операционных затрат) ОБНОВЛЕННАЯ ТАБЛИЦА:
\begin{table}[h!]
	\centering
	\caption{Структура годовых операционных затрат (OPEX)}
	\label{tab:opex_structure}
	\begin{tabular}{|p{0.4\textwidth}|p{0.35\textwidth}|p{0.2\textwidth}|}
		\hline
		\textbf{Статья расходов} & \textbf{Метод расчёта} & \textbf{Сумма, руб./год} \\ \hline
		Хостинг и инфраструктура & Использование бесплатного тарифа публичной платформы (GitHub, GitLab). Для сценария с полным контролем: аренда VPS ~500 руб./мес. \cite{gitverse_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
		\textbf{ИТОГО OPEX} &  & \textbf{473 000} (479 000)* \\ \hline
	\end{tabular}
\end{table}
\vspace{5pt}
\noindent \footnotesize{*В расчётах используется вариант с бесплатным хостингом как наиболее типичный для малых проектов \cite{linux_census3_2024}. Стоимость VPS указана для справки.}

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

\subsubsection{Прогнозирование выручки от внедрения продукта}
Для open-source проекта, распространяемого под лицензией GPL, традиционная модель монетизации через продажу лицензий неприменима. В качестве основной модели принята \textbf{модель платной поддержки и консалтинга} для корпоративных пользователей, желающих гарантировать работоспособность и безопасность утилиты в своей инфраструктуре.

\begin{table}[h!]
	\centering
	\caption{Данные для прогнозирования годовой выручки}
	\label{tab:revenue_params}
	\begin{tabular}{|p{0.5\textwidth}|p{0.2\textwidth}|p{0.25\textwidth}|}
		\hline
		\textbf{Параметр} & \textbf{Обозначение} & \textbf{Значение} \\ \hline
		Общий размер целевой аудитории (ИТ-компании малого и среднего размера в РФ) & \( N_{total} \) & 5 000 \\ \hline
		Конверсия в установку/пользование продуктом & \( C_{install} \) & 2\% \\ \hline
		Конверсия пользователей в клиентов платной поддержки & \( C_{active} \) & 5\% \\ \hline
		Среднее количество контрактов в год на пользователя & \( Q \) & 1 \\ \hline
		Средний годовой контракт на поддержку & \( P_{avg} \) & 25 000 руб. \\ \hline
	\end{tabular}
\end{table}

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

\begin{table}[h!]
	\centering
	\caption{Расчётный денежный поток от эксплуатации}
	\label{tab:revenue_calc}
	\begin{tabular}{|p{0.5\textwidth}|p{0.25\textwidth}|p{0.2\textwidth}|}
		\hline
		\textbf{Показатель} & \textbf{Формула расчёта} & \textbf{Значение} \\ \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 \) & \textbf{125 000 руб.} \\ \hline
	\end{tabular}
\end{table}

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

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

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

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

\subsubsection{Адаптация методики для индивидуальной open-source разработки}
Приведённый выше расчёт соответствует формальному «коммерческому» сценарию. Однако для индивидуального разработчика или малой команды энтузиастов экономическая модель кардинально меняется.

\begin{table}[h!]
	\centering
	\caption{Сравнение экономических моделей разработки}
	\label{tab:models_comparison}
	\begin{tabular}{|p{0.3\textwidth}|p{0.3\textwidth}|p{0.35\textwidth}|}
		\hline
		\textbf{Показатель} & \textbf{Формальный коммерческий сценарий} & \textbf{Реальный индивидуальный сценарий} \\ \hline
		CAPEX & 307 334 руб. (полный расчёт) & \textbf{8 000 руб.} (амортизация ПК + энергия) \\ \hline
		ФОТ & 240 000 руб. (рыночная ставка) & \textbf{0 руб.} (альтернативная стоимость времени, труд добровольца) \\ \hline
		OPEX & 473 000 руб./год (включая поддержку) & \textbf{0 руб./год} (поддержка по мере возможностей) \\ \hline
		Выручка & 125 000 руб./год (прогноз) & 0 – 50 000 руб./год (нерегулярные донаты) \\ \hline
		Прибыль & -354 250 руб./год (убыток) & \textbf{Нематериальная выгода} (портфолио, знания, репутация) \\ \hline
	\end{tabular}
\end{table}

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

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

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

\subsection{Анализ эффективности внедрения программного продукта}

\subsubsection{Расчёт точки безубыточности (ТБУ)}
Точка безубыточности определяет минимальный объём продаж, необходимый для покрытия операционных затрат. Для проекта с выручкой от платной поддержки она рассчитывается по формуле:

\begin{equation}
	Q_{\text{ТБУ}} = \frac{C_{\text{пост}}}{P_{\text{ед}} - C_{\text{пер.ед}}},
\end{equation}
где \( C_{\text{пост}} \) — постоянные затраты (OPEX), \( P_{\text{ед}} \) — цена контракта поддержки, \( C_{\text{пер.ед}} \) — переменные затраты на единицу.

\begin{table}[h!]
	\centering
	\caption{Исходные данные для расчёта точки безубыточности}
	\label{tab:breakeven_data}
	\begin{tabular}{|p{0.4\textwidth}|p{0.25\textwidth}|p{0.3\textwidth}|}
		\hline
		\textbf{Параметр} & \textbf{Обозначение} & \textbf{Значение} \\ \hline
		Постоянные затраты (OPEX) & \( C_{\text{пост}} \) & 473 000 руб./год (из Табл. \ref{tab:opex_structure}) \\ \hline
		Цена за единицу (средний контракт) & \( P_{\text{ед}} \) & 25 000 руб. (из Табл. \ref{tab:revenue_params}) \\ \hline
		Переменные затраты на единицу (5\% комиссия) & \( C_{\text{пер.ед}} \) & 1 250 руб. \\ \hline
	\end{tabular}
\end{table}

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

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

\subsubsection{Расчёт срока окупаемости и возврата на инвестиции (ROI)}
Срок окупаемости (PP) и возврат на инвестиции (ROI) рассчитываются для капитальных затрат (CAPEX).

\begin{table}[h!]
	\centering
	\caption{Данные для расчёта срока окупаемости}
	\label{tab:payback_data}
	\begin{tabular}{|p{0.4\textwidth}|p{0.25\textwidth}|p{0.3\textwidth}|}
		\hline
		\textbf{Параметр} & \textbf{Обозначение} & \textbf{Значение} \\ \hline
		Капитальные затраты & CAPEX & 307 334 руб. (из Табл. \ref{tab:capex_structure}) \\ \hline
		Чистая прибыль в год & \( P_{\text{чист.год}} \) & -354 250 руб./год (из Табл. \ref{tab:pnl}) \\ \hline
	\end{tabular}
\end{table}

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

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

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

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

\textbf{Ответ на вопрос курсовой работы формулируется в два этапа:}

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

\textbf{2. Как рассчитать рентабельность open-source проекта?}
Классический расчёт ROI неприменим. Необходима \textbf{адаптированная методика}, включающая:
\begin{enumerate}
	\item \textbf{Расчёт «затратной» компоненты}: По классической схеме (CAPEX, OPEX), как было проделано в п. 2.2.
	\item \textbf{Оценка «доходной» компоненты}: Не как прогноз продаж, а как \textbf{многокритериальная модель}, учитывающая:
	\begin{itemize}
		\item Денежные потоки от гибридных моделей (Open Core, SaaS).
		\item Экономию на рекламе и найме за счёт репутации.
		\item Накопление человеческого капитала (рост стоимости часа разработчика).
		\item Социальный и экосистемный вклад, который, как показывают макроэкономические исследования, может в десятки раз превышать прямые затраты на разработку \cite{habr_oss_value_2024}.
	\end{itemize}
	\item \textbf{Расчёт «скорректированной рентабельности»}: Сопоставление совокупности выгод (в т.ч. нематериальных) с совокупными затратами.
\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
		\textbf{Показатель} & \textbf{Значение (формальный расчёт)} & \textbf{Интерпретация и рекомендации} \\ \hline
		CAPEX & 307 334 руб. & Может быть снижен до 8-10 тыс. руб. при использовании личного оборудования и бесплатного хостинга. \\ \hline
		OPEX & 473 000 руб./год & Основная статья — поддержка. Может быть снижена за счет вовлечения сообщества. \\ \hline
		Годовая выручка & 125 000 руб. & Недостаточна для окупаемости. Необходимо комбинировать модели: добавить Open Core (премиум-функции) и SaaS. \\ \hline
		Точка безубыточности & 20 контрактов/год & Достижима только при расширении продукта до уровня B2B-решения и активных продажах. \\ \hline
		ROI & -215\% & Отражает провал \textit{данной конкретной} финансовой модели, а не бесполезность проекта. \\ \hline
	\end{tabular}
\end{table}

\textbf{Итоговые практические рекомендации для разработчика:}
\begin{enumerate}
	\item \textbf{Не рассчитывайте на прямую прибыль от open-source ядра}. Рассматривайте его как \textbf{публичное портфолио и основу для бизнеса}.
	\item Для достижения финансовой устойчивости с первого дня планируйте \textbf{гибридную модель} (напр., Open Core), где премиум-функции закрыты и платны.
	\item Рассчитывайте рентабельность не как `(Выручка - Затраты) / Затраты`, а как `(Выгоды(денежные + нематериальные) - Затраты) / Затраты`. В эту формулу включайте рост вашей рыночной ставки как разработчика.
	\item Используйте open-source разработку как стратегию снижения барьеров входа на рынок и проверки гипотез, что в долгосрочной перспективе может оказаться выгоднее традиционной коммерческой разработки \cite{habr_oss_value_2024, gitverse_monetization}.
\end{enumerate}

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