Мой GitHub - https://github.com/prog-time

Идея проекта

Большинство Open Source-проектов создаётся не с целью прямой монетизации, а ради социального признания. К таким показателям можно отнести звёзды на GitHub, лайки и подписчиков в социальных сетях. Эти метрики позволяют получить внешнюю оценку проделанной работы и, в определённой степени, повысить свою заметность на рынке.

Прямой финансовый доход от подобных проектов, как правило, не предполагается. Возможны донаты или спонсорская поддержка, однако на начальных этапах разработки не стоит рассчитывать на значительный заработок.

Исходя из этого, я рекомендую начинать с проектов, которые полезны вам лично. В таком случае у вас появляется естественная мотивация поддерживать и развивать проект, даже если внешняя обратная связь минимальна.

Отдельное внимание стоит уделить масштабу проекта. Оптимальное время разработки до первой MVP-версии не должно превышать 1–2 недель. Более длительный цикл без ощутимого результата значительно повышает риск выгорания и потери интереса к проекту.

Для вдохновения вы можете посмотреть проекты которые сейчас в тренде на GitHub или подписаться на Topic по интересующему вас направлению (https://github.com/trending).

Выбор аудитории

При создании Open Source-проекта важно заранее определить целевую аудиторию, поскольку от этого решения будет зависеть практически вся дальнейшая разработка.

В общем случае проекты можно условно разделить на два типа:

• проекты для разработчиков;

• проекты для конечных (сторонних) пользователей.

На этапе планирования необходимо чётко понимать, для кого именно создаётся продукт, так как выбранная аудитория напрямую влияет на архитектуру, набор функций, требования к документации и способы распространения проекта.

Проекты для разработчиков

Если вы разрабатываете библиотеку, фреймворк или инструмент для разработчиков, имеет смысл ориентироваться на технологии, которые востребованы на рынке. Использование популярных языков программирования и экосистем, как правило, позволяет охватить более широкую аудиторию.

Однако существует и альтернативный подход: вместо выбора языка можно отталкиваться от актуальных рыночных трендов. Например, изучить популярные проекты и экосистемы и создать для них вспомогательную библиотеку, плагин или интеграционный шлюз.

В таком случае даже использование менее распространённого языка программирования может стать преимуществом: конкуренция будет ниже, а проект сможет привлечь значительную аудиторию за счёт решения актуальной задачи. Типичный пример — разработка полезного инструмента или библиотеки для новой технологии или нейросети, которая находится на пике интереса.

Проекты для конечных пользователей

Если проект ориентирован на пользователей, не связанных с разработкой (как в моём случае), приоритеты смещаются. Здесь особенно важно уделять внимание:

• производительности и оптимизации;

• качественной и понятной документации;

• простоте установки и быстрому развёртыванию проекта.

Необходимо учитывать, что такая аудитория, как правило, не имеет технического бэкграунда. Поэтому ключевой фактор успеха — минимальный порог входа и понятный пользовательский опыт.

Наблюдения из практики

По моему опыту, проекты для разработчиков чаще получают звёзды на GitHub, поскольку их аудитория хорошо ориентируется в экосистеме платформы и активно использует такие метрики. Однако подобные проекты сложнее продвигать и выделять среди конкурентов.

Проекты для конечных пользователей, в свою очередь, обычно получают меньше звёзд, но их аудитория охотнее идёт на контакт и более заинтересована в развитии продукта, особенно если он напрямую влияет на их бизнес-процессы.

Начало разработки

На ранних этапах разработки важно сразу продумать сценарий использования проекта с точки зрения пользователя. В идеале процесс установки и первичной настройки не должен превышать 2–3 шага — чем ниже порог входа, тем выше вероятность, что пользователь действительно попробует ваш продукт.

Если вы разрабатываете библиотеку, имеет смысл ориентироваться на популярные менеджеры пакетов соответствующей экосистемы. Это позволяет пользователям подключать ваше решение к проекту с помощью нескольких команд в терминале, без дополнительной ручной настройки.

Если же проект представляет собой отдельный сервис (как в моём случае), стоит заранее задуматься о контейнеризации. Использование Docker позволяет изолировать зависимости, стандартизировать окружение и значительно упростить процесс установки и запуска проекта.

В процессе разработки проекта tg-support-bot я предусмотрел два варианта установки:

• Полный вариант — развёртывание через docker-compose, включающее все необходимые сервисы: PostgreSQL, PgAdmin, Loki, Grafana, Redis и другие компоненты.

• Упрощённый вариант — установка проекта на обычный хостинг с возможностью подключения внешней базы данных и отключения необязательных сервисов.

При этом важно избегать жёстких зависимостей между контейнерами. Пользователи должны иметь возможность отключать или заменять отдельные сервисы внутри docker-compose без нарушения работоспособности основного приложения.

Линтинг, настройка CI и тесты

Перед публикацией проекта важно настроить надежную систему тестирования и линтинга. Это помогает предотвратить ошибки, повышает стабильность проекта и облегчает совместную разработку.

Code style и линтеры

Для каждого проекта важно определить и задокументировать правила code style. Чем строже и однозначнее эти правила, тем проще поддерживать читаемость кода и единый стиль среди участников проекта.

Также необходимо настроить линтеры, которые проверяют код на:

• синтаксические ошибки и типизацию;

• соответствие имен переменных и функций выбранному стилю;

• распространённые ошибки и потенциальные уязвимости.

Автоматическое тестирование

Автотесты критически важны для поддержания стабильности проекта и ускорения разработки. Чем больше функций покрыто тестами, тем безопаснее вносить изменения и привлекать сторонних контрибьюторов.

В проекте tg-support-bot я реализовал систему shell-скриптов для автоматизации линтинга и тестирования с передачей дополнительных параметров к инструментам анализа.

Скрипты интегрированы с git-хуками:

При коммите запускаются проверки только для файлов, включённых в индекс.

• Статический анализатор PHPStan проверяет код на ошибки и нарушения типизации;

• Выполняются unit-тесты для изменённых классов;

• Если изменён Dockerfile, запускается Hadolint для проверки Dockerfile;

• Если изменены shell-скрипты, применяется ShellCheck для выявления ошибок и потенциальных уязвимостей.

При push выполняется проверка всего проекта: PHPStan анализирует весь код, запускаются все unit-тесты и линтеры. Это позволяет выявить проблемы, которые могли быть пропущены при коммите.

На этапе CI система повторно проверяет весь проект, что особенно важно для Open Source: сторонние контрибьюторы могут внести изменения, которые нарушат работу проекта.

В случае обнаружения ошибки системы блокирует изменения до исправления ошибок.

Скрипты для git-hooks вы можете посмотреть здесь - https://github.com/prog-time/git-hooks

Таким образом, процесс тестирования делится на три уровня:

1. Локальная проверка при коммите — только файлы, добавленные в коммит.

2. Проверка при push — весь проект для предотвращения глобальных ошибок.

3. CI/CD — полная автоматическая проверка, включая сторонние изменения.

Продуманная система тестирования и линтинга позволяет снизить риски и обеспечивает стабильность проекта, что особенно важно в Open Source-разработке.

Структура GitHub репозитория

В процессе разработки вы будете создавать множество веток, которые в дальнейшем будут сливаться с основной веткой main. От правильной организации веток напрямую зависит качество проекта и удобство командной работы.

Структура веток

На своих проектах я использую следующую схему:

• Ветка main является основной. Прямые коммиты в неё запрещены — все изменения вносятся через дочерние ветки.

• Релизные ветки создаются перед планированием релиза. Например, для шестого релиза создаётся ветка release_6. В этой ветке я фиксирую все задачи, которые должны войти в релиз.

• Ветки задач создаются для каждой отдельной задачи из релиза. В наименовании ветки обязательно указывается номер соответствующего Issue. Это строгое правило: ветка с некорректным именем не пройдет проверки CI, и изменения не смогут быть слиты в проект.

Такой подход помогает:

1. Приучиться создавать Issues для любых изменений;

2. Контролировать работу сторонних контрибьюторов;

3. Поддерживать прозрачность процесса разработки.

Структура коммитов

Для упрощения отслеживания изменений я использую shell-скрипты, которые автоматически:

• Добавляют в начало описания коммита номер задачи (issues-62 | update tests);

• Формируют список изменённых файлов с пометками Added, Changed, Deleted.

Пример такого комментария:

Структура релизов

Также важно соблюдать грамотное описание релизов: каждая версия должна содержать чёткий список изменений и исправленных задач. Такой подход обеспечивает:

• прозрачное ведение истории изменений;

• удобство для контрибьюторов и пользователей;

• облегчение поддержки проекта в долгосрочной перспективе.

Строгая структура веток и коммитов повышает контроль над изменениями, улучшает читаемость истории проекта и минимизирует ошибки при совместной разработке в Open Source.

Документирование

Документирование — один из ключевых аспектов Open Source-разработки. Хорошая документация делает проект доступным для пользователей и контрибьюторов, ускоряет внедрение и снижает количество ошибок при использовании.

Основные элементы документации

1. README.md

   • Основной файл, который видит каждый пользователь на GitHub.

   • Должен содержать:

     • краткое описание проекта;

     • инструкции по установке и настройке;

     • пример использования;

     • ссылки на документацию.

2. CONTRIBUTING.md

   • Описание процесса внесения изменений в проект.

   • Рекомендуется включать:

     • правила создания веток и коммитов;

     • процесс отправки pull request;

     • требования к тестированию и линтингу.

3. CHANGELOG.md

   • Фиксирует историю релизов и внесённых изменений.

   • Формат: версия, дата релиза, исправления, новые функции.

Отдельно хочу выделить раздел Wiki на GitHub...

GitHub Wiki — это встроенный инструмент для более подробной и структурированной документации проекта. В отличие от README, Wiki позволяет создавать несколько страниц, объединённых логической структурой, что удобно для больших проектов.

Использование Wiki целесообразно для расширенной документации: здесь можно описать архитектуру проекта, инструкции по деплою и CI/CD, гайды по использованию библиотек и сервисов, а также рекомендации для контрибьюторов. Важно, чтобы Wiki дополняла README, а не дублировала его, оставляя последний кратким и ориентированным на быструю установку и запуск.

Практические рекомендации

• Документируйте всё ключевое сразу, не откладывая на будущее. Это экономит время и снижает риск потери информации.

• Используйте шаблоны и стандарты (например, Markdown, OpenAPI, DocBlock), чтобы документация была однородной.

• Поддерживайте документацию в актуальном состоянии — каждая новая функция или изменение должно сопровождаться обновлением описаний.

• Для сторонних пользователей делайте упор на простоту и понятность, для разработчиков — на технические детали и примеры использования.

Взаимодействие с аудиторией

Для успешного развития Open Source-проекта важно активно взаимодействовать с аудиторией и привлекать пользователей из сторонних источников. Это помогает не только продвигать проект, но и получать ценные отзывы для улучшения функционала.

Первым шагом является выбор удобного канала коммуникации. Это может быть форма обратной связи на сайте, отдельная почта для обращений пользователей или группа в популярной социальной сети. Главное — чтобы пользователи могли легко задавать вопросы и получать ответы.

В проекте tg-support-bot я создал отдельную группу, где публикую новости, отвечаю на часто задаваемые вопросы и взаимодействую с пользователями.

Этот подход оказался очень эффективным: со временем пользователи стали помогать друг другу, отвечая на вопросы без моего участия. Кроме того, участники активно тестируют новые функции, выявляют ошибки и предлагают улучшения, что значительно ускоряет развитие проекта.

Дополнительно в Telegram-группе я получаю от пользователей идеи для нового функционала и провожу голосования, что позволяет учитывать мнение сообщества при планировании развития проекта.

Таким образом, налаженная коммуникация с аудиторией позволяет объединить пользователей, повысить вовлечённость и создать сообщество вокруг проекта, что является ключевым фактором успешного Open Source-развития.

Популяризация проекта

Для расширения аудитории важно привлекать пользователей из внешних источников. Одним из эффективных способов является создание видеоконтента в формате «Dev-блог», где можно показывать процесс разработки и делиться опытом по созданию проекта.

Видеоинструкции по установке и настройке проекта также оказывают большую помощь пользователям, снижая порог входа и повышая интерес к проекту.

Дополнительно полезно публиковать статьи на популярных ресурсах, таких как Хабр или Пикабу, чтобы привлечь новую аудиторию и рассказать о проекте более широкой публике.

Если проект содержит интересные технические решения, он может привлекать внимание даже тех пользователей, которые не планируют использовать его напрямую, но хотят наблюдать за процессом разработки и изучать технические детали.

Заключение

Open Source — это не только код, но и процессы, сообщество и взаимодействие с пользователями. Продуманная структура репозитория, тесты, документация и активная коммуникация помогают проекту развиваться и привлекать новых участников.

Если вам интересно следить за моими проектами и участвовать в их развитии, подписывайтесь на мой GitHub — там вы найдёте все обновления и сможете присоединиться к работе над проектами.

17% ищет работу более 4 месяцев

Качество резюме:

60 % резюме составленных "на отъебись" (тупо перечислены места работы и над чем работал кратко и без подробностей)

25% резюме с какими-то подробностями

15% резюме составленных грамотно (фото и очень круто все расписано)

В среднем программисты готовы работать за 180 - 200К. Около 10% хотят 300 - 400К, но это мечтатели - таких зарплат сейчас почти нет. Думаю, многих, кто в поиске больше пары месяцев можно и на 150К уломать, слегка замесив с говном на техсобесе.

Выводы:

1. Те, кто давно в поиске сильно проигрывают тем, кто работает: когда человек пол года не может найти работу - это создает впечатление его жесткой невостребованности. Ну и есть понимание, что человека без работы легче продавить по ЗП.

2. Тем, кто в поиске и не имеет работы составляют конкуренцию те, кто не в поиске (снижая шансы получить лакомый кусок с большой зарплатой потому что конкуренция большая)

3. Рынок просел и на нем реально жопа.

Если у вас есть работа - не увольняйтесь вникуда. И не выебыватесь на дейликах. Будьте паиньками. Лучше уже не будет. ИИ придет за всеми.

3) Леди Мари – любимая фрейлина принцессы Инны из знатного герцогского семейства. 20 лет. Волосы и глаза тёмные, рост чуть-чуть повыше, чем у Инны. Общается развязно, нагловато, одевается удобно. Выше всех по статусу, кроме принцессы. Не терпит нарушений субординации – при этом сама регулярно её нарушает, в том числе с принцессой, пользуясь дружескими связями.

