Совместное использование исходного кода в неофициальном стартапе

Контекст:

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

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

Проблема:

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

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

Резюме аргумента

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

С одной стороны, совместное использование и открытие доступа к коду может иметь смысл, если учесть, что:

  • Командный менталитет: проект — это групповая работа, поэтому имеет смысл делиться всеми его аспектами, ресурсами и разработками с группой.

  • Рост: по мере роста проекта маловероятно, что им сможет управлять один разработчик, поэтому в конечном итоге его необходимо будет открыть.

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

С другой стороны, предоставление доступа к моему коду на этом этапе кажется рискованным, и я опасаюсь этого, учитывая, что:

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

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

  • Ненужные накладные расходы: необходимость управлять «переделкой» и потенциальными проблемами контроля версий, вызванными новым разработчиком, который практически не знает технических особенностей проекта, без острой необходимости в этом на данном этапе, добавил бы неоправданное бремя и дополнительные затраты времени. к моему рабочему процессу.

  • Честность и легитимность: разработка того, что мы сейчас имеем, потребовала значительных затрат времени и усилий. Предоставление доступа другому разработчику для внесения «некоторых крутых идей», чтобы иметь возможность заявить, что он «со-разрабатывал» проект в своем резюме, кажется нечестным и, на мой взгляд, умаляет серьезность и законность того, что я создал.

  • Конфликт ролей: как «технический директор»/«ведущий разработчик» проекта я должен иметь право голоса в отношении того, кто и в каком качестве участвует в процессе разработки проекта. Это опровергается тем фактом, что другой человек также является «основателем».

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

Вопросы

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

  • Предоставление доступа к критически важному исходному коду для других, чтобы «возиться с ним», распространено в неформальных сценариях запуска?

  • Как главному разработчику сохранить контроль над своей работой и защитить свою значимость в группе/стартапе/компании, открыв ее другим разработчикам, в условиях, когда еще не заключены договоры или формальности?

Заранее спасибо.

Чтобы добавить к пунктам @Jonast92, с которыми я полностью согласен, вы должны извлечь урок из этой ситуации и никогда не начинать подобные начинания без каких-либо официальных соглашений и юридического лица. Полгода спустя - это немного поздно для такого обсуждения, приводящего к юридически обязывающим соглашениям, но лучше сейчас, чем никогда..
@Jonast92 Jonast92 - Я согласен, проект находится на контроле версий, просто ему он недоступен. С другой стороны, нет никакого «босса» — как уже упоминалось (но, возможно, недостаточно ясно), мы представляем собой стартап-инициативу, поддерживаемую в настоящее время группой «основателей», которые выполняют различные задачи. Я являюсь учредителем, отвечающим за технические аспекты, а другой коллега является учредителем, отвечающим за финансовые и PR-аспекты.
@iLuvLogix Я также согласен с тем, что разумно иметь четкие правовые рамки, прежде чем начинать какое-либо профессиональное участие. Это всегда было моей практикой как работающего разработчика программного обеспечения. В данном случае проблема возникла из-за неуверенности стартапов — часто нужно что-то добросовестно начать строить, потом валидировать и, надеюсь, получить финансирование, после чего имеет смысл нести расходы на регистрацию, инкорпорацию, составление проекта. юридических соглашений и налогов.
@Sagap Я не согласен - даже если стартапы неопределенны, гораздо дешевле зарегистрировать компанию и получить нотариальную контору для подтверждения ваших официальных соглашений / контрактов с самого начала, чем слишком потерять вашу интеллектуальную собственность за полгода работы. , И работа, которую делают все, не обязательно должна оплачиваться (конечно, в зависимости от ваших местных законов).
Вам, ребята, нужен адвокат, как ВЧЕРА! Мой первый вопрос: является ли это совместным усилием неоплачиваемых людей или кто-то вытягивает деньги из предприятия. Этот парень говорит о повышении своего резюме, когда вы все строите компанию? Этот парень не на той же странице, что и остальные из вас. Вы 3 месяца из мира боли. Вам нужно собрать всех вместе и немедленно заключить контракты. Это плохой беспорядок на вашем пути, и СКОРО!
Вы не упоминаете, какой тип управления версиями вы используете, но - предполагая, что вы используете что-то вроде github - разрешите им разветвить репозиторий - и на случай, если они действительно создадут что-то полезное для проекта, разрешите только они могут внести свой вклад на основе мерж-реквестов , которые вы можете либо принять, либо отклонить.
Предполагая, что ваша компания уже существует, вы бы наняли его?
Хотя на самом деле это не ответ на рабочем месте, github разрешает защищенные ветки, и вы можете установить правило, которое потребует проверки кода для любых запросов на включение в этой ветке, что поможет минимизировать проблемы с накладными расходами/контролем версий. Если есть конфликты слияния и т. д., потребуйте от него разрешения их, прежде чем он сможет получить обзор.

Ответы (3)

Предоставление доступа к критически важному исходному коду для других, чтобы «возиться с ним», распространено в неформальных сценариях запуска?

Да, но неограниченного доступа к фиксации "переделанного" кода нет. Вы уже знаете, что существует огромная разница между некоторыми взломанными демонстрационными материалами и готовым кодом в производстве (даже/особенно в стартапе).

Как главному разработчику сохранить контроль над своей работой и защитить свою актуальность в группе/стартапе/компании, открыв ее другим разработчикам

Управления источником. Используйте Github/Bitbucket/что-то и позвольте своим коллегам получить код. Вы можете поместить библиотеки и т. д. в разные репозитории и ссылаться на них только как на двоичные файлы (Chocolatey/Nuget/npm/etc) и открывать только ту поверхность, с которой они хотят возиться.

в условиях, когда еще не заключены контракты или формальности?

Это ужасная ошибка. сделать это скорее. Конечно, вы должны иметь дело только с теми, кому вы доверяете. Вы доверяете ему/ей, верно?

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

С надеждой!?? Им не понадобится ваш код, и они все равно перепишут его по мере изменения бизнес-требований/фокуса. Им нужно только что-то наглядное, чтобы продать идею инвесторам. Не хочу вас пугать, но без акционерных соглашений вы просто дорогой багаж.

Я бы сказал, что предоставление вашим коллегам доступа к «видению» и «воздействию» кода — это нормальная и продуктивная практика в стартап-средах. Предоставление кому угодно (и это удваивается для тех, кто официально не занимается конкретными задачами) бесплатной возможности коммита/слияния с мастером — ужасная идея . С правильными настройками github и процессом проверки кода вы можете получить лучшее из обоих миров, позволяя вашему стартапу извлекать выгоду из идей и усилий большего количества людей, не скрывая, кто сделал большую часть работы, и не позволяя кому-то менее квалифицированному испортить вашу работу. демо. Помните, что при использовании такого инструмента, как GitHub, будет очевидно, кто что написал (если вы сделали 100 коммитов, а он — 2, должно быть совершенно ясно, что это преувеличение, когда ваш коллега называет себя «соразработчиком»).

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

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

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

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

Совместное использование исходного кода в неофициальном стартапе
СпросиСетьПолитика конфиденциальности1y, 0v