\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
		Статья расходов & Основание для расчёта & Сумма, руб. \\ \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
		ИТОГО CAPEX &  & 307 334 \\ \hline
	\end{tabular}
\end{table}

Таким образом, общий объём капитальных вложений, необходимых для запуска проекта, составляет 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
		Статья расходов & Метод расчёта & Сумма, руб./год \\ \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
		ИТОГО OPEX &  & 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, традиционная модель монетизации через продажу лицензий неприменима. В качестве основной модели принята модель платной поддержки и консалтинга для корпоративных пользователей, желающих гарантировать работоспособность и безопасность утилиты в своей инфраструктуре.

\begin{table}[h!]
	\centering
	\caption{Данные для прогнозирования годовой выручки}
	\label{tab:revenue_params}
	\begin{tabular}{|p{0.5\textwidth}|p{0.2\textwidth}|p{0.25\textwidth}|}
		\hline
		Параметр & Обозначение & Значение \\ \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
		Показатель & Формула расчёта & Значение \\ \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
	\end{tabular}
\end{table}

Прогнозируемая годовая выручка составляет 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
		Показатель & Формула расчёта & Значение, руб. \\ \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
		Операционные расходы (OPEX) & \( C_{opex} \) (из Табл. \ref{tab:opex_structure}) & 473 000 \\ \hline
		Прибыль до налогообложения (EBIT) & \( EBIT = GP - C_{opex} \) & -354 250 \\ \hline
		Налог на прибыль (20\%)* & \( Tax = 0 \) (при убытке) & 0 \\ \hline
		Чистая прибыль (Net Profit) & \( NP = EBIT - Tax \) & -354 250 \\ \hline
	\end{tabular}
\end{table}
\vspace{5pt}
\noindent \footnotesize{*При расчёте налога на прибыль учитывается, что налогооблагаемая база не может быть отрицательной.}

Как видно из расчётов, проект является убыточным при рассмотрении исключительно прямых финансовых потоков. Годовой убыток составляет 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
		Показатель & Формальный коммерческий сценарий & Реальный индивидуальный сценарий \\ \hline
		CAPEX & 307 334 руб. (полный расчёт) & 8 000 руб. (амортизация ПК + энергия) \\ \hline
		ФОТ & 240 000 руб. (рыночная ставка) & 0 руб. (альтернативная стоимость времени, труд добровольца) \\ \hline
		OPEX & 473 000 руб./год (включая поддержку) & 0 руб./год (поддержка по мере возможностей) \\ \hline
		Выручка & 125 000 руб./год (прогноз) & 0 – 50 000 руб./год (нерегулярные донаты) \\ \hline
		Прибыль & -354 250 руб./год (убыток) & Нематериальная выгода (портфолио, знания, репутация) \\ \hline
	\end{tabular}
\end{table}

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

Вывод 1: Для покрытия затрат проект должен заключать не менее 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
		Параметр & Обозначение & Значение \\ \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}

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

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

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

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

2. Как рассчитать рентабельность open-source проекта?
Классический расчёт ROI неприменим. Необходима адаптированная методика, включающая:
\begin{enumerate}
	\item Расчёт «затратной» компоненты: По классической схеме (CAPEX, OPEX), как было проделано в п. 2.2.
	\item Оценка «доходной» компоненты: Не как прогноз продаж, а как многокритериальная модель, учитывающая:
	\begin{itemize}
		\item Денежные потоки от гибридных моделей (Open Core, SaaS).
		\item Экономию на рекламе и найме за счёт репутации.
		\item Накопление человеческого капитала (рост стоимости часа разработчика).
		\item Социальный и экосистемный вклад, который, как показывают макроэкономические исследования, может в десятки раз превышать прямые затраты на разработку \cite{habr_oss_value_2024}.
	\end{itemize}
	\item Расчёт «скорректированной рентабельности»: Сопоставление совокупности выгод (в т.ч. нематериальных) с совокупными затратами.
\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
	\end{tabular}
\end{table}

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

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