Готовый код на хакатоне: что можно брать с собой

Команда Stavleak · Обновлено 7 октября 2026 года

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

Коротко

Готовый код на хакатоне допустим в объёме, который разрешают правила конкретного события. Проверьте отдельно библиотеки, личные шаблоны, учебные фрагменты, прежние проекты и ИИ-код. Затем запишите происхождение компонентов и уточните спорный случай у организатора. Разрешение конкурса использовать компонент и разрешение его автора — два разных вопроса.

Почему нельзя просто спросить «готовый код разрешён»?

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

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

Какие пять вещей проверить в своём репозитории?

1. Пакет или библиотека

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

2. Собственный шаблон приложения

В нём уже могут находиться вход, база данных, готовые экраны и деплой. Перечислите функции, которые работают до старта. Слова «обычный шаблон» слишком расплывчаты: пустой экран и завершённый личный кабинет дают разный объём прежней работы.

3. Фрагмент из учебного проекта

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

4. Старый продукт

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

5. Код, созданный с помощью ИИ

Сначала найдите правило об ИИ, затем отдельно проверьте время создания. Функция, сгенерированная неделю назад, тоже существовала до старта. Зафиксируйте инструмент и его роль, а также то, что команда проверила. Убедитесь, что вы можете объяснить код и воспроизвести его работу.

Как задать организатору вопрос, на который можно ответить?

Вместо «можно свой шаблон?» отправьте описание границы:

У нас есть репозиторий, созданный до события. В нём уже работают регистрация и сохранение пользователя. Во время хакатона планируем сделать поиск свободных аудиторий. Разрешено ли взять эту основу? Где в подаче указать прежние функции и какие подтверждения нового вклада нужны?

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

Сохраните ответ вместе с версией правил и датой. Уточните, распространяется ли разъяснение на ваш трек. Односложное «можно» без описания компонента позже трудно связать с тем, что оказалось в финальном проекте.

Как записать происхождение компонентов без большого отчёта?

Заведите короткий список компонентов в документации проекта. Ниже учебный пример: названия и статусы нужно заменить своими.

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

Чем разрешение конкурса отличается от лицензии?

Организатор отвечает, допустим ли компонент для участия. Автор кода определяет условия его использования. В документации GitHub объясняется роль лицензии: открытая видимость репозитория сама по себе не даёт общего разрешения копировать и распространять код.

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

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

FAQ

Если код написал я, его точно можно использовать?

Авторство не отменяет требования конкурса о времени разработки. Опишите компонент и сверяйтесь с правилами выбранного события.

Если я перепишу старый проект на другом языке, он новый?

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

Нужно ли раскрывать маленькую функцию?

Следуйте требуемому формату раскрытия. Если граница не описана, приведите конкретный фрагмент в вопросе организатору.

Источники

Примеры компонентов и сообщение организатору придуманы командой Stavleak. Материал подготовлен с помощью ИИ и проверен по первоисточникам.