FastStream - это относительно новая блестящая игрушка в руках Python'истов, которая создана специально для работы с брокерами сообщений.
В Python сложилось устойчивое убеждение, что если мы работаем с MQ - то нам нужен Celery, но он слегка устарел. Именно поэтому люди пытаются выкинуть "деда" и затащить вместо него любой новый многообещающий MQ-инструмент. Кроме того, культ Celery настолько силен в умах, что практически все новые библиотеки для работы с MQ пытаются стать его "убийцей" и заменой.
Однако, это не совсем верно. Существует огромный пласт проектов, которым нужен не фреймворк для менеджмента задач, а просто "голый" функционал Kafka/RabbitMQ/NATS/whatever для межсервисного взаимодействия. И все эти проекты вынуждены довольствоваться "сырыми" python-клиентами к своим брокерам, а всю обвязку вокруг этих клиентов писать самостоятельно. FastStream целится как раз в эту нишу.
В рамках статьи я хочу убедить вас, что не Celery мы едины, и для альтернативных инструментов найдется место под солнцем. А также рассмотрим фичи FastStream, которые он привносит в застоявшийся мир MQ-инструментов.
Кто я?
Привет! Я - Никита - создатель Propan и ныне core-developer FastStream. Возможно, вы уже читали мои предыдущие статьи о развитии проекта или даже видели выступление на Podlodka Python Crew #3.
Прошлый раз мы виделись почти год назад, когда FastStream только-только вышел. Поэтому сейчас я хотел бы суммаризировать и опубликовать единым списком преимущества, которые должны убедить вас использовать попробовать FastStream. Проект не стоит на месте и мне есть о чем вам рассказать.
Что FastStream за фреймворк?
FastStream - это python-фреймворк для работы с брокерами сообщений. Он был создан для максимального упрощения разработки event-driven систем.
Если просто - это очень толстый клиент для брокеров, который позволяет вам писать меньше инфраструктурного кода и сконцентрироваться на бизнес-логике ваших приложений. Поэтому гораздо уместнее будет сравнение с aiokafka/aio-pika или Kombu (чьим логическим продолжением и является FastStream). Однако, мы предоставляем дополнительный функционал, напрямую не связанный с кодом, но крайне необходимый для современных систем: автодокументирование проекта, удобство тестирования и Observability из коробки.
Давайте же, наконец, разбираться, зачем FastStream нужен именно вам?
Базовый API
В первую очередь - это очень простой API. На данный момент FastStream поддерживает Kafka, RabbitMQ, NATS и Redis в качестве брокера сообщений (список постоянно растет, на текущий момент у нас 8 Issues от комьюнити на поддержку новых брокеров).
Фреймворк предоставляет как унифицированный способ взаимодействия с брокерами, так и специфичные для каждого из них методы. Типичный эндпоинт для сообщений с использованием FastStream выглядит следующим образом:
from faststream import FastStream
from faststream.rabbit import RabbitBroker
broker = RabbitBroker("amqp://guest:guest@localhost:5672/")
app = FastStream(broker)
@broker.subscriber("test-queue") # название очереди RMQ
async def handle(msg: str):
print(msg)
Запускается это все тоже донельзя просто:
faststream run main:app
Данный синтаксис работает для всех поддерживаемых брокеров и отличается разве что импортами.
Основное преимущество FastStream перед "сырыми" клиентами в данном аспекте - это декларативный синтаксис. Мы переходим от написания императивщины ("подключись к X", "создай очередь", "создай потребителя", "привяжи к потребителю функцию") к декларативному "мне нужен подписчик для X". Также все вопросы сериализации/десериализации сообщений FastStream берет на себя - он приводит тело сообщения к запрашиваемому в аннотации типу с помощью pydantic.
Как видите, процесс создания потребителей максимально упрощен относительно привычных MQ библиотек и напоминает другой очень популярный Python фреймворк.
Дальше предлагаю разобраться с тем, какие преимущества мы получаем помимо "сахара над сахаром".
Вдохновение для FastStream
Как я уже сказал, FastStream не стремится быть копией/заменой Celery, а кроме него у нас были только "сырые" клиенты. Получается, среди MQ инструментов вдохновения мы не найдем.
Но мы нашли его среди популярных HTTP-инструментов! А именно - FastAPI. Этот фреймворк в свое время показал, каким требованиям должен отвечать современный инструмент. Давайте же их перечислим:
Интуитивно понятный API
Сериализация данных на основе аннотации типов
Автоматическая документация
Удобное тестирование
Ничего из этого у нас не было в MQ мире до этого. Теперь есть!
И если с первыми двумя пунктами мы уже разобрались, то давайте посмотрим на остальные фичи.
Автоматическое документирование
Документация в текущих реалиях крайне важна для проекта. Как вы передадите в смежную команду контракты, которые ожидает ваш сервис? Как будете взаимодействовать с тестировщиками? На что будет смотреть новый член команды при онбординге?
Для HTTP сервисов решение существует давно - OpenAPI + SwaggerUI. А что делать с асинхронными сервисами? Конечно, вы можете написать документацию самостоятельно в том или ином виде, но как тогда поддерживать ее актульность коду?
FastStream решает эту проблему абсолютно прозрачным и привычным способом - он генерирует AsyncAPI спецификацию из кода вашего сервиса. Вы можете разослать полученный файл, разместить его в своей Wiki или просто захостить его HTML представление прямо рядом с сервисом.
Так, для следующего сервиса из одного подписчика и продюсера:
from pydantic import BaseModel
from faststream import FastStream
from faststream.nats import NatsBroker
broker = NatsBroker()
app = FastStream(broker)
class InputData(BaseModel):
data: bytes
class Prediction(BaseModel):
result: float
@broker.subscriber("test-subject")
@broker.publisher("out-subject")
async def handle_prediction(
msg: InputData
) -> Prediction:
predict = model.predict(msg)
return predict
Мы получим следующую страничку, где видны:
адрес брокера, с которым работает система
input очередь и ожидаемый формат данных
output очередь и формат предоставляемых данных
Тестирование сервиса
Вопрос с тестированием асинхронных сервисов стоит особенно остро. Безусловно, мы можем тестировать бизнес-логику (если достаточно качественно декомпозировали код), но что делать с контрактами? Поднимать брокер каждый раз в CI и тестировать на реальной внешней зависимости?
С HTTP клиентами все просто - мы мокаем транспорт и отправляем вместо реального запроса его эмуляцию "в памяти". Почему бы не сделать то же самое для брокеров сообщений? Тем более, что Kombu уже имел такой функционал. Жаль, что про старика все забыли.
Так, тесты на сервис из первого примера будут выглядеть следующим образом:
import pytest
from pydantic import ValidationError
from faststream.rabbit import TestRabbitBroker
@pytest.mark.asyncio()
async def test_correct():
async with TestRabbitBroker(broker) as br:
await br.publish("Hi!", "test-queue")
@pytest.mark.asyncio()
async def test_invalid():
async with TestRabbitBroker(broker) as br:
with pytest.raises(ValidationError):
await br.publish(1, "test-queue")
При этом все взаимодействи будет происходить "в памяти", что обеспечивает простоту и воспроизводимость тестирования в CI.
Но если вы хотите переиспользовать те же тесты для реального брокера, то нет ничего проще:
async with TestRabbitBroker(broker, with_real=True) as br:
Observability
Мониторинг системы - это чрезвычайно важный аспект эксплуатации ваших сервисов. Для того, чтобы спать спокойно, пока код работает, вам нужны
Логи
Метрики
Трейсы
Healthcheck'и
На тевущий момент FastStream имеет встроенный функционал для интеграции с любой системой логирования, а также готовое решение для OpenTelemetry, с помощью которого вы можете построить сквозные трейсы по всей вашей системе.
О логировании вы можете прочитать в нашей документации, как и о трейсинге. Я также настоятельно рекомендую заглянуть вот в этот репозиторий (спасибо нашему контрибутору Роману), чтобы посмотреть на готовый пример сервисов и инфраструктуры для того, чтобы получить вот такую красивую картинку ваших трейсов:
Работа над поддержкой Prometheus метрик и удобного API для k8s проб (healthcheck'ов) уже ведется и сейчас это приоритетная задача, так что эпопея с Observability скоро должна завершиться.
Другие фичи
Не хочу пересказывать всю документацию, но тезисно обозначу фичи, что у нас есть:
Декомпозиция приложения через Router'ы
Гибкая система Middlewares
Своя система внедрения зависимостей на базе Depends и Context
CLI с хотрелоадом (а как иначе разрабатывать-то?)
Возможность отключить pydantic и использовать собственный формат сообщений (msgpack, protobuf, avro, etc)
Тесная интеграция с FastAPI
Интеграция с taskiq для плановой публикации сообщений
В общем, у нас есть все для вашей комфортной разработки.
Заключение
В заключение хотелось бы сказать, что большинство задач, решаемые сейчас с помощью Celery могут решаться (и даже эффективнее) с помощью FastStream. Но это не потому что мы - "убийца Сelery", а просто потому что вы воткнули сельдерей туда, где он вам не нужен.
Если вам нужно взаимодействие между сервисами на разных языках и технологиях поверх брокеров - это FastStream.
Если вам нужны асинхронные "задачи" на той же кодовой базе - со всеми их "статусами", мониторингом через flower и тд - вам к Celery и его аналогам.
Вот такой простой вывод, прошу прощение за кликбейтный заголовок :)
Послесловие
Не смотря на свой относительно молодой возраст (релиз был в сентябре 2023), проект уже приобрел некоторую популярность. Все, кто присматривался - уже присмотрелись и стали активно внедрять. Я не вправе заявлять от лица компаний, что они используют наш инструмент, но интерес сообщества подкрепляется следующими фактами:
2000 звезд на GitHub с момента релиза (меньше года)
Больше 100к установок в месяц
Включение в список Top-100 OpenSource Achievements 2023 года
Поддержка развития фреймворка со стороны команд RabbitMQ, NATS и AsyncAPI
Непрекращающийся поток запросов на новые фичи со стороны комьюнити
FastStream показал, каким должен быть современный MQ инструмент - и, надеемся, остальные библиотеки потянутся за нами. Например, создатель pydantic уже анонсировал Roadmap на arq, в котором хочет завезти фичи, которые показали мы.
Вы также можете поддержать наш проект:
[ ] поставив звезду на GitHub
[ ] рассказав о нем своим коллегам и знакомым
[ ] вступив в наше RU-telergram соощество, где можно принять непосредственное участие в обсуждении и проектировании нового функционала фреймворка
Также, если вам интересно будущее проекта, вы можете ознакомиться с нашим Roadmap по этой ссылке:
Комментарии (21)
dimastbk
19.06.2024 15:06Пользуясь случаем, будет поддержка max_workers для Kafka? А то процессами будто накладно масштабироваться.
Propan671 Автор
19.06.2024 15:06Добрый день! Мы можем завезти
max_workersдля конкурентного потребления сообщений из одного топика, но только для ack-first политики потребления. Если мы устанавливаем "ручной" commit, то мы не сможем корректно ставить offset, поэтому тут уже нужно скейлится через consumer-group и горизонтально по воркерам
TyVik
19.06.2024 15:06+1Если честно, то не понимаю как их вообще можно сравнивать. Инструменты ж для разного.
gnomeby
19.06.2024 15:06А отложенное выполнение заданий через время или зависимости делается на стороне брокера, как я понимаю, в вашей архитектуре? То есть по сути только путём включения экспериментальной фичи в RabbitMQ (https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq).
Propan671 Автор
19.06.2024 15:06Отложенное выполнение "заданий" - это к Celery. Мы ничего не знаем и не делаем с заданиями, мы просто публикуем/потребляем сообщения. Если брокер поддерживает такую фичу на публикацию - то мы тоже ее поддерживаем.
Propan671 Автор
19.06.2024 15:06Если слушать - то в доке есть пример интеграции. Если публиковать - то есть syncify враппер, который позволяет делать publish из синхронного кода
vit1251
19.06.2024 15:06+2Кроме того, культ Celery настолько силен в умах, что практически все новые библиотеки для работы с MQ пытаются стать его "убийцей" и заменой.
И у меня подгорает с этих вайтишников, которые с трудом могут написать три строки кода для самостоятельной обработки очереди на нативной библитеке от поставщика, так им подавай зачем-то целый фреймворк.
Вообще проблема лежит не на разработчиках фреймворков и даже не на технологической пропоганде всякой ерунды в Интернете, а на работодателях, которые считают, что чем больше у соискателя подобных пустышек в резюме тем с более опытным программистом они имеют дело. Так сегодня существуют прикладные программисты никогда не спускавшиеся в дебри реализации Python и все глубже идущие на поводу моды и все глубже закапываясь в эту щелуху оберток.
Решить проблему кмк может только серьезная конкуренция самих инструментов, такая которая позволит качественно показать преимущество, но для этого рынок ИТ решений слишком молод и не прекращает непрерывную гонку вперед каждый день. Сегодня Celery, а завтра уже FastStream.
Вернемся к конкуренции, а что же в действительности позволяют все эти инструменты? Самый толковый аргумент, который я слышал, что эти инструменты хорошо протестированы и позволяют быстро переключиться между системами. Вот и выходит, что при возникновении проблемы современный вайтишник идет заменять драйвер, а не разбираться в причинах проблемы. Хорошо известный подход хренак-хренак и в продакшен.
Как можно решить проблему бесконечных оберток? Вводить понятные криетрии оценки: скорость, производительность, удобство разработки, количество отказов, рики для бизнеса в уходе инструмента с рынка и т.д.
В заключении конечно мне скорее всего не удасться вразумить всю эту современную школу, но возможно удасться посеять зерно и ответить не мне, так себе на вопрос, а зачем вы вообще тащите весь этот старый хлам себе в код?
Propan671 Автор
19.06.2024 15:06+2И у меня подгорает с этих вайтишников, которые с трудом могут написать три строки кода для самостоятельной обработки очереди на нативной библитеке от поставщика, так им подавай зачем-то целый фреймворк.
Мне очень понравился ваш тезис и я даже разделяю ваше негодование на тему "вайтишников". Неспособность решить проблему без помощи `pip/npm/whatever install ...` - это боль современного ИТ.
Однако, с остальными вашими тезисами я вынужден не согласиться. Звучит так, будто вы разделяете инструменты только с точки зрения того, как они работают с кодом: "зачем вам эти абстракции, если можно и на клиентах все реализовать?".
Вот только современные инструменты конкурируют не только своим "удобным" API (от которого зависит скорость разработки), надежностью кода и его производительностью. Инструменты конкурируют еще и тем, какой круг задач они позволяют вам решить своим использованием.
Жизненный цикл проекта заключается не только в "написании кода", но и в его тестировании, развертывании, сопровождении и тд. Инструменты, которые закрывают как можно больше число из вышеописанных аспектов - это то, что бизнесу и разработчикам нужно сегодня.
FastStream как раз закрывает потребности не разработчиков по написанию кода, но бизнеса - по всем стадиям развития проекта:
1) Удобный API - написание кода, легче онбординг, дешевле найм и обучение, меньше ошибок на самописных костылях
2) In-Memory тестирование - воспроизводимое поведение, остутствие флакующих тестов, быстрое и безболезненное тестирование в CI
3) AsyncAPI документация - экономим на простоте взаимодействия команд, том же онбординге
4) Готовые рецепты и интеграции для Observability - увеличивает шансы, что кто-то это таки внедрит, что существенно упростит расследование инцидентов, улучшит понимание системы, позволит избежать некоторых аварий
Не случайно в статье всего 1 маленький пример кода - ведь мы говорим не о нем и "абстракциях над абстракциями"
К тому же "абстракции над абстракциями" - это не абсолютное зло. В процессе реализации функционала вашего сервисы вы будете вынуждены написать собственные абстракции, если не берете готовые. Вы уверены, что у вас получится лучше, чем у вендора "готовых абстракций"? Этот вендор скорее всего уже собрал большую часть граблей, которые вы скорее всего прочувствуете на своей шкуре. Просто банально за счет распространенности его проекта и потоку Issues от пользователей, на которые он вынужден реагировать.vit1251
19.06.2024 15:06Инструменты конкурируют еще и тем, какой круг задач они позволяют вам решить своим использованием.
Очевидно речь пойдет не о функциональных возможностях, так как абстракция в лучшем случае сохранит эти возможности, а в худшем сузит предоставляемый API.
Жизненный цикл проекта заключается не только в "написании кода", но и в его тестировании, развертывании, сопровождении и тд. Инструменты, которые закрывают как можно больше число из вышеописанных аспектов - это то, что бизнесу и разработчикам нужно сегодня.
Пойдем от противного. Предположим, что наш разработчик пишет сложный в тестировании код, тяжелый в развертывании и сопровождении. Мне кажется, что мы подходим напрямую к определению "вайтишника" и вот теперь когда мы понимаем, что он это не сделает хорошо, то мы предлагаем решение. Я о этом и говорю.
Вы уверены, что у вас получится лучше, чем у вендора "готовых абстракций"? Этот вендор скорее всего уже собрал большую часть граблей, которые вы скорее всего прочувствуете на своей шкуре.
А тут уже откровенно начинаем говорить о околонулевом опыте "вайтишника". Если этакий специалист не может решить задачу в три строки и тем более сомневается в своем решении, то такому специалисту как-то нужно получать опыт. Стоит ли делать ошибки на бизнес домене или на домене технологическом вопрос открытый.
Просто банально за счет распространенности его проекта и потоку Issues от пользователей, на которые он вынужден реагировать.
Мы все еще говорим о абстракции в три строки или о драйвере. О реализациях драйверов ниже есть отличный пост. Исправлять ошибки в workaround это как я думаю достаточно популярный антипаттерн и рекомендую исправлять оригинальную библиотеку по мере возможности, а не городить очередной лес костылей вокруг.
Propan671 Автор
19.06.2024 15:06+1Простите, я снова вынужден с вами спорить
абстракция в лучшем случае сохранит эти возможности, а в худшем сузит предоставляемый API
Абстракция может не только "сохранить в лучшем случае", но и приумножить. Например, тот же Celery расширяет функциональные возможности голых брокеров (пряча оригинальные, но мог бы и не делать этого)
Предположим, что наш разработчик пишет сложный в тестировании код, тяжелый в развертывании и сопровождении.
Вот вы набрасываете, но не аргументируете. Я спрашиваю - "как вы будете тестировать контракты в асинхронном взаимодействии?". Это не вина разработчика, что он не смог. У него просто нет для этого инструментов
А тут уже откровенно начинаем говорить о околонулевом опыте "вайтишника"
В написанном коде всегда будут ошибки. Не важно, пишете его вы, я или "вайтишник". Если этот код написал разработчик библиотеки, а протестировали его тысячи других пользователей - шанс на ошибку в разы меньше
vit1251
19.06.2024 15:06Абстракция может не только "сохранить в лучшем случае", но и приумножить. Например, тот же Celery расширяет функциональные возможности голых брокеров (пряча оригинальные, но мог бы и не делать этого).
Вы сужаете возможности конкретного драйвера оригинального API и говорите, что это приумножает возможности? Нет, это ограничивает API каждой конкретной библиотеки до какого-то общего (минимально достаточного) уровня.
Сравниваете скорее всего уже не абстракцию над конкретном драйвере, а скорее всего реализации и продаете клиенту уже не драйвер, а менеджер этих драйверов создавая долг в виде, а мы потом определимся с наиболее подходящим, а то и вовсе заменим. История примерно такая же как и с ORM-ами разных сортов.
Как вы будете тестировать контракты в асинхронном взаимодействии? Это не вина разработчика, что он не смог. У него просто нет для этого инструментов.
Если автор не представил асинхронный клиент, то первый разработчик выбравший этот брокер вынуждены его разработать. Если повезет, то предложить автору полученное решение, а дальше дорабатывать его сообществом сколько душе угодно. После чего можно протестировать полученный результат. Вроде проблема всех первопроходцев.
Другое дело, что такой подход создаст конкурентное преимущество другим компаниям, так что такую библиотеку коммерческая компания просто не выпустит в открытый доступ. Речь о рынке и рыночных отношениях, а не о обвинении конкретного исполнителя испытывающего дефицит инструментов, времени и т.д.
Если этот код написал разработчик библиотеки, а протестировали его тысячи других пользователей - шанс на ошибку в разы меньше
Мне пока непонятно почему разработчик сам не может протестировать свою библиотеку. Если она приносит значительные доходы компании, то это будет в обозримом будущем сделано. В противном случае говорим о выброшенных каких-то продуктах с околонулевой поддержкой.
Propan671 Автор
19.06.2024 15:06+3Кстати, интересное замечание насчет
нативной библитеки от поставщика
А вы уверены, что с ними так все хорошо? Давайте пройдемся по ним, чтоли
1) RabbitMQ - тут, слава богу, все хорошо. Есть официальная pika, вот только она синхронная, не везде подойдет. Есть Дмитрий Орлов и его aio-pika - клиент феноменального качества, вот только это обертка над aiormq, который обертка над pamqp.
Какой уровень абстракций вы считаете приемлимым? - Мне не очень понятно
2) Kafka. Ну, тут у нас весело - есть confluent-kafka, которая просто python-биндинги поверх C библиотеки. И падает оно с segfault на каждый чих. Отличная "библиотека от вендора". Есть еще aiokafka - но она же не от вендора, да и не все фичи самой Kafka поддерживает
3) NATS. Еще веселее. nats-py клиент пишет человек из core-команды NATS. Вот только он же пишет и ruby клиент. И язык Python для него не основной. Я нашел МНОГО багов, пока реализовывал поддержку NATS в FastStream поверх этой библиотеки. Часть пофиксили через PR в nats-py, часть получилось обойти на уровне кода. Еще одна прекрасная библиотека от вендора
4) SQS. Тут у нас botocore (синхронный) и aiobotocore (асинхронный) ну и прочие boto3. Это абсолютно непригодные для разработки инструменты, тк банально не имеют ни автокомплитов в IDE, ни проверки типов - это просто классы, которые конструируются в рантайме, поэтому ваш код на момент написания ничего не знает об их поведении
Я не буду продолжать по всем брокерам, просто хочу сказать, что "нативные библиотеки" - это не всегда лучшее решение. В большинстве случаев потом что сам инструмент разрабатывался на одном языке, а клиенты нужны - под все. И у разработчиков вполне может не хватить экспертизы чтобы написать качественный и удобный клиент.vit1251
19.06.2024 15:06А вы уверены, что с ними так все хорошо?
Я достоверно знаю, что все плохо с перечисленными продуктами. Большую часть которых нет смысла использовать. Более того с трудом понимаю зачем мне нужно знать и тащить зависимости и костыли в проект над этими продуктами.
Если бизнесу в действительности переживает за решение, то выясняет с кем имеет дело и какие риски могут возникнуть с этим поставщиком, так меня в свое время смутил подход одной государственной компании заключившей договор(!) с лицензией на брокер очередей. Та еще свистопляска была его установить и использовать. И такое тоже бывает.
RabbitMQ - тут, слава богу, все хорошо.
К сожалению, все плохо с драйвером на С/C++ где течет память и крашится сама библиотека. Сейчас уже не вспомню, но имел некоторое отношение к поиску этих двух проблем. К сожалению, состояние дел на данный момент мне не известно, но надеюсь, что проблему коллегам удалось решить и отправить PR с решением автору.
Какой уровень абстракций вы считаете приемлимым? - Мне не очень понятно
Все это какие-то обертки оберток создающие еще больший зоопарк драйверов. Точно такой же зоопарк в свое время развели вокруг MySQL. Уровень абстракции один это драйвер от поставщика. Все остальное это добавочная стоимость сомнительного качества решающая сомнительные частные задачи каких-то людей. Хотите сделать что-то хорошее - помогите автору улучшить (написать) драйвер к вашему языку.
Kafka. Ну, тут у нас весело - есть confluent-kafka, которая просто python-биндинги поверх C библиотеки. И падает оно с segfault на каждый чих. Отличная "библиотека от вендора". Есть еще aiokafka - но она же не от вендора, да и не все фичи самой Kafka поддерживает
Зачем использовать продукт с ошибкой? Опять же если компетенций достаточно, то почему бы не предложить решение проблемы раз вы используете их продукт? Выходит какая-то потребительская позиция вот они там разработали (саночки возят), а мне только прокатиться разок (денег получить). Если Вы получаете прибыль с продукта, то почему бы не помочь разработчику помогающему вам в этом? Не умеете, то отправьте донат с комментарием (купите подписку, оплатите лицензию), а не городите костыли вокруг.
Я не буду продолжать по всем брокерам, просто хочу сказать, что "нативные библиотеки" - это не всегда лучшее решение. В большинстве случаев потом что сам инструмент разрабатывался на одном языке, а клиенты нужны - под все. И у разработчиков вполне может не хватить экспертизы чтобы написать качественный и удобный клиент.
Нативные библиотек всегда лучшее решение, так как это самая короткая дорога к разработчику без посредников (перекупщиков, переклейщиков наклеек, универсальных решателей проблем и т.д.), которая позволят вносить вклад (исправлять) напрямую контактируя с разработчиком и предоставляя обратную связь. Другой вопрос станет ли разработчик просто так за спасибо вашим соучастником в достижении вашей цели. Скорее всего - нет.
morington
Очень содержательно! Благодарю за материал!