Здравствуйте, меня зовут Дмитрий Карловский, и я — профессиональный велосипедист. За всю свою карьеру я сделал кучу велосипедов: больших и маленьких, быстрых и удобных, кривых и прямых. Поэтому для меня довольно дико видеть толковых программистов, делающих большие и сложные приложения, но при этом подключающих к проекту очередной leftpad, вместо того, чтобы написать пару простых строк своими руками. Всему виной сформировавшаяся в среде программистов и поддерживающая сама себя боязнь велосипедов в продакшене.  Для простоты изложения, выделим 3 условные группы программистов. Условные, потому, что между ними нет чёткой границы, а один и тот же человек в разных областях может принадлежать к разным группам. Проследив эволюцию программиста, легко заметить, что сначала у него мало навыков, но нет страха, а по мере обретения навыков появляется и усиливается боязнь велосипедов. Чтобы справиться с этим страхом, нужно разобрать его причины. Новичок и правда не сможет. Ему стоит направить свои усилия на то, чтобы объяснить суть и важность проблем, которые он видит своим свежим взглядом, более опытным коллегам и разработчикам библиотек.  У специалиста скорее всего получится не хуже, если он хорошо разберётся в проблематике и посоветуется с другими специалистами и профессионалами. Профессионал же способен сделать лучше в большинстве случаев, так как уже отлично разбирается в теме и даже имеет навык всестороннего анализа. К сожалению, проконсультироваться ему как правило не с кем, ибо других профессионалов мало, и они занимаются другими темами. А специалистам не хватает кругозора. Обычно автор велосипеда неплохо мотивирован чинить дефекты в своём детище. Но рано или поздно эта мотивация проходит, если делает он это в нерабочее время. И тут сторонняя библиотека, казалось бы, позволяет сэкономить ресурсы, ведь её поддержкой занимаются другие люди, которым не надо платить. Но повлиять на них не представляется возможным, а потому, чтобы успеть к дедлайну, придётся засучить рукава, и починить дефект своими силами, после чего долго и упорно пробивать свой патч в основной репозиторий, без какой-либо гарантии на успех.  Тут та же ситуация, что и с дефектами. Но если с дефектами всем обычно ясно, что их надо чинить, то вот взгляд на направление развития у всех разное. Сторонний разработчик будет развивать свою библиотеку туда, куда нужно ему, а не вам. С той скоростью, которая удобна ему, а не вам. Так что если требуется конкретный вектор развития, то свой велосипед даёт контроль и предсказуемость — два качества, которые для менеджмента куда важнее, чем временные и денежные затраты. Если хочется использовать велосипед за пределами компании, то разрабатывать его придётся либо в свободное от работы время, либо договориться об открытии исходников, что обычно сложнее, но вполне возможно. Ведь компания практически бесплатно получает пиар в среде потенциальных работников, а так же бесплатных бета-тестеров (а то и контрибьюторов, но на это не стоит рассчитывать) в лице других пользователей велосипеда. Тут прежде всего стоит сравнить с альтернативами. Если их нет, то и выбора нет — придётся пилить. Если же альтернативы есть, то тут стоит сравнить в денежном и временном эквиваленте: Также отдельно стоит оценить стоимость перехода со стороннего решения на велосипед, если вдруг выяснится, что какое-то из ограничений более неприемлемо. Часто бывает так, что выгоднее сейчас внедрить стороннее решение, а потом быстро перевести его на свой велосипед, когда (и если) потребуется, чем сейчас тратить время на велосипедостроение. Данная оценка помогает как самому понять стоит ли игра свеч, так и объяснить менеджменту почему стоит написать своё, а не взять чужое (или наоборот). Сомнительно, чтобы велосипед занимал существенную долю проекта. Так что проклинать будут в большей степени за весь остальной код. Так что велосипед надо делать как минимум не хуже. А то и лучше, чтобы ни у кого не было желания заменить его на стороннюю библиотеку или на ещё один велосипед. Для этого нужно: Это нормально, если вам наплевать на проект, над которым работаете. Если же вам не совсем всё-равно, чему посвящаете треть вашего времени за сутки, то придётся отстаивать свою точку зрения. И чем выше ваш статус, тем с большей ответственностью стоит подходить к тому, что говорить. Ведь от вашего голоса зависит не только как будете работать вы, но и как будут работать другие, и куда будет катиться проект в целом. Надеюсь мне удалось показать беспочвенность страхов перед велосипедами. Чем ближе вы к профессионализму, тем более амбициозные велосипеды можете на себя взять. Начинать лучше с велосипедов поменьше, имеющих меньшие риски, но дающие не мало опыта на этом поприще. И с этим портфолио браться за всё более крутые и интересные штуки. Важно только не забывать, что настоящий профессионал не только делает крутые штуки, но и знает когда стоит отказаться от их создания. Поэтому всегда проводите анализ, который и вам даст уверенности, что всё делаете правильно, и менеджмент будет на вашей стороне, и те, кто придут после вас, будут понимать что это за велосипед, зачем он тут, и почему иначе было нельзя. Ну а чтобы помочь вам с анализом сторонних библиотек, я за вечер запилил приложение, позволяющее оценить время нерешения проблем проектов на ГитХабе. Чем больше число, тем хуже у проекта с поддержой, и тем дольше вам придётся ждать решения вашей проблемы. Например: сравнение Angular, VueJS, React и конечно же $mol, на котором этот велосипед и написан. Имейте ввиду, что последняя ссылка одноразовая, так как выкачивание всех открытых проблем Ангуляра выедает все лимиты ГитХаба, что красноречиво показывает, что его мейнтейнеры не справляются с поддержкой монстра, которого породили. Адвокат Дьявола