Rate this post

.NET Aspire позиционируется как бесплатная платформа с открытым исходным кодом. Однако это заявление заслуживает более внимательного рассмотрения. Более глубокий анализ внутренних компонентов выявляет проприетарный элемент в самом центре системы оркестрации — что поднимает серьёзные вопросы о прозрачности, лицензировании и доверии.

Более пристальный взгляд на среду выполнения Aspire

После создания нового приложения Aspire в Windows и его запуска всё поначалу выглядит нормально. Панель управления запускается корректно, а опыт разработчика соответствует ожиданиям от инструмента с открытым исходным кодом на .NET.

Однако при изучении установленных пакетов NuGet — в частности Azure Hosting App Orchestration Tools — обнаруживается странный исполняемый файл: DCP.exe.

Что это за файл? Почему он там?

Тот же бинарник на macOS

Повторение эксперимента на macOS приводит к тому же результату. Хотя версия Aspire там немного старее, тот же бинарный файл DCP появляется в папке пакетов.

Это поднимает критический вопрос:
Если Aspire — это открытый исходный код, почему он включает закрытый исполняемый файл?

Лицензия рассказывает другую историю

Открытие лицензионного файла, связанного с этим бинарником, выявляет нечто неожиданное:
Microsoft Developer Control Plane.

Условия лицензии ясно дают понять, что это проприетарное программное обеспечение. Соглашение прямо запрещает реверс-инжиниринг, декомпиляцию или дизассемблирование. В нём также содержатся положения о сборе данных, обработке персональных данных и экспортных ограничениях.

Этот бинарник не является открытым исходным кодом.

Ещё более тревожно то, что при установке Aspire не появляется явного запроса на принятие лицензии. Проприетарный компонент бесшумно встраивается в цепочку инструментов.

Что такое DCP?

Документация Aspire описывает DCP (Developer Control Plane) так:

«В основе функциональности оркестрации хоста приложений Azure. Отвечает за оркестрацию всех ресурсов».

Другими словами, это не какой-то необязательный вспомогательный инструмент — он является центральным элементом работы Aspire.

В документации также отмечается, что DCP написан на Go, а не на .NET, чтобы обеспечить глубокую нативную интеграцию с API Kubernetes.

Чего в ней не упоминается:
что этот критически важный компонент является закрытым исходным кодом.

Откуда берётся этот бинарник?

Похоже, что DCP не распространяется через публичный канал NuGet. Вместо этого в файлах проектов Aspire присутствуют ссылки на загрузку пакетов Microsoft Developer Control Plane из приватных источников.

Есть основания полагать, что эти бинарники могут происходить из внутреннего репозитория Microsoft на GitHub, к которому у общественности нет доступа.

Таким образом, цепочка инструментов подтягивает проприетарный бинарник из приватного источника и упаковывает его в Aspire — не предоставляя возможности просмотреть или принять его лицензию.

Опасения по поводу телеметрии и сбора данных

В лицензии упоминаются сбор данных и обработка персональных данных. Согласно комментариям инженеров Microsoft, DCP в настоящее время не собирает телеметрию или данные об использовании.

Слово «в настоящее время» здесь делает очень многое.

Поскольку бинарник закрытого исходного кода, нет практического способа проверить, что именно он делает сегодня — или что он может начать делать в будущем. Если телеметрия будет добавлена позже, у разработчиков не будет никакой видимости того, когда и как это изменение произошло.

А поскольку DCP запускается на машинах разработчиков, эта неопределённость имеет значение.

Является ли это всё ещё «открытым исходным кодом»?

.NET Aspire размещён под эгидой .NET Foundation, которая требует лицензии, одобренные OSI. Формально Aspire этим требованиям соответствует.

Однако на практике он оборачивает проприетарный бинарник в самом центре своей архитектуры.

Это означает:

  • Вы не можете полностью собрать Aspire из исходного кода.

  • Вы не можете провести аудит самой критически важной части его логики оркестрации.

  • Вы не можете форкнуть его в полностью независимую реализацию.

Это растягивает определение «открытого исходного кода» за пределы того, что большинство разработчиков сочло бы разумным.

Озабоченность сообщества и открытые вопросы

Эта проблема уже была поднята публично, в том числе на GitHub. Один из заданных вопросов:

Есть ли планы открыть исходный код Developer Control Plane?

Текущий лицензионный язык наводит на мысль, что Microsoft может позиционировать DCP как будущий коммерческий продукт.

Если это произойдёт, это будет означать, что Aspire фактически является обёрткой вокруг проприетарного ядра, которое позже может стать платным программным обеспечением.

Это был бы классический «rug pull».

Почему ядро написано на Go?

Ещё одна неудобная деталь:
DCP написан на Go, а не на .NET.

Для платформы, позиционируемой как флагманское решение .NET для оркестрации, вынесение самой важной логики в Go-бинарник выглядит противоречиво.

Если .NET должен быть первоклассной платформой для cloud-native инструментов, почему тогда его оркестрационное ядро не реализовано на .NET?

Настоящая ценность Aspire?

Одно из самых проницательных наблюдений из глубокого технического анализа заключается в том, что бинарник DCP может быть самой ценной частью Aspire. Он выглядит значительно более сложным, чем окружающий его C#-код.

В этом свете Aspire начинает выглядеть не столько как платформа с открытым исходным кодом, сколько как тонкая обёртка вокруг закрытого движка.

Лучшее направление вперёд

Вот конструктивное предложение:

  • Открыть исходный код Developer Control Plane.

  • Если Go абсолютно необходим, оставить его на Go — но сделать код публичным.

  • Ещё лучше — реализовать его на .NET.

  • Предоставить документированный, поддающийся аудиту API оркестрации.

Полностью открытый, нативный для .NET движок оркестрации Kubernetes был бы действительно впечатляющим — и гораздо более соответствующим духу .NET Foundation.

Окончательный вердикт

Можно ли сегодня честно назвать .NET Aspire платформой с открытым исходным кодом?

Нет.

Не тогда, когда проприетарный бинарник Microsoft находится в центре его функциональности.
Не тогда, когда разработчики не могут просмотреть, собрать или заменить этот компонент.
Не тогда, когда лицензионные условия тихо связывают компании без явного согласия.

Пока эта проблема не будет решена, трудно рекомендовать Aspire добросовестно.

Microsoft должна прояснить статус Developer Control Plane, опубликовать его исходный код или, по крайней мере, быть прозрачной в отношении закрытой зависимости, встроенной в Aspire.

Прямо сейчас эта ситуация не просто запутанная — она глубоко тревожная.