Нет, не шучу. Именно это я и имею в виду. Ваш проект врядли будет популярен, если он написан без соблюдения этих практик. И как только Вы станете искать причины непопулярности у сообщества, тут же наткнетесь на «правильные» пути развития. Open source за Вас работу не сделает, он может помочь сделать её правильнее, если есть желание, но нет умения.
Да, согласен, причины смерти мамонта могут быть необоснованными. Но представьте, что ваша внутренняя разработка набирает обороты и сама замещает мамонтов у конкурентов. Шанс необоснованного убийства будет поменьше.
Про отсутствие тестировщиков: я вижу прямо противоположное. Откройте любой более — менее популярный репозиторий на гитхабе — вы найдете целую кучу issue, которые добавили проходящие мимо люди.
Качество кода высокое так же и за счет «правильного» процесса разработки с применением TDD, CI, code-review через PR, которые приняты вы open source. Посмотрите на репозиторий языка Rust для примера. Чтобы туда законтрибьютить, нужно сделать несколько подходов и учесть замечания команды. И люди делают свой вклад даже не смотря на драконовские проверки, потому что понимают обоснованность этого решения.
Конечно, если развивать проект как open source и забить на все принципы работы в этой сфере, упереться в хардкорный enterprise опыт и продолжать применять те же практики (пресс-релизы вместо общения, конференции с sales питчами, технические специалисты по устарелым технологиям), вы получите репозиторий с 1 звездочкой от собственного субподрядчика и треш-кодом в PR от стажеров. Можно будет смело рапортовать начальству, что идея провальная, деньги потрачены, а профита нет.
Но open source — это не просто выложить код на гитхаб, это еще и иной формат работы: публичное планирование, обсуждение фич, сбор обратной связи, формирование сообщества через соцсети и конференции. Это именно не дополнительная работа, а иная. В некоторых случаях большая, в некоторых — меньшая.
Есть примеры компаний, которые выбрали этот путь и результаты воодушевляют.
Цифры конверсий для «интернет-магазина за 20000р» и «за 3,5 ляма». Стоимости часа работы Ваших профессионалов различных компетенций, сколько часов каждого из них нужно на разработку проекта. Какие метрики вы таким образом достигаете.
Иначе выходит «слова + слова + слова + слова — слова * слова = цифра в рублях».
Можно выкладывать в open source модули и плагины, которые могут быть использованы другими. Например, мы сейчас планируем пилить внутреннюю систему для контроля разработки и собираемся разделить её на 2 части — opensource ядро (Agile Board для разработчиков со счетчиком времени, который работает на Issue движке Gitlab) и генераторы отчетости, которые будем продавать, либо смиримся и родим мамонта. Но хотя бы ядро будет жить и обновляться, а это больше половины кодовой базы. В тот момент, когда мамонт умрет, нужно будет переписать только несколько гнилых кусков.
Компании тоннами рожают внутренние PHP-фреймворки, JS- библиотеки, сервера очередей и даже базы данных. И хоронят их так же тоннами. В таких случаях частенько их «узкозаточенность под бизнес-процессы» выдумывают из-за незнания best practices и нежелания погуглить или наличия ментального трения в восприятии трендов.
И нет, даже, если этот код никому не будет интересен для использования, это будет портфолио и мотиватор Ваших разработчиков. Да и код, который пишется публично, обычно пишется чище и старательнее. Плюсы все равно есть.
Про отсутствие тестировщиков: я вижу прямо противоположное. Откройте любой более — менее популярный репозиторий на гитхабе — вы найдете целую кучу issue, которые добавили проходящие мимо люди.
Качество кода высокое так же и за счет «правильного» процесса разработки с применением TDD, CI, code-review через PR, которые приняты вы open source. Посмотрите на репозиторий языка Rust для примера. Чтобы туда законтрибьютить, нужно сделать несколько подходов и учесть замечания команды. И люди делают свой вклад даже не смотря на драконовские проверки, потому что понимают обоснованность этого решения.
Конечно, если развивать проект как open source и забить на все принципы работы в этой сфере, упереться в хардкорный enterprise опыт и продолжать применять те же практики (пресс-релизы вместо общения, конференции с sales питчами, технические специалисты по устарелым технологиям), вы получите репозиторий с 1 звездочкой от собственного субподрядчика и треш-кодом в PR от стажеров. Можно будет смело рапортовать начальству, что идея провальная, деньги потрачены, а профита нет.
Но open source — это не просто выложить код на гитхаб, это еще и иной формат работы: публичное планирование, обсуждение фич, сбор обратной связи, формирование сообщества через соцсети и конференции. Это именно не дополнительная работа, а иная. В некоторых случаях большая, в некоторых — меньшая.
Есть примеры компаний, которые выбрали этот путь и результаты воодушевляют.
По поводу бюджетов раскройте пожалуйста мысль.
Цифры конверсий для «интернет-магазина за 20000р» и «за 3,5 ляма». Стоимости часа работы Ваших профессионалов различных компетенций, сколько часов каждого из них нужно на разработку проекта. Какие метрики вы таким образом достигаете.
Иначе выходит «слова + слова + слова + слова — слова * слова = цифра в рублях».
Компании тоннами рожают внутренние PHP-фреймворки, JS- библиотеки, сервера очередей и даже базы данных. И хоронят их так же тоннами. В таких случаях частенько их «узкозаточенность под бизнес-процессы» выдумывают из-за незнания best practices и нежелания погуглить или наличия ментального трения в восприятии трендов.
И нет, даже, если этот код никому не будет интересен для использования, это будет портфолио и мотиватор Ваших разработчиков. Да и код, который пишется публично, обычно пишется чище и старательнее. Плюсы все равно есть.