4) Мелоний Швестеркранк – придворный механик. 65 лет. Рост средний, сам коренастый, наполовину лысый и седой. Давно работает во дворце. Мари называет его просто «Мел», а принцесса (периодически, в качестве уважения) – «Многоуважаемый дедушка Мелоний». Пример технократа, обожающего разнообразные конструкции и инженерию, превозносящего науку над искусством.

5) Елизавета (прозвище – «Дон Лизон») – повариха во дворце. 30 лет. Глаза зелёные, волосы каштановые, итальянской внешности, говорит с акцентом. Слегка полновата. Обожает принцессу, но недолюбливает Мари, поскольку та предъявляет к ней слишком много требований и часто выругивает якобы по пустякам.

6) Арчибальд – капитан королевской стражи. 35 лет. Ростом чуть выше, чем Саша, носит длинные чёрные волосы, при этом глаза у него голубые. Идеально почтителен с вышестоящими. Недолюбливает Александра с первого же взгляда и знакомства. Видите ли, в юности он тоже писал стихи, и в этом видит свою конкуренцию с главным героем.

7) Василий – отец Саши. Ему 51 год, и он очень похож на Сашу (если представить, что тот вдвое состарился). С детства преподал сыну недюжинные знания и навыки в области садоводства, чем парень при должной смекалке может потрясти Инну и Мари. По характеру – простой деревенский мужик, умелый и простой, - правда, знающий дворцовый этикет, если надо общаться с высшим обществом!

