В сообществе есть над чем поработать. Готовы ли вы к этому вызову?
Эта статья - не что иное, как собрание моих мыслей о движении за открытые исходные коды, которым я гордился более двадцати лет. Вы можете не согласиться, расстроиться или отнестись к этой статье с недоверием, но я уверен, что мы наблюдаем смену поколений и отношения в ИТ-сообществе в целом, что не работает в его пользу.
Как все началось
Движение за открытый исходный код и сам термин были созданы группой легенд в Паоло Альто в конце 90-х годов, когда Netscape выпустила исходный код своего браузера Navigator. Оно было ответвлением движения за свободное программное обеспечение (свободное с точки зрения свободы изменения и обмена, а не денежной свободы), которое началось в 80-х годах и началось с запуска проекта GNU Ричардом Столлманом. Вскоре после этого Брюс Перенс и Эрик Рэймонд основали организацию под названием Open Source Initiative, которая занималась пропагандой и продвижением решений с открытым исходным кодом.
Я влюбился в идею OpenSource в возрасте 14 лет, совершенно очарованный возможностью творить, изменять и вносить свой вклад как коллектив, вкладывая личное время и усилия в улучшение своей собственной жизни и жизни других. Учиться у других, обсуждать проблемы или вопросы в IRC и планировать в записных книжках стало реальностью, поскольку не существовало даже программного обеспечения для простого доступа и участия. Прошло 20 лет с тех пор, как был изобретен SVN (дедушка git), и единственной историей изменений, которые у нас были тогда, были FTP-сервер и файл changelog.
Когда дело доходит до сотрудничества, это были действительно тяжелые времена - сегодня вы находитесь на расстоянии нескольких щелчков мышью от идеи до фактического начала работы над ней.
Нажмите - здесь находится репозиторий Github с проектами, проблемами и CI / CD.
Нажмите - там Slack, чтобы обсудить все с членами команды, провести встречи и Получайте все самые свежие новости о ходе выполнения вашего проекта.
Нажмите - вы получите бесплатную учетную запись AWS или GoogleCloud, чтобы дать вашему проекту возможность развлечься, с дополнительными кредитами и бесплатными уровнями.
То, что тогда не приходило к нам даже в малейших мечтах, стало повседневной реальностью, которую на самом деле часто недооценивали и принимали как должное.
Качество OpenSource проектов
Я использую множество проектов ежедневно. Более того, я просматриваю страницы, чтобы принимать обоснованные решения, когда их следует использовать в «вещах, над которыми я работаю». Я на собственном горьком опыте узнал, как дважды проверять частоту коммитов, насколько отзывчивы специалисты по сопровождению, когда дело касается поднятых проблем, насколько они готовы принимать запросы на вытягивание от сторонних участников. Никто не хочет основывать свою тяжелую работу на проекте, который, скорее всего, будет заброшен, верно? В течение прошлого года я ежедневно использую Python, Go и JS, но - я не называю себя разработчиком - я знаю их достаточно, чтобы выполнять свою работу, разбираться в коде, передовых методах и, в целом - заставить вещи работать. Я работал с PHP (да, я вижу эти улыбки даже сейчас) и Ruby в прошлом, что дает мне относительно целостный обзор идей, лежащих в основе языков и возможных решений.
Я не стремлюсь начинать войну со словами «этот язык лучше, чем тот», и все сравнение максимально объективно, без дополнительных предубеждений - точно так же, как вы можете расширить свой кругозор, путешествуя - вы можете проверить, как другие языки справляются с проблемами, которые могут у вас возникнуть, стать языковым агностиком и убедиться, что вы выберете лучший для работы, основываясь на своем мнении по различным факторам.
Легенда приговоров
- Простота использования. Насколько легко выучить язык (не освоить его) и начать использовать с нуля до героя.
- Легкость найма. Если вы начнете работать над проектом, возможно, в будущем вам понадобится нанять кого-нибудь, кто вам поможет. Этот рейтинг основан на проведенных собеседованиях - количестве соискателей и людей, которые могли бы выполнить работу.
- Качество кода с открытым исходным кодом. Есть ли даже ворсинки? Как код соответствует лучшим стандартам и практикам? Легко ли изменить или даже прочитать? Как насчет расширения за счет добавления новых функций? Какова вероятность того, что что-то сломается в следующий раз, когда вы обновите библиотеку / пакет?
- Поддержка открытого исходного кода: насколько вероятно, что авторы проекта примут потенциальную критику, ответят или признают проблемы и отреагируют на новые запросы на вытягивание.
- Документация. Насколько обширна документация? Охватывает ли он все функции и опции? Обновляется ли он после добавления новых функций?
Пусть начнется (дружеский) бой
⭐ NodeJS и JS в целом
Мне это очень нравится, поскольку разработка моего частного проекта перешла с бэкэнда только на фронтенд. Я выбрал Vue.js по рекомендации hipertracker и, как всякий новичок, влюбился в чрезмерно увлеченную установку пряжи. Через некоторое время я обратил внимание на то, что большинство пакетов, которые я устанавливал, не обслуживались, буквально оставлены их создателями с десятками, если не сотнями проблем (и поднятыми запросами на перенос), но без видимого стимула со стороны сторона сопровождающего должна либо проверять, либо объединять исправления и новые функции. Документация, когда дело доходит до них, больше посвящена «проверьте наш код, чтобы узнать», а не ясному и легкому для понимания способу использования .
Я твердо убежден, что эта ситуация вызвана простыми требованиями начального уровня, чтобы стать JS-разработчиком, который, в сочетании с возможностью распространять код по всему миру, представляет собой опасную смесь. Растущая популярность TypeScript определенно повысит качество кода и проектов, хотя на это может потребоваться время.
┌──────────────────────────┬───────┐ │ Ease of use │ 4/5 │ │ Ease to hire │ 5/5 │ │ OpenSource code quality │ 3/5 │ │ OpenSource maintenance │ 2/5 │ │ Documentation │ 2/5 │ └──────────────────────────┴───────┘
⭐ Python
Я не слышал о разработчике, который не знал бы даже немного Python. Он присутствует везде - от простых системных скриптов до обработки больших данных с помощью pySpark, и замыкает список моделирование искусственного интеллекта. Довольно недавний конец жизни 2.7 и принудительный переход на 3.x определенно улучшили общую кодовую базу, и я искренне надеюсь, что владельцы проектов последуют за ней.
┌──────────────────────────┬───────┐ │ Ease of use │ 4/5 │ │ Ease to hire │ 5/5 │ │ OpenSource code quality │ 4/5 │ │ OpenSource maintenance │ 3/5 │ │ Documentation │ 4/5 │ └──────────────────────────┴───────┘
⭐ Go
Относительно новый игрок на рынке, сумевший покорить сердца миллионов разработчиков, ищущих быстрые, масштабируемые решения с повторяющимися сборками (в конце концов - все, что вы получаете, это двоичный файл). Одно из его величайших преимуществ - встроенный сервер документации, которым я лично пользуюсь и злоупотребляю, надеясь, что кто-то позаботится о том, чтобы написать несколько комментариев по поводу своих функций.
┌──────────────────────────┬───────┐ │ Ease of use │ 3/5 │ │ Ease to hire │ 3.5/5 │ │ OpenSource code quality │ 4/5 │ │ OpenSource maintenance │ 3/5 │ │ Documentation │ 4.5/5 │ └──────────────────────────┴───────┘
Закрытое сообщество разработчиков ПО с открытым исходным кодом
Цель этой статьи никогда не заключалась в том, чтобы разрушить сам язык, поскольку я очень заинтересован в развитии любого из упомянутых. Во время любого цикла разработки приложения вам нужно будет полагаться как на документацию, так и на само сообщество. К сожалению, многие создатели библиотек либо отправляют свой код один раз и оставляют его там, где он есть, либо воспринимают любые сообщения об ошибках как персональную атаку.
Я приведу вам пример проекта GENIUS, который я использую уже более года - Overmind.js от Christian Alfoni, который позволяет мне, чтобы работать с состояниями приложения действительно просто и логично. Я даже порекомендовал использовать его разработчикам внешнего интерфейса на работе после того, как показал им свою кодовую базу во время специального сеанса демонстрации вещей. К сожалению, он был отклонен из-за отсутствия технической поддержки, так как в то время он был заброшен на несколько месяцев, а список открытых проблем постоянно увеличивался. При проверке мне показалось, что автор либо сделал длительный перерыв, либо отказался от него, поэтому я решил открыть вопрос с запросом на сопровождение проекта. После некоторого времени без ответа по самой проблеме я решил пинговать автора в Твиттере, поскольку он был там относительно активен - просто чтобы встретить атаки третьих лиц (а не самого автора), отговаривающих меня за то, что я спросил. К счастью, Кристиан быстро вмешался и объяснил, что скоро вернется к самому проекту.
Мало что не лишило меня любви к самому Сверхразуму. Однако я поставил серьезный вопросительный знак о зависимости от него в другом проекте - вопросительный знак, который с тех пор использую как практическое правило для выбора критически важных библиотек.
- Бригады технического обслуживания из одного человека недостаточно. Этого никогда не было и не будет. Слишком много вещей может пойти не так (или, как в жизни Кристиана - слишком хорошо, еще раз - поздравляю! ❤), и большинство из них подвергают другие проекты, в зависимости от этого, серьезному риску.
- Слишком личное восприятие вашего или чужого кода (sic!) удерживает сообщество от того и другого - вносить вклад и поднимать проблемы, а также препятствует использованию вашего продукта.
- Частота коммитов и их среднее время объединения PR в основную ветку, общее общение.
- Обнаружение ошибки в вашем программном обеспечении не является преступлением, и определенно не является личной атакой и не должно рассматриваться как таковое.
Я абсолютно понимаю, что проект может стать младенцем - в конце концов, потратить все эти бесконечные часы и ночи на то, чтобы найти время, чтобы избавиться от досадных ошибок. Кроме того, общение с недовольными пользователями может быть очень нервным. Я был там, и мне удавалось несколько раз грубо отвечать пользователям. Если вы хотите знать, что произошло - мои пользователи ушли и нашли другой проект, работающий аналогично. С тех пор я нашел BeastByte, который стал отвечать за управление сообществом и ежедневную помощь пользователям, что очень хорошо сработало из-за разницы часовых поясов (он живет в Венесуэле и говорит по-английски и по-испански!). Теперь пользователи знают, что могут задать вопрос в любое время дня и ночи. Всегда найдется кто-нибудь, кто их поддержит.
Сохранение открытого исходного кода открытым
Поддержка проекта с открытым исходным кодом может быть настоящей болью. Однако, если к нашей повседневной работе относиться с таким же профессионализмом, это может превратиться в благословение и помочь вам резко повысить популярность и повысить ваши навыки, которые рано или поздно превратятся в предложения о работе, выгодные для обоих. стороны. Я был свидетелем найма людей (да, даже я нанял их) с действительно хорошим портфелем их публичных вкладов, и я знаю немало мест, где ценят такой опыт. Каждый бизнес ищет не только человека, который выполняет свою работу, но и отличного командного игрока. Если вы можете продемонстрировать свой подход к решению проблем, управлению проектами и отличные коммуникативные навыки - при этом делая это бесплатно, потому что вам это нравится - вы автоматически присоединяетесь к самым популярным активам на рынке, как того хочет каждая разумная компания. сражаться за.
О самих проектах - большинство из нас, ботаников, интроверты. Из-за разделения и отсутствия общих человеческих взаимодействий мы иногда принимаем вещи лично, а иногда даже чересчур. Это не делает нас плохими разработчиками, поскольку мы склонны сосредотачиваться на коде и общем результате, а не на доказательстве другой стороны, кто прав и почему это я. Однако это может сделать нас плохими сопровождающими проектами, отталкивая новые таланты и активных участников, желающих тратить свое время и усилия на добавление реальной ценности самому проекту.
Я бы хотел, чтобы проекты с открытым исходным кодом были действительно открытыми, в истинном духе первоначального движения, когда любой, кто мог внести свой вклад, был приглашен сделать это, когда люди делились знаниями или когда всегда был кто-то, кто хотел бы объяснить и научить или ... когда мы все работали вместе, помня о прогрессе, без личных предубеждений и враждебности. Обычно была группа людей (в шутку называемых «старейшинами Интернета»), которые отвечали за поддержку проекта, поддержку участников и анализ их работы, общение со всеми происходило либо через IRC, либо через USENET и позволили как на долгое время дружить, так и обмениваться дополнительными идеями, что, очевидно, привело к появлению еще большего количества замечательных проектов, которые мы все используем сегодня.
Бизнесы, чтобы показать пример
Проработав несколько лет на службе у Ее Величества, работая с различными технологиями и множеством проектов, я понял, что делиться хорошо или даже желательно. Многие проекты в правительстве Ее Величества являются публичными, и запросы на вытягивание от третьих лиц принимаются в духе » Кодекса государственной службы - честности, объективности и беспристрастности. Британское правительство действительно прокладывает путь для бизнеса, демонстрируя, как все может быть сделано в идеальном мире, где мнение каждого имеет значение, а все усилия сосредоточены на общем благе.
Многие частные компании присоединяются к open-source движение, которое работает для них обоих - они получают бесплатные взносы на свой продукт, который обычно предлагается (с дополнительными функциями, конечно) на основе Enterprise или подписки. Просто гениальный подход, привносящий дух «совместное использование - забота в коммерциализированный мир, используемый в настоящее время nats.io, Hasura, Portainer.io , micro.mu и множество других компаний работают лучше, чем те, которые держат все под замком и, что наиболее важно, крадут сердца своих будущих клиентов до того, как конкуренты смогут даже отправить им свои предложения.
Что там делать
Я хотел бы закончить эту статью списком шагов, которые можно было пропустить между строк.
- Держите код открытым, даже если он не самого высокого качества - есть шанс, что кто-то начнет его использовать и предложит улучшения, которые позволят вам и / или вашим инженерам учиться и открывать свои мысли.
- Не принимайте лично вопросы, поднятые третьими сторонами. Вместо этого будьте счастливы, что кто-то в мире достаточно ценит вашу работу, чтобы использовать ее и тратить свое время, обращая ваше внимание на ошибки, вместо того, чтобы переключаться на другой продукт.
- Чтобы все соответствовало первоначальным целям - подумайте о создании общедоступной дорожной карты со списком функций для новой версии - есть шанс, что кто-то извне выберет ее и поможет вам с работой и идеями.
- Создайте сообщество вокруг своего проекта, убедитесь, что все приветствуются, все мнения услышаны и на все вопросы даны ответы (подсказка: «google it» не является ответом на технический вопрос).
- Участвуйте в других проектах, принимайте участие в обсуждениях и не бойтесь поднимать вопросы - хотя все виды общения должны быть позитивными и уважительными, как если бы вы поступали со своими коллегами.
~ Интернет должен быть бесплатным, как и большая часть вашего кода. * ~
* Относится к критически важному для бизнеса программному обеспечению и логике.
