kmpo-economy-coursework/sections/theory.tex

\section{Материально-техническая база предприятий, оказывающих ИТ-услуги}

\subsection{Программное обеспечение: определение, классификация, особенности open-source}

\subsubsection{Базовые определения и классификация программного обеспечения}
В современной цифровой экономике программное обеспечение (ПО) является ключевым активом и средством производства. Согласно межгосударственному стандарту ГОСТ 19781-90, программное обеспечение определяется как «совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ» \cite[п. 3]{gost_19781_90}. Это определение подчёркивает комплексный характер ПО, включающий не только исполняемый код, но и сопровождающую документацию, что важно для оценки полного объёма работ при его создании.

С функциональной точки зрения тот же стандарт устанавливает классификацию ПО по назначению, выделяя три основные категории \cite[пп. 4, 7, 8]{gost_19781_90}:
\begin{itemize}
	\item Системные программы, предназначенные для поддержания работоспособности системы обработки информации (операционные системы, драйверы, утилиты сопровождения).
	\item Прикладные программы, решающие задачи в определённой области применения (текстовые и графические редакторы, системы управления базами данных, инженерные пакеты).
	\item Программы обслуживания (утилиты), оказывающие услуги общего характера пользователям и обслуживающему персоналу. К этому классу относятся средства архивации, диагностики, управления файлами и другие инструменты для обслуживания системы.
\end{itemize}

Внутри этих категорий, согласно исследованиям, доминирующую роль в инфраструктуре начинают играть решения с открытым исходным кодом \cite{eu_report}.

\subsubsection{Философские и практические основы открытого кода}
Феномен ПО с открытым исходным кодом (Open-Source Software, OSS) базируется на двух взаимодополняющих, но идеологически различных концепциях: «свободное программное обеспечение» (Free Software) и «открытое программное обеспечение» (Open Source).

Концепция свободного ПО, продвигаемая Фондом свободного программного обеспечения (Free Software Foundation, FSF), делает акцент на этических и социальных свободах пользователя. Она определяет свободное ПО через четыре неотъемлемых права: свободу запуска программы с любой целью, изучения и адаптации её исходного кода, распространения точных копий, а также распространения модифицированных версий \cite{gnu_free_software_definition}. Данный подход, сформулированный в 1980-х годах, рассматривает доступ к коду как необходимое условие для контроля пользователя над технологиями.

Более поздняя и прагматичная концепция открытого ПО, формализованная организацией Open Source Initiative (OSI), фокусируется на практических преимуществах открытой модели разработки для качества, безопасности и скорости инноваций. Её критерии, изложенные в The Open Source Definition (OSD), включают свободное распространение, обязательное наличие исходного кода, разрешение на создание производных работ и недискриминационный характер лицензии \cite{osi_definition_2024}.

Несмотря на различия в философском обосновании, на практике набор лицензий, удовлетворяющих определению OSI, почти полностью совпадает с лицензиями, соответствующими критериям FSF. Для целей настоящего исследования, сфокусированного на экономических аспектах, используется термин «open-source software» (OSS) как более распространённый в деловой и академической среде, подразумевая соблюдение как критериев OSD, так и базовых свобод пользователя.

\subsubsection{Основные типы лицензий открытого программного обеспечения}
Юридической основой, регулирующей использование, модификацию и распространение OSS, являются лицензии открытого кода. Они определяют баланс между свободой сообщества и правами авторов. Наиболее распространённые лицензии можно разделить на две основные категории, представленные в таблице 1.

\begin{table}[h!]
	\centering
	\caption{Сравнительная характеристика основных лицензий открытого программного обеспечения}
	\label{tab:oss_licenses}
	\begin{tabular}{|p{0.25\textwidth}|p{0.3\textwidth}|p{0.35\textwidth}|}
		\hline
		Лицензия & Ключевой принцип (тип) & Основные условия и особенности \\ \hline
		\hline
		GNU GPL (General Public License) & Копилефт (Copyleft) & Обязательное лицензирование производных работ на условиях той же лицензии. Гарантирует сохранение открытости всех последующих модификаций. Является основой для многих проектов, включая ядро Linux. \\ \hline
		MIT License & Разрешительная (Permissive) & Предоставляет максимальную свободу при минимальных ограничениях. Позволяет использование, изменение, распространение, в том числе в составе проприетарного ПО, с обязательным сохранением уведомления об авторских правах и лицензии. \\ \hline
		Apache License 2.0 & Разрешительная (Permissive) & Аналогична MIT, но дополнительно содержит явное предоставление патентных прав от contributors пользователям и защиту от патентного троллинга. Также требует сохранения уведомлений об изменениях. \\ \hline
		BSD 2-Clause/3-Clause License & Разрешительная (Permissive) & Краткая лицензия, близкая по духу к MIT. Основное различие в 3-пунктной версии — наличие условия о запрете использования имени авторов для одобрения производных продуктов. \\ \hline
	\end{tabular}
