Окей, раз уж вы проголосовали за да (описывать, как "это можно преодолеть", начнем с первой мне в голову проблемы Телеграм.
Знаете ли вы, что такое спортивное программирование? Веселая, но
бесполезная статья на Лурке вас развлечет, но едва ли поможет погрузиться в бездны отчаяния неподготовленного продакта (менеджера продукта), столкнувшегося со спортивным, aka "олимпиадным", подходом. Наверное, по этой причине столкновения редки, кратковременны и для безболезненного длительного сотрудничества требуется, чтобы продакт был олимпиадниками воспитан. С детства. Намек сочится толстотой такой силы, что разжевывать не нужно ;)
Без обиняков, главная проблема олимпиадников в том, что при реализации практических задач они пилят велосипеды.
Практически все существующие решения их не устраивают. Здесь скорость маловата, здесь метода не хватает, здесь то, се, пятое и десятое. В результате олимпиадники садятся, и пишут низкоуровневый код, идеально (насколько это возможно) решающий конкретную задачу. Самый лоск — сделать свой собственный язык и написать код на нем.
И, конечно же, код не будет задокументирован. Документация для дебилов (нет). Зачем автору кода рассказывать самому себе что за что отвечает? Вы же, за исключением страдающих потерей памяти, не пишете себе инструкции о том, что нельзя включать стиральную машину одновременно с чайником — так как выбьет пробки?
В чем проблема? Амонтильядо Эсперанто.
Получившееся решение не нужно никому, кроме них и кучки таких же гиков.
Разобраться в незадокументированном коде и самописном языке — это отличная задача, на сообразительность, на элитарность, настоящий тест на профессиональную пригодность.
Но это не имеет ни малейшего отношения к практической разработке, когда ты можешь взять на рынке пристойного специалиста и посадить его делать, например, групповые звонки в твоем мессенджере ;)
Кроме того, спортивный подход не развивает сообщество и существующие решения. Грубо говоря, если вы запилили свой сервис на базе давно известной библиотеки, то, с одной стороны, вы сразу подписались под все ее проблемы и риски. Здесь что-то не работает, там нет метода, а вот тут и тут вы поправили код и ваше решение может пригодиться и другим. А еще вы сделали аудит и на 99.9% знаете, что там нет закладок.
А потом вы делаете 200 пуллов в репозиторий, от чего мейнтейнер и комьюнити приходят в ужас, начинают с вами сраться и попутно пилить исправления. В итоге плодами сотрудничества пользуетесь и вы, и сообщество.
Спрос рождает предложение. Без столкновения с проблемами и ограничениями существующих решений, они не будут развиваться. Нет проблемы — нет оптимизации. Основными контрибуторами (теми, кто вкладывает свое время и внимание) в существующие open source решения являются сотрудники коммерческих компаний, Google, например. Им это нужно.
Конечно же, коммерческие компании пилят огромное количество своих собственных решений: языки, базы, субд, операционные системы и так далее. Но это все реально только в условиях:
а) высочайшей задокументированности;
б) высочайшего уровня работы с сообществом и партнерами;
в) кратного превосходства нового решения в плане коммерческого использования.
Кто бы, простите, изучал Swift ("новый" язык для приложений на iOS/MacOS) если бы его использования не давало никаких преимуществ при работе с экосистемой Apple, причем преимуществ чисто коммерческих, в виде экономии времени и стоимости найма разработчиков ;) ?
Телеграм — это олимпиадный, спортивный продукт, построенный маленькой командой, пишущей для себя. По этой (в том числе, ведь она не единственная) причине вы с высокой долей вероятности никогда не попадете в команду разаботчиков Телеграм — так как просто не разберетесь в том, что там понаписано. Некоторым, но лишь некоторым, исключением являются Телеграм-клиенты, но и их разработчики сталкиваются с проблемами и ограничениями "велосипедного" (ладно, олимпиадного) подхода.