Для каждого из персонажей ты должен изобразить не менее 10 поз и эмоций (больше можно), необходимых для повествования.

Фоны:

1) Королевский сад (4)

2) Апартаменты королевского дворца (4)

3) Природа вокруг дворца (4)

4) Дом Александра (2)

5) Надворные пристройки ко дворцу (вид изнутри) (2)

6) Городские виды (2)

7) Аптека (2)

8) Ремесленный двор (2)

9) Крестьянское подворье (2)

Если по сюжету нужно ещё, можешь смело дорисовывать. Это базовый минимум.

Традиции:

1) К тем, кто выше по статусу, всегда обращаются на «Вы», а к тем, кто ниже – на «ты» (не зависит от возраста). Это ни в коем случае не нарушается ни в одном из вариантов развития событий. Не считается чем-то дискриминационным: наоборот, преподносится как традиционная эстетика дворца. Даже романтические беседы не подразумевают перехода на «ты», если социальный статус влюблённых неравен. Даже брак не подразумевает!

2) Королевская власть не считается чем-то злым, несправедливым. Наоборот, все искренне верят, что монаршие особы привносят в мир только разумное, доброе и светлое. Споры и тем более скандалы с принцессой не доступны ни при каких обстоятельствах. С Мари – весьма и весьма нежелательны, поскольку фрейлина – «вторая после Бога». Разлад с ней наблюдается только в одной-двух сценах, ведущих к плохим концовкам. Разборки могут быть только между «своими» по статусу. И вообще, чем персонаж выше по происхождению, тем он правильнее и справедливее априори.