\end{table}

Выбор лицензии имеет прямые экономические последствия. Копилефт-лицензии (GPL) способствуют сохранению экосистемы полностью открытых проектов, но могут ограничивать коммерческое использование в проприетарных продуктах. Разрешительные лицензии (MIT, Apache) обеспечивают максимальную гибкость для бизнеса, позволяя интегрировать код в коммерческие решения, что способствует их широкому распространению в отраслевых стандартах и облачных сервисах \cite{linux_census3_2024}.

\subsubsection{Компрессоры как класс служебных программ (утилит)}
В контексте классификации ГОСТ 19781-90, программы-архиваторы относятся к категории программ обслуживания (утилит). Их основное функциональное назначение — уменьшение объёма данных (сжатие) для экономии дискового пространства и ускорения передачи по сетям, а также упаковка множества файлов в единый архив для удобства хранения и переноса.

Исторически и технологически развитие компрессоров и архиваторов тесно связано с открытым исходным кодом. Классические консольные утилиты, такие как \texttt{gzip} (использующий алгоритм DEFLATE), \texttt{bzip2} и \texttt{xz}, являются стандартными компонентами любой UNIX-подобной системы и распространяются под свободными лицензиями (GPL). Кроссплатформенный архиватор \texttt{7-Zip}, поддерживающий современный формат 7z с высоким коэффициентом сжатия, также является open-source проектом (лицензия LGPL).

С алгоритмической точки зрения, компрессоры реализуют фундаментальные методы сжатия данных:
\begin{itemize}
	\item Алгоритмы словарного сжатия (LZ77, LZ78), которые заменяют повторяющиеся последовательности символов ссылками на их предыдущие вхождения.
	\item Энтропийное кодирование (Алгоритм Хаффмана, Арифметическое кодирование), которое присваивает более короткие коды более частым символам.
\end{itemize}
Наиболее распространённый алгоритм DEFLATE, используемый в форматах ZIP и gzip, комбинирует метод LZ77 с кодированием Хаффмана.

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


\subsection{Состав материально-технической базы и специфика организации труда в ИТ}

\subsubsection{Состав и амортизация основных фондов}
Материально-техническая база (МТБ) современного ИТ-предприятия представляет собой комплекс материальных активов, необходимых для осуществления деятельности по разработке, тестированию и эксплуатации программного обеспечения. К основным фондам традиционно относятся \cite{gost_19781_90}:
\begin{itemize}
	\item Здания и сооружения: офисные помещения, дата-центры.
	\item Вычислительная техника: рабочие станции разработчиков и инженеров, серверное оборудование для сборки, тестирования и развёртывания.
	\item Сетевое и телекоммуникационное оборудование: маршрутизаторы, коммутаторы, системы бесперебойного питания.
	\item Мебель и оргтехника.
\end{itemize}

Срок полезного использования такого оборудования для целей налогового учёта определяется в соответствии с Классификацией основных средств, включаемых в амортизационные группы (утверждённой Постановлением Правительства РФ № 1). Согласно данному классификатору, вычислительная техника (код ОКОФ 330.28.23.23) относится ко Второй амортизационной группе со сроком полезного использования от 2 до 3 лет включительно \cite{postanovlenie_1_amort_groups}, что коррелирует с периодом её морального устаревания в ИТ-отрасли.

Особенностью ИТ-отрасли является высокая доля активов с быстрым моральным устареванием (3-5 лет), таких как серверы и компьютеры. В бухгалтерском учёте, согласно ФСБУ 6/2020, организация вправе выбирать способ начисления амортизации, в том числе линейный или способ уменьшаемого остатка, исходя из характера будущих экономических выгод \cite{fsbu_6_2020}. В налоговом же учёте, наряду с линейным и нелинейным методами, Налоговый кодекс РФ (ст. 259.3) предусматривает возможность применения повышающих коэффициентов к норме амортизации для основных средств, используемых в условиях повышенной сменности, агрессивной среды или имеющих высокую энергетическую эффективность \cite{nk_rf_259_3}.

