Відстеження активності розробників у Solana дає змогу оцінити реальну життєздатність екосистеми, а не покладатися на маркетингові наративи. Нижче — покрокова методологія збору, фільтрації та інтерпретації даних, яка уникає типових пасток і дає перевірені результати.
Метрики активності розробників: коміти, PR, GitHub Stars
Кожна метрика вимірює різний аспект розробки. Розуміння їхньої природи — перший крок до коректного аналізу.
Коміти
Коміт фіксує зміну в коді. Це найгрубіша одиниця виміру: один розробник може зробити двадцять дрібних комітів на день, інший — один великий щотижня. Тому абсолютна кількість комітів майже неінформативна без додаткової фільтрації.
Практичний підхід: групуйте коміти за унікальними авторами (email або ім'я у Git) і за періодами (місяць, квартал). Звертайте увагу на медіану комітів на розробника, а не на середнє значення — медіана менш чутлива до викидів від ботів або масових міграцій.
Pull Requests
Pull request (PR) відображає пропозицію зміни, яка проходить рев'ю. Це значно якісніша метрика за коміт, бо включає процес обговорення, перевірки та затвердження. Злиті (merged) PR свідчать про реальне внесення в кодову базу, відкриті але незлиті — про активність, яка не дійшла до кінця.
Критерії для аналізу PR у Solana-репозиторіях:
- частка злитих PR від загальної кількості відкритих;
- середній час від відкриття до злиття (час рев'ю);
- кількість унікальних рецензентів на один PR.
GitHub Stars
Stars — це метрика уваги, не розробки. Високий показник свідчить про інтерес спільноти, але не гарантує активної підтримки коду. У контексті Solana Stars корисні для виявлення нових інструментів, які набирають traction, але жодним чином не замінюють коміти чи PR.
Джерела даних: GitHub, Electric Capital, інструменти
Пряма робота з GitHub
GitHub — первинне джерело, але витягувати дані вручну неефективно. Використовуйте GitHub REST API або GraphQL API з фільтрацією за мовою програмування (Rust, TypeScript, Python) та темою репозиторію (solana, anchor, spl).
Базовий запит через GraphQL API дозволяє отримати коміти за репозиторієм із фільтрацією за датою та автором. Для масштабного аналізу екосистеми знадобиться агрегувати дані за десятками репозиторіїв — Solana Labs, Solana Program Library, Anchor, а також сторонні проєкти (Mango, Jupiter, Metaplex тощо).
Обмеження: GitHub API має ліміти на кількість запитів. Для систематичного моніторингу потрібен токен з підвищеними лімітами або локальне дзеркало даних.
Electric Capital Developer Report
Electric Capital публікує щоквартальні звіти про активність розробників у блокчейн-екосистемах. Їхня методологія ґрунтується на ідентифікації унікальних розробників за email-адресами в Git-історії, що дозволяє рахувати людей, а не коміти.
Що варто знати про цей звіт:
- він охоплює тисячі репозиторіїв, але може пропустити невеликі або приватні проєкти;
- класифікація розробників за екосистемами базується на евристиці (які репозиторії домінують у діяльності розробника), тому розробник, який працює з кількома ланцюгами, може бути зарахований до однієї з них;
- дані публікуються з затримкою в кілька місяців.
Спеціалізовані інструменти
Для оперативного моніторингу існують платформи, які агрегують GitHub-дані для блокчейн-проєктів (CryptoFees, Dune Analytics для деяких метрик, Artemis). Проте жодна з них не дає повної картини виключно розробницької активності без ручної калібрування. Найнадійніший результат дає комбінація: власний скрипт для ключових репозиторіїв плюс звіти Electric Capital для контексту.
Оманливі метрики: боти, форки, inactive repos
Це найважливіший розділ для будь-кого, хто приймає рішення на основі даних. Нефільтровані цифри з GitHub можуть вводити в оману системно.
Боти
Бот-акаунти в Git створюють коміти автоматично: залежності (dependabot), CI/CD-пайплайни, генератори документації. У деяких репозиторіях частка бот-комітів сягає 30–40% загальної кількості. Якщо не виключити їх, ви будете вимірювати активність автоматизації, а не людей.
Критерії ідентифікації: акаунти з поміткою [bot] у імені, відсутність іншої діяльності крім автоматичних комітів, однотипні повідомлення комітів (update dependency, chore, docs). GitHub API дозволяє фільтрувати ботів за типом акаунта.
Форки
Форк репозиторію створюється одним кліком і не свідчить про розробницьку активність. Якщо ви рахуєте всі репозиторії зі словом solana у назві, ви захопите тисячі форків, у яких немає жодного коміту поверх оригіналу. Завжди фільтруйте за умовою: наявність щонайменше кількох унікальних комітів після дати форку.
Неактивні репозиторії
Репозиторій із тисячею комітів може бути мертвим останні два роки. Навпаки, свіжий репозиторій із двадцятьма комітами може бути активнішим. Обов'язковий фільтр: дата останнього коміту, дата останнього злитого PR, інтервал між комітами. Репозиторій без активності понад 90 днів варто маркувати як неактивний і аналізувати окремо.
Порівняння з іншими екосистемами
Пряме порівняння кількості розробників між Solana, Ethereum, Polygon чи іншими ланцюгами вимагає обережності через структурні відмінності.
Solana-екосистема концентрується навколо відносно невеликого ядра (Solana Labs, Solana Foundation) та набору великих протоколів (Metaplex, Jupiter, Marinade). Ethereum-екосистема значно більш розпорошена: сотні L2, безліч окремих стандартів (ERC-20, ERC-721, ERC-4337), велика кількість інфраструктурних проєктів. Тому абсолютна кількість розробників у Ethereum вища частково через архітектурну складність самої екосистеми, а не обов'язково через більшу «здоровість».
Коректніше порівнювати не абсолютні цифри, а:
- тренди змін (зростання чи спад квартал до кварталу) — це показує динаміку незалежно від розміру екосистеми;
- щільність активних розробників на ключовий інфраструктурний компонент (наприклад, скільки людей активно працюють над основним клієнтом);
- співвідношення нових розробників (first-time contributors) до тих, хто залишається (retention) — це індикатор здатності екосистеми залучати й утримувати таланти.
Без урахування цих нюансів будь-яке порівняння перетворюється на маніпуляцію числами.
Межі аналізу
Жоден набір публічних метрик не дає повної картини. Варто чітко розуміти, що залишається поза полем зору.
По-перше, закритий код. Значна частина комерційних проєктів у Solana розробляється у приватних репозиторіях. Вони не відображаються в жодних публічних метриках, але формують екосистему не менше, ніж відкриті проєкти.
По-друге, не-Git-активність. смарт-контракти та інфраструктура — це не весь цикл. Дизайн інтерфейсів, дослідження безпеки (аудити часто проводяться поза GitHub), написання специфікацій, управління спільнотою — усе це розробницька робота, яка не фіксується в комітах.
По-третє, якість проти кількості. Тисяча комітів із виправленням форматування коду не дорівнюють одному PR, який усуває критичну вразливість. Метрики активності не вимірюють вплив на безпеку чи продуктивність мережі.
По-четверте, кореляція не є причинністю. Зростання кількості розробників може супроводжувати зростання ціни токена, але це не означає, що одне викликає інше. Обидві змінні можуть реагувати на третій фактор — загальний інтерес до ніші.
Практичний висновок: використовуйте розробницькі метрики як один із кількох сигналів, разом із аналізом TVL, транзакційної активності та якості інфраструктури. Жодна метрика окремо не дає підстави для однозначних висновків.
Якщо ви тільки починаєте знайомство з технічною стороною Solana, рекомендуємо ознайомитися з базовими концепціями у розділі Solana з нуля — це допоможе краще зрозуміти контекст тієї розробки, яку ви відстежуєте.