3) В королевстве хорошо относятся как к искусствам, так и к науке. А в особенности к тому искусству, которое прославляет монархию. Магия присутствует, но в крайне малых дозах и редких случаях. Считается чистейшей прерогативой знатных особ. А простолюдины «руками работать должны».

Сюжет:

Василий пишет письмо принцессе Инне с нижайшей просьбой взять на службу его сына Александра. Сам Василий когда-то тоже служил при дворе старшим садовником, а у них преемственность поколений. Дополнительно, чтобы произвести впечатление, у игрока есть выбор добавить к письму стихотворение Александра.

Инна устраивает испытание Саше, связанное с работой садовника. Если мы выбрали писать стихотворение, то испытания становятся немного легче, а отношения менее формальными. (Далее я не буду расписывать тебе каждый выбор игрока – ты должен сам качественно соорудить все ответвления, полагаясь на ТЗ и свою фантазию)

Одна из главных тем новеллы – идейное противостояние «лирика» Саши и «техника» Мелония, «старшего» и «младшего» поэтов Арчибальда и Александра, желающих произвести впечатление на дам. Романтические линии возможны как с Инной, так и с Мари. При этом отношения не выходят за рамки покровительственных (слуга-повелительница, даже при близком общении). Легонько и скрытно Александр может влиять на события, происходящие в королевстве. Не наглеть!

Итак, Саша работает во дворце, вступает в диалоги, споры и даже остросюжетные скандалы с другими персонажами (в рамках своего ранга), и это приводит его к одной из 7 концовок.

Общие требования:

Новелла представляет собой запускаемую программу, написанную на Python. Протяжённость игрового процесса – не менее 2 часов прохождения. Прохождение должно быть интересным, динамичным и захватывающим (цепляющим).

Выборы неявные: они немного запутывают игрока, превращая его опыт в загадочную сказку.

Уровень качества – шедевр.