Таким образом, для быстроустаревающего ИТ-оборудования экономически обосновано применение ускоренных методов амортизации, что важно для корректного вычисления себестоимости разработки и налогового планирования.

\subsubsection{Программные инструменты и экосистема разработки}
Наряду с материальными активами, критически важной частью МТБ является программная экосистема. Согласно глобальному опросу разработчиков Stack Overflow (2025), доминирующими инструментами являются \cite{stackoverflow_survey_2025}:
\begin{itemize}
	\item Среды разработки (IDE): Visual Studio Code (используется 75.9\% респондентов), Visual Studio (29\%), IntelliJ IDEA (27.1\%). Преимущество open-source и условно-бесплатных решений (VS Code) подтверждает общий тренд на снижение лицензионных затрат.
	\item Системы контроля версий и коллаборации: Git как стандарт де-факто, с GitHub как самой желаемой платформой для совместной работы (желаема для 59.3\% против 25.6\% для GitLab и 22\% для Jira) \cite{stackoverflow_survey_2025}.
	\item Языки программирования и инфраструктура: Широкое распространение Python (57.9\%), JavaScript (66\%), а также инструментов контейнеризации и оркестрации (Kubernetes, Docker), что отражает переход к микросервисным и облачным архитектурам.
\end{itemize}
Эта стандартизированная экосистема снижает порог входа в проекты и формирует единую технологическую основу как для коммерческих, так и для open-source команд.

\subsubsection{Типовое рабочее место и операционные затраты}
Типовая рабочая станция для разработки программного обеспечения представляет собой высокопроизводительный компьютер, характеристики которого (производительность процессора, объём оперативной памяти, скорость накопителя) определяются необходимостью одновременной работы со средами разработки (IDE), виртуальными машинами, контейнерами и инструментами сборки проектов. Такое рабочее место требует значительных единовременных капитальных вложений в МТБ. Это соответствует общей тенденции роста инвестиций в основной капитал ИТ-отрасли, которая, согласно данным НИУ ВШЭ, в 2023 году составляла десятки миллиардов рублей и демонстрировала высокие темпы прироста \cite{hse_ict_2023}.

К операционным затратам (OPEX), связанным с МТБ, помимо амортизации, относятся: аренда помещений и облачных мощностей (IaaS, PaaS), оплата лицензий на проприетарное ПО (где оно применяется), расходы на электроэнергию и высокоскоростной доступ в интернет, что является критическим ресурсом для распределённых команд. Данный состав затрат характерен для управленческого учёта в ИТ-проектах и соответствует принципам классификации и калькулирования, описанным в литературе по предмету \cite{isaev_upravl_uchet_2006}.

\subsubsection{Специфика материально-технической базы для open-source проектов}
МТБ проектов, разрабатываемых в парадигме открытого кода, имеет существенные отличия, вытекающие из их философских основ \cite{raymond_cathedral} и экономических моделей.
\begin{itemize}
	\item Смещение затрат с CAPEX на OPEX: Максимальное использование бесплатных open-source инструментов (Linux, Git, VS Code, GCC) и публичной облачной инфраструктуры (GitHub Actions, GitLab CI) минимизирует первоначальные капитальные вложения (CAPEX) в лицензионное ПО, но может увеличивать операционные расходы на облачные сервисы.
	\item Распределённая и удалённая инфраструктура: Модель «базара» по Реймонду изначально предполагает географическую распределённость команды. Это подтверждается данными Stack Overflow: 32.4\% разработчиков работают полностью удалённо, а ещё 29.5\% — в гибридном формате \cite{stackoverflow_survey_2025}. МТБ такой команды — это совокупность личных или корпоративных устройств разработчиков, связанных через интернет, а не централизованный офис.
	\item Сообщество как расширенная МТБ: В open-source проектах тестирование на различных аппаратных и программных конфигурациях часто осуществляется добровольцами из сообщества, что, как отмечалось в Census III, особенно важно для обеспечения совместимости и безопасности \cite{linux_census3_2024}. Таким образом, сообщество выступает как «виртуальный» и масштабируемый тестовый полигон.
	\item Приоритет экосистемы над отдельным инструментом: Успех проекта зависит от интеграции в существующие экосистемы пакетов (npm, PyPI, Crates.io). Census III отмечает растущую зависимость от облачно-специфичных пакетов и компонентов, написанных на memory-safe языках, таких как Rust \cite{linux_census3_2024}.
