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