А тут ничего не было сказано про монетизацию разработки. Разработка происходит в компании-разработчике ровно по тем же правилам, по которым она происходит во всем мире и сейчас. В России очень мало (почти нет) компаний разработчиков, но это не меняет общие правила.
Компания-разработчика должна уметь переключаться на "более жирный проект". Как раз весь смысл в том, что она рыночная. При этом опен-сорс в ядре может выжить, а может и умереть, такое тоже случается.
Ну и наконец про государство. Я абсолютно не верю во что-то путное, что может сделать наше государство. Историю успеха оно не особо может показать. И тем не менее, схема не исключает софинансирование от государства (лично я считаю схему софинансирования единственным вариантом взаимодействия с государством, который имеет шансы не скатиться в профанацию). Но этот софит скорее всего будет опять же на уровне компании разработчика. Потому что ядро разработки не понятно как будет отчитываться за грант. По строчкам кода? А где гарантия, что эти строчки кому-то вообще нужны?
То, что вы описываете - довольно типичная ситуация в ПО для науки. Ну и тут два пути, либо тянуть ту же историю, которая есть сейчас, при этом, разумеется, у вас есть "конкуренты" и если ваша область востребована, они будут вас очень быстро догонять (для поточной обработки в памяти существует уже довольно много инструментов, и главным блокером для появления новых является, как это ни удивительно пакет Pandas). Или вы понимаете, что вам нужно развитие, и тогда вам придется заняться поэтапной модернизацией проекта, которая требует довольно много усилий.
Ну давайте начнем со слона в комнате, ваш пакет написан на Fortran. Живых людей вне метеорологии, кто писал бы на Fortran уже осталось очень мало. Это означает, что без дополнительных усилий будет довольно сложно привлечь комьюнити. Какие дополнительные усилия можно предпринять? Сделать поставку ядра приложения таким образом, чтобы другие люди могли ей пользоваться. Например сделать обертку на Python. В Python экосистеме это довольно распространенная практика, весь ScipPy так сделан. Сразу предупреждаю, что это не просто если вы до этого никогда этим не занимались. Надо разобраться с тем, как работают более или менее стабильные сборщики, научиться более или менее автоматически делать релизы и сделать минимальные тесты. Не просто, но и не фантастически сложно. Мотивированный студент за полгода должен разобраться.
Дальше вопрос о том, зачем и имеет ли смысл. Тут надо понять, востребован ли ваш пакет за пределами вашей задачи. Для этого лучше всего поискать профессиональные сообщества в вашей теме и закинуть туда вашу идею. У нас есть свое сообщество, и мы иногда занимаемся геоданными, но боюсь не настолько углубленно, чтобы был нужен отдельный пакет для анализа. Если сообщества нет, то можно его создавать. Это тоже не так уж просто (и именно этому могут существенно помочь open source хабы в вузах), но как минимум надо начать с того, чтобы опубликовать код в удобном виде. Можно на Github, возможно у вашего института или вузов, с которыми вы работаете есть какие-то свои хранилища. При этом, как вам уже писали, надо позаботиться о том, чтобы ваш код было удобно и приятно читать.
Теперь о шансах. Шансы, что кто-то со стороны быстро придет и начнет что-то добавлять в ваш сложный код на мертвом по сути языке довольно низкие. При этом если возникнут пользователи, то так или иначе качество кода будет улучшаться. Хотя бы потому, что люди будут приходить и задавать вопросы, по которым будут видны недостатки существующего кода. Может быть и критика, но критика означает в том числе интерес. Даже если сторонних контрибьютеров не будет, будут ваши собственные студенты, для которых публичный вклад в проект будет хорошим опытом и хорошей добавкой в портфолио.
Более того, Столмановское "свободы" зачастую вредны, а не полезны. Потому что не дают построить нормальную систему монетизации. Свободное ПО должно быть выгодно всем участникам процесса и только тогда будет развиваться.
Спасибо за статью. Интересно, что покажет голосование. Пока 100% за нехватку понимания. И это действительно главная проблема. Не только в смысле "зачем делать опенсорс", но и как он работает и какие у него могут быть бизнес-модели (многие все еще воспринимают его как чисто работу "за идею").
Есть еще один аспект, про который часто забывают. Отладка на JVM на порядки проще и удобнее, чем на JS или тем более в нативе. Какую-то сложную common-only логику удобно отлаживать на JVM, а в остальных местах просто использовать. С оговоркой о платформных типах, которая была выше.
Нет, это к сожалению не "детские" проблемы, а как раз проблемы, которые возникают при масштабировании. Это не отменяет того, что джулия весьма хороша в области прототипирования и изолированых научных задач. Но для больших многоцелевых фреймворков она вряд ли будет пригодна.
Не кажется. "Составлением уравнений" занимается в лучшем случае теоретик, да и то далеко не каждый. Это что-то типа одного процента от всех физиков, если не меньше. Я экспериментатор и совершенно точно могу сказать, что "составления уравнений" там очень мало.
А в остальном, я же написал. Если сказать, что физик отвечает за физику, а программист за программу, то ничего не работает. Потому что первый второму не может объяснить, что надо делать. Опять же как физик-программист могу сказать, что в вычислительных методах и анализе данных очень много нюансов, которые нельзя эффективно разрешить без понимания предметной области.
Ну собственно вы и тут и в другом своем комментарии подтверждаете один из моих поинтов из интервью. Вы утверждаете, что программирование сейчас и программирование 50 лет назад - это одно и тоже программирование. Это совсем не так. Это совсем другая дисциплина. Она имеет очень мало отношения к математике и очень много к инженерии. Я не готов тут полную лекцию про это рассказывать, так что просто буду апеллировать к своему опыту. Я начал что-то программировать где-то в конце 90-х и всю эту эволюцию очень хорошо вижу.
Людям, которые считают, что это "то же самое, что 50 лет назад", рекомендую пойти и почитать какие-нибудь форумы по веб бек-энд разработке современной и попробовать понять, что там происходит. И не говорите "это нам не нужно, у нас и так все работает".
Так я в первую очередь физик. И во со всей профессиональной уверенностью могу сказать, что сейчас нет проблем с алгоритмами. Зато есть куча проблем с фреймворками. Собственно по этой причине между изобретениям алгоритмов и и их внедрением проходит куча времени.
Есть и такое. Потому что разница зарплат слишком большая. Я же говорю о том, что должны быть систематическое решение. Нужно специально готовить "специалистов по мостам" и организовывать для них ставки. Не только в физике. Биология, география, гелология и так далее.
Тут есть еще одна проблема, про которую в интервью не было. Во многих научных организациях и проектах просто нет ставок для IT специалистов. Много публикаций по софту не напишешь, да и позиция там нужна не пост-дока, а подольше. Поэтому тут нужна еще инфраструктура самих научных организаций.
Сейчас идут другим путем. Создаются отдельные центры научного программирования, которые работают с научными организациями "на аутсорсе". Тоже вариант.
Все ваши утверждения верны. Но только именно в приложении к суперкомпьютерным алгоритмам. Если уйти от них, то все три пункта оказываются не совсем верными.
Фортран актуален на суперкомпьютерах. Но за пределами этой области не используется практически совсем. Я знаю некоторых людей, которые иногда на нем пишут "для себя", но сейчас на нем прекращают даже поддержку проектов. Не говоря о новых проектах.
В задачах по сбору и анализу данных "интерфейс" является первичным. Реализацию как раз всегда можно подменить. Есть разные алгоритмы для того, чтобы сделать одно и то же, но если нет абстракции, которая их изолирует, то под каждый алгоритм надо переписывать всю систему. Это очень расточительно.
Собственно то же, что и пункт 2. В фреймворках, возьмите тот же CERN ROOT дизайн является первичным, а реализации вторичными. Когда эти системы создавались, они зачастую создавались вокруг алгоритмов. Но уже давно эти алгоритмы стали сильно вариативными и дизайн системы играет в целом большую если не бОльшую роль. Если есть контрпример - пишите.
Скажу про то, что точно знаю. В физике частиц и биологии использование Python носит массовый характер. Там, где не Python, там архаичный кривой С++ где-то на уровне стандарта 98 года. Так что уже лучше Python. Julia отвоевала себе очень небольшую нишу. Я знаю буквально одну группу в физике частиц, которая ее использует.
Разделение на физиков и программистов де-факто есть. Но действительно, сейчас есть потребность его стереть. Проблема в том, что нельзя быть одновременно крутыми во всем, поэтому требуется создание самого понятия "физик-программист". Оно сейчас формируется в сознании людей, но еще не сформировалось.
А тут ничего не было сказано про монетизацию разработки. Разработка происходит в компании-разработчике ровно по тем же правилам, по которым она происходит во всем мире и сейчас. В России очень мало (почти нет) компаний разработчиков, но это не меняет общие правила.
Компания-разработчика должна уметь переключаться на "более жирный проект". Как раз весь смысл в том, что она рыночная. При этом опен-сорс в ядре может выжить, а может и умереть, такое тоже случается.
Ну и наконец про государство. Я абсолютно не верю во что-то путное, что может сделать наше государство. Историю успеха оно не особо может показать. И тем не менее, схема не исключает софинансирование от государства (лично я считаю схему софинансирования единственным вариантом взаимодействия с государством, который имеет шансы не скатиться в профанацию). Но этот софит скорее всего будет опять же на уровне компании разработчика. Потому что ядро разработки не понятно как будет отчитываться за грант. По строчкам кода? А где гарантия, что эти строчки кому-то вообще нужны?
Никому не пожелаю вернуться к WinCC.
У вас стоимость интеграции на порядки больше стоимости лицензии.
Умерла. В прошлом году делали обзор и уже почти неживая была.
То, что вы описываете - довольно типичная ситуация в ПО для науки. Ну и тут два пути, либо тянуть ту же историю, которая есть сейчас, при этом, разумеется, у вас есть "конкуренты" и если ваша область востребована, они будут вас очень быстро догонять (для поточной обработки в памяти существует уже довольно много инструментов, и главным блокером для появления новых является, как это ни удивительно пакет Pandas). Или вы понимаете, что вам нужно развитие, и тогда вам придется заняться поэтапной модернизацией проекта, которая требует довольно много усилий.
Кстати, куча свободных компиляторов фортрана. Кто мешает протестировать на любом из них?
Ну давайте начнем со слона в комнате, ваш пакет написан на Fortran. Живых людей вне метеорологии, кто писал бы на Fortran уже осталось очень мало. Это означает, что без дополнительных усилий будет довольно сложно привлечь комьюнити. Какие дополнительные усилия можно предпринять? Сделать поставку ядра приложения таким образом, чтобы другие люди могли ей пользоваться. Например сделать обертку на Python. В Python экосистеме это довольно распространенная практика, весь ScipPy так сделан. Сразу предупреждаю, что это не просто если вы до этого никогда этим не занимались. Надо разобраться с тем, как работают более или менее стабильные сборщики, научиться более или менее автоматически делать релизы и сделать минимальные тесты. Не просто, но и не фантастически сложно. Мотивированный студент за полгода должен разобраться.
Дальше вопрос о том, зачем и имеет ли смысл. Тут надо понять, востребован ли ваш пакет за пределами вашей задачи. Для этого лучше всего поискать профессиональные сообщества в вашей теме и закинуть туда вашу идею. У нас есть свое сообщество, и мы иногда занимаемся геоданными, но боюсь не настолько углубленно, чтобы был нужен отдельный пакет для анализа. Если сообщества нет, то можно его создавать. Это тоже не так уж просто (и именно этому могут существенно помочь open source хабы в вузах), но как минимум надо начать с того, чтобы опубликовать код в удобном виде. Можно на Github, возможно у вашего института или вузов, с которыми вы работаете есть какие-то свои хранилища. При этом, как вам уже писали, надо позаботиться о том, чтобы ваш код было удобно и приятно читать.
Теперь о шансах. Шансы, что кто-то со стороны быстро придет и начнет что-то добавлять в ваш сложный код на мертвом по сути языке довольно низкие. При этом если возникнут пользователи, то так или иначе качество кода будет улучшаться. Хотя бы потому, что люди будут приходить и задавать вопросы, по которым будут видны недостатки существующего кода. Может быть и критика, но критика означает в том числе интерес. Даже если сторонних контрибьютеров не будет, будут ваши собственные студенты, для которых публичный вклад в проект будет хорошим опытом и хорошей добавкой в портфолио.
Более того, Столмановское "свободы" зачастую вредны, а не полезны. Потому что не дают построить нормальную систему монетизации. Свободное ПО должно быть выгодно всем участникам процесса и только тогда будет развиваться.
Спасибо за статью. Интересно, что покажет голосование. Пока 100% за нехватку понимания. И это действительно главная проблема. Не только в смысле "зачем делать опенсорс", но и как он работает и какие у него могут быть бизнес-модели (многие все еще воспринимают его как чисто работу "за идею").
Есть еще один аспект, про который часто забывают. Отладка на JVM на порядки проще и удобнее, чем на JS или тем более в нативе. Какую-то сложную common-only логику удобно отлаживать на JVM, а в остальных местах просто использовать. С оговоркой о платформных типах, которая была выше.
Нет, это к сожалению не "детские" проблемы, а как раз проблемы, которые возникают при масштабировании. Это не отменяет того, что джулия весьма хороша в области прототипирования и изолированых научных задач. Но для больших многоцелевых фреймворков она вряд ли будет пригодна.
Не кажется. "Составлением уравнений" занимается в лучшем случае теоретик, да и то далеко не каждый. Это что-то типа одного процента от всех физиков, если не меньше. Я экспериментатор и совершенно точно могу сказать, что "составления уравнений" там очень мало.
А в остальном, я же написал. Если сказать, что физик отвечает за физику, а программист за программу, то ничего не работает. Потому что первый второму не может объяснить, что надо делать. Опять же как физик-программист могу сказать, что в вычислительных методах и анализе данных очень много нюансов, которые нельзя эффективно разрешить без понимания предметной области.
Ну собственно вы и тут и в другом своем комментарии подтверждаете один из моих поинтов из интервью. Вы утверждаете, что программирование сейчас и программирование 50 лет назад - это одно и тоже программирование. Это совсем не так. Это совсем другая дисциплина. Она имеет очень мало отношения к математике и очень много к инженерии. Я не готов тут полную лекцию про это рассказывать, так что просто буду апеллировать к своему опыту. Я начал что-то программировать где-то в конце 90-х и всю эту эволюцию очень хорошо вижу.
Людям, которые считают, что это "то же самое, что 50 лет назад", рекомендую пойти и почитать какие-нибудь форумы по веб бек-энд разработке современной и попробовать понять, что там происходит. И не говорите "это нам не нужно, у нас и так все работает".
Именно. Собственно время уже частично упущено. Потому что многие вещи проще заново написать, чем починить. Но лучше поздно, чем никогда.
Так я в первую очередь физик. И во со всей профессиональной уверенностью могу сказать, что сейчас нет проблем с алгоритмами. Зато есть куча проблем с фреймворками. Собственно по этой причине между изобретениям алгоритмов и и их внедрением проходит куча времени.
Забавно получать такие вопросы от интернет-анонимов. У меня вся информация в профиле. Там и список публикации не сложно найти.
Есть и такое. Потому что разница зарплат слишком большая. Я же говорю о том, что должны быть систематическое решение. Нужно специально готовить "специалистов по мостам" и организовывать для них ставки. Не только в физике. Биология, география, гелология и так далее.
Тут есть еще одна проблема, про которую в интервью не было. Во многих научных организациях и проектах просто нет ставок для IT специалистов. Много публикаций по софту не напишешь, да и позиция там нужна не пост-дока, а подольше. Поэтому тут нужна еще инфраструктура самих научных организаций.
Сейчас идут другим путем. Создаются отдельные центры научного программирования, которые работают с научными организациями "на аутсорсе". Тоже вариант.
Все ваши утверждения верны. Но только именно в приложении к суперкомпьютерным алгоритмам. Если уйти от них, то все три пункта оказываются не совсем верными.
Фортран актуален на суперкомпьютерах. Но за пределами этой области не используется практически совсем. Я знаю некоторых людей, которые иногда на нем пишут "для себя", но сейчас на нем прекращают даже поддержку проектов. Не говоря о новых проектах.
В задачах по сбору и анализу данных "интерфейс" является первичным. Реализацию как раз всегда можно подменить. Есть разные алгоритмы для того, чтобы сделать одно и то же, но если нет абстракции, которая их изолирует, то под каждый алгоритм надо переписывать всю систему. Это очень расточительно.
Собственно то же, что и пункт 2. В фреймворках, возьмите тот же CERN ROOT дизайн является первичным, а реализации вторичными. Когда эти системы создавались, они зачастую создавались вокруг алгоритмов. Но уже давно эти алгоритмы стали сильно вариативными и дизайн системы играет в целом большую если не бОльшую роль. Если есть контрпример - пишите.
Скажу про то, что точно знаю. В физике частиц и биологии использование Python носит массовый характер. Там, где не Python, там архаичный кривой С++ где-то на уровне стандарта 98 года. Так что уже лучше Python. Julia отвоевала себе очень небольшую нишу. Я знаю буквально одну группу в физике частиц, которая ее использует.
Разделение на физиков и программистов де-факто есть. Но действительно, сейчас есть потребность его стереть. Проблема в том, что нельзя быть одновременно крутыми во всем, поэтому требуется создание самого понятия "физик-программист". Оно сейчас формируется в сознании людей, но еще не сформировалось.
Julia на этом даже всю идеологию строит: https://juliadatascience.io/julia_accomplish#sec:two_language