\end{itemize}

На основании проведённого анализа структуры МТБ, данных об инструментах разработки \cite{stackoverflow_survey_2025} и специфики open-source проектов \cite{raymond_cathedral, linux_census3_2024} можно сформулировать следующие сравнительные характеристики:

\begin{longtable}{|p{0.35\textwidth}|p{0.3\textwidth}|p{0.3\textwidth}|} % Можно слегка подкорректировать ширину
	\caption{Сравнительная характеристика МТБ коммерческой и open-source разработки} \label{tab:mtb_comparison} \\ % Заголовок и метка
	\hline
	Компонент МТБ & Традиционная коммерческая разработка & Типичный open-source проект \\
	\hline
	\endfirsthead % Заголовок на ПЕРВОЙ странице таблицы
	
	\multicolumn{3}{c}{{\tablename\ \thetable{} (продолжение)}} \\
	\hline
	Компонент МТБ & Традиционная коммерческая разработка & Типичный open-source проект \\
	\hline
	\endhead % Заголовок, который будет повторяться на КАЖДОЙ следующей странице
	
	\hline
	\endfoot % Нижний колонтитул таблицы (если нужен)
	
	% Само тело таблицы
	Лицензии на инструменты & Крупные статьи CAPEX (проприетарные IDE, ОС) & Минимальные (доминируют бесплатные OSS-инструменты) \\ \hline
	Инфраструктура разработки & Корпоративные серверы, выделенные линии & Публичные облачные платформы (GitHub, GitLab), интернет \\ \hline
	Рабочее место & Стандартизированная офисная рабочая станция & Личное устройство разработчика, удалённый доступ \\ \hline
	Тестовые среды & Выделенный парк устройств, стенды & Добровольное сообщество, эмуляторы, limited CI/CD \\ \hline
	Ключевые затраты & CAPEX (оборудование, лицензии), OPEX (аренда, зарплата) & OPEX (облачные сервисы, хостинг), альтернативная стоимость времени \\ \hline
\end{longtable}

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

\subsection{Методики экономической оценки разработки программного обеспечения}

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

\subsubsection{Классические модели оценки трудоёмкости: COCOMO и функциональные точки}
Проблема прогнозирования затрат на разработку ПО является одной из центральных в экономике программной инженерии. Исторически сложилось два основных подхода: параметрическое моделирование, основанное на метриках исходного кода, и функционально-ориентированное оценивание.

Наиболее известной параметрической моделью является COCOMO (Constructive Cost Model), разработанная Барри Боэмом. Её базовая форма (COCOMO I) устанавливает зависимость между объёмом кода в тысячах строк (KSLOC) и требуемыми для разработки трудозатратами (в человеко-месяцах) \cite[с. 87]{polyansky_ekonomika_2017}. Формула модели имеет вид:
\begin{equation}
	\text{PM} = a \times (\text{KSLOC})^b \times \prod_{i=1}^{n} EMF_i,
	\label{eq:cocomo}
\end{equation}
где:
\begin{itemize}[nosep, leftmargin=*, labelwidth=1.5em]
	\item[PM] (Person-Month) – оценка трудозатрат;
	\item[a, b] – эмпирические коэффициенты, зависящие от типа проекта (органический, полунезависимый, встроенный);
	\item[EMF] (Effort Multiplier Factor) – поправочные коэффициенты, учитывающие атрибуты проекта (надёжность, опыт команды, современность инструментов и др.).
\end{itemize}
Несмотря на свою структурированность, прямое применение COCOMO к небольшим open-source проектам затруднено из-за неявного учёта таких факторов, как волонтёрский труд и отсутствие формальных процессов.

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

\subsubsection{Структура затрат и калькуляция себестоимости разработки ПО}
Экономическая оценка проекта не ограничивается трудозатратами; она требует учёта полной структуры затрат. В общем виде себестоимость разработки программного продукта (С) можно представить как сумму следующих статей \cite[с. 36-41]{polyansky_ekonomika_2017}:
\begin{equation}
	C = C_{\text{ФОТ}} + C_{\text{соц}} + C_{\text{аморт}} + C_{\text{наклад}} + C_{\text{проч}},
	\label{eq:cost}
