Я не вижу ничего плохого в том, чтобы активно использовать различные HTTP статусы и связывать их с бизнес логикой приложения. Если вы делаете REST API, такой подход будет более логичным. Но и описанный вами вариант, где при продуктовых ошибках статус ответа всегда 200, тоже имеет право на жизнь, многие его найдут даже более удобным. Поэтому советую вам выбрать тот формат, который больше всего вам нравится, но не забудьте хорошо задокументировать свой выбор, чтобы у пользователей API было меньше сложностей
Спасибо за замечание. Действительно, Сократ говорил на древнегреческом, а в статье представлен достаточно популярный перевод его фразы на латынь для более удобного восприятия текста.
Как бы это ни было больно, периодически необходимо обновлять используемое серверное ПО и библиотеки, иначе проект в конечном итоге рискует стать легкой мишенью для злоумышленников. Да, это может привести к множеству проблем и сложностей в моменте, но чем дальше откладывать обновление, тем более болезненным оно может стать. Ну а если затягивать с этим слишком сильно, в какой-то момент обновление зависимостей становится почти равносильным переписыванию всего проекта с нуля.
К сожалению, мы не можем получить статистику о наличии секретов в закрытых проектах. Однако факт наличия 1,7 миллиона секретов в общедоступных проектах, которые авторы намеренно разместили в открытом доступе, зная, что они будут доступны буквально каждому, уже говорит о многом. Из собственного опыта могу сказать, что в закрытых проектах вопросы безопасности часто игнорируются (особенно новичками), поскольку проект считается «закрытым», а дополнительные меры безопасности воспринимаются как «лишняя работа».
Конечно, я абсолютно согласен, что опенсурс-разработчики никому ничем не обязаны, но хотел бы отметить то, что все-таки некоторые из них могут получать оплату в виде небольших пожертвований. Кроме того, на мой взгляд, и сами создатели проекта могут быть заинтересованы в том, чтобы их детище пользовалось спросом и было популярным, а для этого и нужно писать документацию, улучшать кодовую базу, развивать сообщество вокруг своей разработки. У разработчиков тут нет никаких обязательств, только глубоко искреннее и доброе желание помочь другим, поэтому в шагах, позволяющих это сделать быстрее и эффективнее, я не вижу серьёзных минусов.
Спасибо за ваши дополнения, полностью согласен что заданные вами вопросы очень важны! Конечно, существует много факторов, которые следует осознавать при начале своей деятельности в роли лидера опенсорс проекта, но я хотел бы отметить, что правильная работа с сообществом поможет закрыть многие из этих пунктов. Находя помощников и заинтересованных в развитии вашей разработки, вы уже гораздо легче сможете справиться с ростом пользовательской базы проекта. Повышая ответственность коллег, вы снимете нагрузку с себя. Про цели проекта я также отметил в статье, но тут важно подчеркнуть, что следует обладать гибкостью, и быть готовым к тому, что цели могут измениться в любой момент, иначе будет тяжело выживать при сильной конкуренции. А вот что касается альтернатив и повторения существующего функционала... не могу сказать, что это плохо, всегда полезно, когда есть большой выбор разработок, решающих одну задачу, но по-разному. Элемент конкуренции является драйвером развития любых проектов, а монополии — это всегда плохо, даже в open-source разработке.
Спасибо за ваше замечание. Советы действительно могут показаться простыми, но в реальности у многих опенсорс разработок существует ряд проблем, связанных с ними. Вот например результаты исследования по используемым лицензиям в открытых проектах: https://blog.opensource.org/the-most-popular-licenses-for-each-language-2023/ - как видно из результатов, огромная часть разработок её и вовсе не имеет. Это очень большая проблема, а ведь разработчики данных решений может и не задумывались ни разу о том, почему она важна. Про повально плохое качество документации в комментариях уже многие отметили. По остальным пунктам то же самое, и я уверен что стоит об этом рассказывать больше и чаще, тогда и многие проекты, которые нас окружают, будут становиться лучше.
Полностью согласен с тем, что с документацией у многих опенсорс проектов большая проблема. Тут сразу вспоминается частое заблуждение про "чистый код == понятный проект", но, к сожалению, это далеко не так, и без хорошего описания любая разработка будет мало полезна. При этом я могу понять разработчиков, которые не любят писать документацию - очень уж это трудоёмкий процесс, который отнимает много времени. Но я надеюсь, что после прочтения статьи, кто-нибудь из создателей плохо задокументированного open-source проекта лишний раз задумается о её необходимости...
Я не вижу ничего плохого в том, чтобы активно использовать различные HTTP статусы и связывать их с бизнес логикой приложения. Если вы делаете REST API, такой подход будет более логичным. Но и описанный вами вариант, где при продуктовых ошибках статус ответа всегда 200, тоже имеет право на жизнь, многие его найдут даже более удобным. Поэтому советую вам выбрать тот формат, который больше всего вам нравится, но не забудьте хорошо задокументировать свой выбор, чтобы у пользователей API было меньше сложностей
Спасибо за замечание. Действительно, Сократ говорил на древнегреческом, а в статье представлен достаточно популярный перевод его фразы на латынь для более удобного восприятия текста.
Как бы это ни было больно, периодически необходимо обновлять используемое серверное ПО и библиотеки, иначе проект в конечном итоге рискует стать легкой мишенью для злоумышленников. Да, это может привести к множеству проблем и сложностей в моменте, но чем дальше откладывать обновление, тем более болезненным оно может стать. Ну а если затягивать с этим слишком сильно, в какой-то момент обновление зависимостей становится почти равносильным переписыванию всего проекта с нуля.
К сожалению, мы не можем получить статистику о наличии секретов в закрытых проектах. Однако факт наличия 1,7 миллиона секретов в общедоступных проектах, которые авторы намеренно разместили в открытом доступе, зная, что они будут доступны буквально каждому, уже говорит о многом.
Из собственного опыта могу сказать, что в закрытых проектах вопросы безопасности часто игнорируются (особенно новичками), поскольку проект считается «закрытым», а дополнительные меры безопасности воспринимаются как «лишняя работа».
Конечно, я абсолютно согласен, что опенсурс-разработчики никому ничем не обязаны, но хотел бы отметить то, что все-таки некоторые из них могут получать оплату в виде небольших пожертвований. Кроме того, на мой взгляд, и сами создатели проекта могут быть заинтересованы в том, чтобы их детище пользовалось спросом и было популярным, а для этого и нужно писать документацию, улучшать кодовую базу, развивать сообщество вокруг своей разработки. У разработчиков тут нет никаких обязательств, только глубоко искреннее и доброе желание помочь другим, поэтому в шагах, позволяющих это сделать быстрее и эффективнее, я не вижу серьёзных минусов.
Спасибо за ваши дополнения, полностью согласен что заданные вами вопросы очень важны!
Конечно, существует много факторов, которые следует осознавать при начале своей деятельности в роли лидера опенсорс проекта, но я хотел бы отметить, что правильная работа с сообществом поможет закрыть многие из этих пунктов. Находя помощников и заинтересованных в развитии вашей разработки, вы уже гораздо легче сможете справиться с ростом пользовательской базы проекта. Повышая ответственность коллег, вы снимете нагрузку с себя.
Про цели проекта я также отметил в статье, но тут важно подчеркнуть, что следует обладать гибкостью, и быть готовым к тому, что цели могут измениться в любой момент, иначе будет тяжело выживать при сильной конкуренции. А вот что касается альтернатив и повторения существующего функционала... не могу сказать, что это плохо, всегда полезно, когда есть большой выбор разработок, решающих одну задачу, но по-разному. Элемент конкуренции является драйвером развития любых проектов, а монополии — это всегда плохо, даже в open-source разработке.
Спасибо за ваше замечание. Советы действительно могут показаться простыми, но в реальности у многих опенсорс разработок существует ряд проблем, связанных с ними. Вот например результаты исследования по используемым лицензиям в открытых проектах: https://blog.opensource.org/the-most-popular-licenses-for-each-language-2023/ - как видно из результатов, огромная часть разработок её и вовсе не имеет. Это очень большая проблема, а ведь разработчики данных решений может и не задумывались ни разу о том, почему она важна. Про повально плохое качество документации в комментариях уже многие отметили. По остальным пунктам то же самое, и я уверен что стоит об этом рассказывать больше и чаще, тогда и многие проекты, которые нас окружают, будут становиться лучше.
Полностью согласен с тем, что с документацией у многих опенсорс проектов большая проблема. Тут сразу вспоминается частое заблуждение про "чистый код == понятный проект", но, к сожалению, это далеко не так, и без хорошего описания любая разработка будет мало полезна. При этом я могу понять разработчиков, которые не любят писать документацию - очень уж это трудоёмкий процесс, который отнимает много времени. Но я надеюсь, что после прочтения статьи, кто-нибудь из создателей плохо задокументированного open-source проекта лишний раз задумается о её необходимости...