Привет всем! Подходит время новогодних праздников и это отличная возможность начать свой open source проект. Меня зовут Дима и я Ruby разработчик, сегодня я хочу поделиться своим опытом создания open source решения, расскажу подробнее какие этапы должен пройти проект, как правильно выбрать функционал для первого релиза и с какими ошибками столкнулся лично при создании своего проекта.
Полгода назад мне пришла идея о том, что хорошо было бы создать свой open source проект, вместо тестовых заданий на интервью мне было бы достаточно отправить ссылку на репозиторий, а перспектива помочь коллегам с решением их повседневных проблем еще больше зарядила меня энергией.
Мне всегда не нравились гемы для создания административных панелей, любое лишнее движение требует переопределения классов, для изменения полей нужно делать изменения в файлах. После размышлений и беседой с коллегами было принято решение создать новую библиотеку, которая была бы гибкой и не требовала бы дашбордов или файлов конфигурации.
Определите цели
Каждый open source проект решает определенную проблему. Пообщайтесь коллегами, чаты, форумы, расскажите о своей идее, все это поможет вам на раннем этапе сформировать картину того, какие решения уже существуют и услышать критику со стороны. Пообщайтесь с людьми, у которых уже есть свои open source проекты, они могут дать очень ценные советы, не бойтесь спрашивать и проявлять инициативу.
Одним из ценных советов, который я получил на данном этапе, это обратить внимание в первую очередь на документацию проекта, у вас может быть очень хороший проект, но никто не будет читать исходники и пытаться понять как это работает.
Самый важный аспект, без которого дальнейшие этапы невозможны это мотивация, идея проекта должна цеплять в первую очередь вас, чаще всего люди привыкают к тем инструментам с которыми работают и попадают в зону комфорта, мнения со стороны могут быть неоднозначными.
Планирование
Выбор определенного таск менеджера вопрос вкуса, задачи следует фиксировать и иметь четкую картину на каком этапе сейчас находится проект в целом. Разбейте задачи на подзадачи, в идеале чтобы выполнение одной задачи не занимало более 3-4 часов, важно получать удовольствие от выполнение маленьких задач, это поможет избежать выгорания и потерю мотивации.
Я использую pivotal tracker, основное преимущество является наличие бесплатной версии для open source проектов, присутствует сортировка задач по типу (feature, bug, chore, release), задачи можно группировать в релизы и определять дедлайн.
Оформление
В каждом open source проекте должны присутствовать следующие вещи:
- README
- open source license
- Contributing guidelines
Файл README не только объясняет как использовать ваш проект, но и какая цель вашего проекта, как начать его использовать. Если не знаете как правильно оформить README можете посмотреть другие известные open source проекты или воспользоваться шаблоном.
Лицензия гарантирует, что другие могут использовать, копировать и модифицировать исходный код проекта. Вам необходимо добавлять этот файл в каждый репозиторий с вашим open source проектом. MIT, Apache 2.0 GPLv3 самые популярные лицензии для open source проектов, если не уверены какую выбрать можете воспользоваться удобным сервисом.
Файл CONTRIBUTING поможет другим разработчикам сделать вклад в проект. На первых шагах проекта не обязательно уделять этому файлу пристальное внимание, можно воспользоваться уже готовым шаблоном из другого проекта.
Мои ошибки
Если анализировать первоначальный этап, у меня была идея, но не было четкого плана. Я решил, что хочу сделать это, не имея четкого представления сколько по времени это может занять и конкретного представления функционала, который будет в первой версии библиотеки. У меня было просто много желания и отсутствие четкого плана
Так же почитав историю других проектов, не только open source, я заметил, что на раннем этапе имеются слишком оптимистичные планы и переоценка своих сил и возможностей, не так просто находить время каждый день на написание новой фичи в проект. Большую часть задач, пришлось в итоге отсеять и оставить необходимый минимум для MVP.
На данный момент мой проект simple-admin находится в состоянии альфа версии, в дальнейшии планы входит создание отдельной версии библиотеки для hanami.
Комментарии (20)
RomanPokrovskij
01.01.2018 03:22+3Я целевая аудитория этой статьи и мне многого чего в ней не хватило.
1) не хватает подборки ссылок на правильные Contributing, я вот так сразу не нашел этого файла в тех проектах которые сам считаю образцовыми и которым подражаю. (кстати выбор образца для подражания — необходимый и неупомянутый шаг).
2) не хватает описания git workflow — вопрос использовать ли integration workflow (два репозитория) все время меня мучает (хотя и несколько заранее, но вообще такие вещи заранее и обсуждаются и решаются).
3) крайне не хватает понимания какие ходы по растпространению информации о своем проекте возможны.
В чем проблема: мне например стучали по шапке на stackoverflow где я в ответах на вопросы о ошибках сериализации (circular references ) добавил ответ с ссылкой на свое решение (сериализатор решающий проблемы circular references сразу множестовм способом: и заданием глубины и памятью о экземплярах и заданиями стратегий для неповторения сложных типов). Не то чтобы сильно стучали: ответы при этом удалили. Апеляция успеха не имела. В одном случае — в результате дискуссии один из «апеляционных модеров» заявил что если бы я пост переделал он бы имел право на публикацию. Мне показалось это потерей времени — ничего переделывть не стал, согласился с удалением. То что это была реклама — ок, но это все же опенсорсное решение, вполне уникальное и рабочее и интересное и по теме топика. Модератор взъелся от того что я просто «поспамил» решение в 3-4 схожих вопроса. Отсюда вывод — следующий проект буду рекламировать не так «агрессивно», хотя повторюсь было отправлено в 3-4 треада, весьма скромный спам.
Hokum
01.01.2018 13:34-1> не хватает описания git workflow
Нет смысла перегружать вводную статью такими вещами. Сюда же относится и integration workflow. Это важные и нужные вещи, но когда разработчик начинает работать над проектом в одиночку, то они могут подождать. На начальном этапе стоит уделить больше времени для скорейшего получения минимальной рабочей версии. В противном случае, решая вопросы с workflow и CI, CD, можно упустить время, задор исчезнет, а ничего рабочего не будет.
Указанные вещи могут стать отдельной статьей, с заголовком «Open Source проект запущен, что дальше?». В которой можно рассмотреть преимущества и недостатки облачных систем управления репозиториями (github. bitbucket, gitlab). Какие есть облачные системы CI и CD, чтобы не тратить время и силы на администрирование self-hosted решений. Но и это может быть интересно в разрезе провайдеров VDS который предоставляют специальные планы для opensource проектов, если такие есть.RomanPokrovskij
02.01.2018 02:30Категория «Опен Сорс проект» в своей специфичности начинается именно что с задачи распространения информации о идеи воплощенной в кусок кода и с организации совместной работы над этой идеей/кодом. Разве нет? Вот вы «задор» употребили — задор — ингридент всякого творчества, и никак не специфичен для опен сорс проекта.
Я даже не могу себя назвать защитником принципа «давайте сразу к самому важному» — это не тот принцип, что нуждается в защите.Hokum
02.01.2018 12:06задачи распространения информации о идеи воплощенной в кусок кода
Именно что о воплощенной идеи. Когда уже есть какая-то наработка, когда видно, что из этого получится — больше шансов собрать команду разработчиков. И имея хоть как-то воплощенную идею, пора задуматься как организовать совместную работу.
Вот вы «задор» употребили — задор — ингридент всякого творчества, и никак не специфичен для опен сорс проекта.
Согласен. Не специфичен. Но чтобы идея нашла реализацию нужна энергия на это. Которая появляется в момент возникновения. Я называю это "задором". Если в ближайшее время не приступить к ее осуществлению, то велика вероятность, что задор пройдет, а идея так и останется идеей. Так что надо успеть хоть как-то воплотить идею в код, а потом уже думать как привлечь сообщество.
Исключения, если вы уже запустили не один успешный проект, в таком случае есть шанс, что соберется сообщество вокруг только анонсированной идеи или вы гениальный менеджер и оратор способный "заражать" своей идеей других.
datacompboy
01.01.2018 13:53Ух ты, это ж мне, получается везёт. Я как-то "спамил" на СО ссылкой на вавплеер — никто не возмущался
RomanPokrovskij
02.01.2018 01:10Может это мне не везет. У меня и на СО карма -1 не пойму за что. Писал статью в песочницу — не получил ответа. Всё на ощупь и всюду по пальцам.
dmytrostriletskyi
01.01.2018 04:24+4свой open source проект, вместо тестовых заданий на интервью мне было бы достаточно отправить ссылку на репозиторий
По своему опыту скажу, половине работодателей все равно на ваши проекты на Гитхабе или личный блог. Другой части этого достаточно не будет и вам придется сделать тестовое задание. Случается часто, что когда без тестового задания после собеседования сразу могли предложить оффер, но влияли ли на это мои подделки — вряд ли (вывод основан на том, что никто ни разу о них и не спросил, как и о блоге).
Я каждый раз натыкаюсь на то, что идея открытых проектов как инструмент заявить о себе работодателю переоценена и не работает.
Что касается тестового — не считаю это чем-то плохим. Всегда спрашиваю две вещи: почему мне дают тестовое задание (с этого можно сделать выводы), и относится ли оно к будущей работе (если относится и вы сделали его очень хорошо, то это повод выторговать лучшие условия или вовсе отказаться от сотрудничества).RomanPokrovskij
01.01.2018 04:34Кстати да, мне попадались исключительно менеджеры непроявляющие никакого интереса к моим профессиональным профайлам на гитхабе и стаковерфлоу. Но всегда просили список сертификатов и любили его пообсуждать (вывод: приоритет за формальным).
caballero
01.01.2018 13:11Потому что зачастую эйчар — девица надергавшая требований с инета и мало что понимающая в технической стороне.
RomanPokrovskij
02.01.2018 01:00Нет, я как фрилансер, немного по другому пути иду: когда проходишь хедхантеров и когда уже они рекомендуют заказчику — разговор сразу же начинается с менеджера проекта. Правда надо понимать что те кто пользуются хедхантерами — большие корпорации — у них своя специфика. Тем не менее некое удивление остается — у тебя проект горит от того что забрели в тупик, пойди посмотри на профайлы, работает человек с этой технологией и как, но нет сравнения кандидатов будут идти насколько удачно сертификаты покрывают формальные потребности.
devalone
01.01.2018 14:59+2По своему опыту скажу, половине работодателей все равно на ваши проекты на Гитхабе или личный блог.
HRы Гугла, например, в видео про процесс найма говорят, что open-source проекты — это важно и хорошо, если они есть. Собеседоваться в компании уровня гугла не доводилось, но в обычных компаниях всем насрать.
Ordinatus
01.01.2018 15:01+1Да, пожалуй даже больше половины работодателей из моего опыта не интересуются аккаунтами на гитхабе, хабре, стековерфлоу и т.д. Зачастую менеджеры просто не понимают что это такое, но если мы говорим о работодателях из такого рейтинга то ситуация меняется. Был во многих на собеседованиях, после формальных вопросов начинается диалог о опыте, технологиях, проектах. Вот на этом этапе пригождаются проф. соц. сети, если они есть в резюме, тыкаешь пальцем и рассказываешь что там есть подробности на ту или иную тему.
dmitriy-strukov Автор
01.01.2018 22:20dmytrostriletskyi У всех свой опыт, в моем опыте большую часть работодателей интересовал мой проект, если просили тестовое я скидывал ссылку на проект, после этого проходило уже интервью. Безусловно для некоторых компаний основным критерием будет тестовое, а на ваш проект им все равно, но вопрос уже в том хотели бы вы работать в такой компании.
dom1n1k
02.01.2018 10:06Это хорошо работает только для авторов знаменитых проектов. Если репозиторий имеет много тысяч звезд и название на слуху в своей области, значит автор сделал себе имя. В противном случае, ну молодец конечно, но не более того.
therhino
01.01.2018 04:59+1Все существующие без исключения гемы для административных панелей ужасны и вангую, что лучших не будет.
Вместо написания своего (велосипеда) / (очередной бесполезной cms) я бы посоветовал внести свой вклад в другие проекты. Вот тогда действительно будет что показать.
caballero
01.01.2018 13:14+2Если проект более менее серьезный (а не для показать на собеседовании) — основная проблема — обрастание сообществом.
KvanTTT
01.01.2018 20:28Я использую pivotal tracker, основное преимущество является наличие бесплатной версии для open source проектов, присутствует сортировка задач по типу (feature, bug, chore, release), задачи можно группировать в релизы и определять дедлайн.
А стандартный, встроенный в GitHub или GitLab не подойдет?
dmitriy-strukov Автор
01.01.2018 22:22KvanTTT на вкус и цвет. Главное чтобы вам было удобно, а если вокруг проекта подтянется сообщество, то выберете более удобное решение под ваши потребности.
totorialman
Хорошая статья, все заманчивое написано, но лично у меня ничего толкового на праздниках не выходит, увы)