\end{equation}
где:
\begin{itemize}[nosep, leftmargin=*, labelwidth=2em]
	\item[$C_{\text{ФОТ}}$] – фонд оплаты труда ключевого персонала (аналитиков, разработчиков, тестировщиков);
	\item[$C_{\text{соц}}$] – страховые взносы и иные обязательные отчисления от ФОТ;
	\item[$C_{\text{аморт}}$] – амортизация оборудования и нематериальных активов (лицензий);
	\item[$C_{\text{наклад}}$] – накладные расходы (аренда, коммунальные услуги, административный персонал);
	\item[$C_{\text{проч}}$] – прочие прямые затраты (лицензии на инструменты, облачные услуги).
\end{itemize}

Для коммерческого проекта расчёт каждой статьи является обязательным. Однако, как показано в подразделе 1.2, для open-source проектов характерно смещение структуры: затраты на лицензионное ПО ($C_{\text{проч}}$) стремятся к нулю, амортизация ($C_{\text{аморт}}$) часто не учитывается при использовании личного оборудования, а накладные расходы ($C_{\text{наклад}}$) минимизируются за счёт удалённой работы \cite{stackoverflow_survey_2025}. Это приводит к тому, что основной статьёй затрат в открытой разработке становится альтернативная стоимость времени разработчиков ($C_{\text{ФОТ}}$), которая в случае волонтёрского участия не имеет прямого денежного выражения.

\subsubsection{Специфика экономической оценки open-source проектов и существующие пробелы}
Экономика свободного и открытого ПО строится на принципиально иных, по сравнению с проприетарной моделью, основаниях \cite[с. 99]{polyansky_ekonomika_2017}. Если классическая модель ориентирована на максимизацию прибыли от продажи лицензий, то open-source проекты часто следуют моделям, основанным на предоставлении сопутствующих платных услуг (поддержка, кастомизация, хостинг), продаже branded-версий или получении грантов.

Классические методики, такие как COCOMO и FPA, создавались для «соборной» модели разработки и не учитывают ключевые особенности «базарной» модели \cite{raymond_cathedral}:
\begin{enumerate}
	\item Асинхронный и распределённый вклад: Трудозатраты складываются из неравномерных усилий множества независимых контрибьюторов, что делает оценку в «человеко-месяцах» некорректной.
	\item Нематериальная мотивация: Весомую часть стоимости составляет мотивация, основанная на репутации, обучении или идеализме («egoboo»), которая не конвертируется напрямую в денежный эквивалент.
	\item Экосистемная зависимость: Стоимость проекта резко снижается за счёт повторного использования существующих открытых компонентов, что отражено в данных Census III о повсеместном использовании языковых пакетов \cite{linux_census3_2024}. Однако это создаёт скрытые затраты на поддержание совместимости и безопасность зависимостей.
	\item Парадокс «критического ресурса»: Как показано в Census III, многие жизненно важные для инфраструктуры проекты поддерживаются 1-2 разработчиками \cite{linux_census3_2024}. С точки зрения классической оценки это «низкозатратный» проект, но с макроэкономической позиции — актив с высокой ценностью и высокими рисками.
\end{enumerate}

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

\subsubsection{Выводы по теоретической части и обоснование методики для практического раздела}
Проведённый анализ позволяет сформулировать следующие выводы, являющиеся основой для практического расчёта в Главе 2:
\begin{enumerate}
	\item Для оценки алгоритмической сложности разрабатываемого архиватора возможно использование аппарата параметрических моделей (адаптированной COCOMO) на этапе проектирования.
	\item Структура затрат для open-source проекта будет кардинально отличаться от коммерческого: необходимо рассчитать два сценария — «коммерческий» (полная калькуляция по формуле \ref{eq:cost}) и «реальный open-source» (учёт только прямых материальных затрат и альтернативной стоимости времени).
	\item Ключевым экономическим показателем для подобного проекта является не прямая прибыль, а соотношение общественной полезности (ценности) к понесённым затратам. Это требует введения в анализ качественных и косвенных количественных метрик.
	\item Предлагаемая в работе методика должна быть гибридной: сочетать формальный расчёт для частей проекта, поддающихся оценке (трудозатраты на реализацию ядра), и экспертную оценку для специфических аспектов open-source (стоимость поддержки сообщества, ценность портфолио).
\end{enumerate}

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