Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Контора, которая пилит решение под свои бизнес-процессы, может выложить свой код в опенсорс. Только этот код никому не будет интересен, по той простой причине, что у конкурентов — свои бизнес-процессы, отличные от. А пилить универсальное решение безсмысленно — бизнесу нужно решение под конкретные имеющиеся бизнес-процессы.
Итог. Никто не будет использовать, тестировать и контрибутить в этот проект. Смысл опен-сорса — теряется.
Итог. Никто не будет использовать, тестировать и контрибутить в этот проект. Смысл опен-сорса — теряется.
Можно выкладывать в open source модули и плагины, которые могут быть использованы другими. Например, мы сейчас планируем пилить внутреннюю систему для контроля разработки и собираемся разделить её на 2 части — opensource ядро (Agile Board для разработчиков со счетчиком времени, который работает на Issue движке Gitlab) и генераторы отчетости, которые будем продавать, либо смиримся и родим мамонта. Но хотя бы ядро будет жить и обновляться, а это больше половины кодовой базы. В тот момент, когда мамонт умрет, нужно будет переписать только несколько гнилых кусков.
Компании тоннами рожают внутренние PHP-фреймворки, JS- библиотеки, сервера очередей и даже базы данных. И хоронят их так же тоннами. В таких случаях частенько их «узкозаточенность под бизнес-процессы» выдумывают из-за незнания best practices и нежелания погуглить или наличия ментального трения в восприятии трендов.
И нет, даже, если этот код никому не будет интересен для использования, это будет портфолио и мотиватор Ваших разработчиков. Да и код, который пишется публично, обычно пишется чище и старательнее. Плюсы все равно есть.
Компании тоннами рожают внутренние PHP-фреймворки, JS- библиотеки, сервера очередей и даже базы данных. И хоронят их так же тоннами. В таких случаях частенько их «узкозаточенность под бизнес-процессы» выдумывают из-за незнания best practices и нежелания погуглить или наличия ментального трения в восприятии трендов.
И нет, даже, если этот код никому не будет интересен для использования, это будет портфолио и мотиватор Ваших разработчиков. Да и код, который пишется публично, обычно пишется чище и старательнее. Плюсы все равно есть.
> В тот момент, когда мамонт умрет, нужно будет переписать только несколько гнилых кусков.
Наивная мысль. Мамонт умрёт не весь, и не так, как вы ожидаете. На рынке не будет ничего с совместимым Api (ни на уровне бинарной совместимости, ни кодовой, ни идеологической).
Переписывать придётся много, на порядок больше, чем можно подумать. Поэтому мамонты и живут много лет даже после обнаружения подходящий аналогов
Наивная мысль. Мамонт умрёт не весь, и не так, как вы ожидаете. На рынке не будет ничего с совместимым Api (ни на уровне бинарной совместимости, ни кодовой, ни идеологической).
Переписывать придётся много, на порядок больше, чем можно подумать. Поэтому мамонты и живут много лет даже после обнаружения подходящий аналогов
Не очень понял мысль: «На рынке не будет ничего с совместимым АПИ». Шанс, что совместимость будет с open source проектом, мне кажется, все же выше, чем шанс найти совместимость с проектом, который держится в корпоративных подземельях и гниет там. Если конечно не было отдельных «бюджетов под интеграцию».
Я находил совершенно дикие интеграции, которые писали фанаты той, или иной системы. Что стоит интерпритатор PHP как база для десктоп-Windows приложений с GUI.
К тому-же разработка из моего примера в принципе основана на интеграции с API другой open source системы, что как бы немножко намекает, что если мы будем стараться держать open source составляющую в адекватном состоянии, мы получим рабочую интеграцию с последней версией GitLab на момент смерти мамонта.
И да, я знаю, что они «живут долго после обнаружения аналогов». Только в статье я назвал это «смертью», потому что эти процессы гораздо более похожи. За мою практику такие проекты ничего больше, чем стыд технарей, неудобств, смятения новичков и нежелания о них думать руководства, не вызывают. А еще, да, в тяжелых случаях такая «жизнь» вызывает кадровую текучку. И такое я тоже видел.
Я находил совершенно дикие интеграции, которые писали фанаты той, или иной системы. Что стоит интерпритатор PHP как база для десктоп-Windows приложений с GUI.
К тому-же разработка из моего примера в принципе основана на интеграции с API другой open source системы, что как бы немножко намекает, что если мы будем стараться держать open source составляющую в адекватном состоянии, мы получим рабочую интеграцию с последней версией GitLab на момент смерти мамонта.
И да, я знаю, что они «живут долго после обнаружения аналогов». Только в статье я назвал это «смертью», потому что эти процессы гораздо более похожи. За мою практику такие проекты ничего больше, чем стыд технарей, неудобств, смятения новичков и нежелания о них думать руководства, не вызывают. А еще, да, в тяжелых случаях такая «жизнь» вызывает кадровую текучку. И такое я тоже видел.
Если конечно не было отдельных «бюджетов под интеграцию».
Шанс, что интеграция с проектом, у которого были бюджеты на интеграцию выше, чем с другими. Но, если не придумывать искусственных ограничений, то остальное Вам кажется.
Рабочую интеграцию Вы может и получите, но gitlab к тому моменту будет напоминать «cvslab», то есть какую то старинную даром не нужную штуку
Шанс, что интеграция с проектом, у которого были бюджеты на интеграцию выше, чем с другими. Но, если не придумывать искусственных ограничений, то остальное Вам кажется.
Рабочую интеграцию Вы может и получите, но gitlab к тому моменту будет напоминать «cvslab», то есть какую то старинную даром не нужную штуку
может выложить свой код в опенсорс. Только этот код никому не будет интересен, по той простой причине
Потому что без документации.
А исчерпывающую и красиво оформленную документацию по внутренним системам редко делают. Ибо там много общения личного.
> В мире есть прекрасные оттестированные аналоги, которые решают проблему гораздо лучше.
Зачастую это не так. И про оттестированные это очень громко.
> Open Source 1.Бесплатных тестировщиков
Нету их. Даже если вы будете пиарить Ваш проект.
> Open Source 2.Высокое качество кода
Это иллюзия. Как правильно написал ServPonomarev — оно высокое только если основному разработчику нужна та или иная функциональность. А как только ты используешь проект «по своему» — вылезают новые баги. И основному разработчику решать их нет никакого резона (сроки, бюджеты).
> Open Source 3. Имидж 4.Мотивация сотрудников
Это я считаю важно как для современных компаний так и разработчиков. Но на это надо выделять бюджеты на что готовы не все.
Зачастую это не так. И про оттестированные это очень громко.
> Open Source 1.Бесплатных тестировщиков
Нету их. Даже если вы будете пиарить Ваш проект.
> Open Source 2.Высокое качество кода
Это иллюзия. Как правильно написал ServPonomarev — оно высокое только если основному разработчику нужна та или иная функциональность. А как только ты используешь проект «по своему» — вылезают новые баги. И основному разработчику решать их нет никакого резона (сроки, бюджеты).
> Open Source 3. Имидж 4.Мотивация сотрудников
Это я считаю важно как для современных компаний так и разработчиков. Но на это надо выделять бюджеты на что готовы не все.
Да, согласен, причины смерти мамонта могут быть необоснованными. Но представьте, что ваша внутренняя разработка набирает обороты и сама замещает мамонтов у конкурентов. Шанс необоснованного убийства будет поменьше.
Про отсутствие тестировщиков: я вижу прямо противоположное. Откройте любой более — менее популярный репозиторий на гитхабе — вы найдете целую кучу issue, которые добавили проходящие мимо люди.
Качество кода высокое так же и за счет «правильного» процесса разработки с применением TDD, CI, code-review через PR, которые приняты вы open source. Посмотрите на репозиторий языка Rust для примера. Чтобы туда законтрибьютить, нужно сделать несколько подходов и учесть замечания команды. И люди делают свой вклад даже не смотря на драконовские проверки, потому что понимают обоснованность этого решения.
Конечно, если развивать проект как open source и забить на все принципы работы в этой сфере, упереться в хардкорный enterprise опыт и продолжать применять те же практики (пресс-релизы вместо общения, конференции с sales питчами, технические специалисты по устарелым технологиям), вы получите репозиторий с 1 звездочкой от собственного субподрядчика и треш-кодом в PR от стажеров. Можно будет смело рапортовать начальству, что идея провальная, деньги потрачены, а профита нет.
Но open source — это не просто выложить код на гитхаб, это еще и иной формат работы: публичное планирование, обсуждение фич, сбор обратной связи, формирование сообщества через соцсети и конференции. Это именно не дополнительная работа, а иная. В некоторых случаях большая, в некоторых — меньшая.
Есть примеры компаний, которые выбрали этот путь и результаты воодушевляют.
По поводу бюджетов раскройте пожалуйста мысль.
Про отсутствие тестировщиков: я вижу прямо противоположное. Откройте любой более — менее популярный репозиторий на гитхабе — вы найдете целую кучу issue, которые добавили проходящие мимо люди.
Качество кода высокое так же и за счет «правильного» процесса разработки с применением TDD, CI, code-review через PR, которые приняты вы open source. Посмотрите на репозиторий языка Rust для примера. Чтобы туда законтрибьютить, нужно сделать несколько подходов и учесть замечания команды. И люди делают свой вклад даже не смотря на драконовские проверки, потому что понимают обоснованность этого решения.
Конечно, если развивать проект как open source и забить на все принципы работы в этой сфере, упереться в хардкорный enterprise опыт и продолжать применять те же практики (пресс-релизы вместо общения, конференции с sales питчами, технические специалисты по устарелым технологиям), вы получите репозиторий с 1 звездочкой от собственного субподрядчика и треш-кодом в PR от стажеров. Можно будет смело рапортовать начальству, что идея провальная, деньги потрачены, а профита нет.
Но open source — это не просто выложить код на гитхаб, это еще и иной формат работы: публичное планирование, обсуждение фич, сбор обратной связи, формирование сообщества через соцсети и конференции. Это именно не дополнительная работа, а иная. В некоторых случаях большая, в некоторых — меньшая.
Есть примеры компаний, которые выбрали этот путь и результаты воодушевляют.
По поводу бюджетов раскройте пожалуйста мысль.
> с применением TDD, CI, code-review через PR, которые приняты вы open source.
Шутите? Откройте любой любительский проект, в который левые люди не контрибьютят (или 1-2 человека комитят 95%).
Шутите? Откройте любой любительский проект, в который левые люди не контрибьютят (или 1-2 человека комитят 95%).
Нет, не шучу. Именно это я и имею в виду. Ваш проект врядли будет популярен, если он написан без соблюдения этих практик. И как только Вы станете искать причины непопулярности у сообщества, тут же наткнетесь на «правильные» пути развития. Open source за Вас работу не сделает, он может помочь сделать её правильнее, если есть желание, но нет умения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как начать разработку внутреннего ПО и не родить мамонта