12 причин, почему технологии Wolfram — это не Open Source

от автора

И у меня на это 12 причиииииин...

И у меня на это 12 причиииииин…

На протяжении многих лет меня много раз спрашивали о моем мнении по поводу бесплатного программного обеспечения с открытым исходным кодом. Иногда эти вопросы были вызваны сравнением с каким-либо перспективным или недавно вошедшим в моду проектом с открытым исходным кодом, иногда сравнением с застойным проектом с открытым исходным кодом, а иногда убеждением, что технологии Wolfram были бы лучше, если бы они были с открытым исходным кодом.

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

Подскаст, посвященной это теме размещен в SoundCloud.

Большая часть этой статьи может быть подытожена двумя ответами: (1) бесплатное программное обеспечение с открытым исходным кодом может быть очень хорошим, но оно плохо справляется с тем, что мы пытаемся сделать; и большая часть причины в том, что (2) открытый исходный код распределяет разработку среди небольших, самостоятельно собирающихся групп, которые по отдельности решают части общей задачи, но масштабная, единая разработка требует централизованного контроля и постоянных усилий.

Я описал 12 причин, по которым считаю, что создание технологического стека Wolfram с использованием бесплатной модели с открытым исходным кодом было бы невозможным. Мне было бы интересно узнать ваше мнение в комментариях под этим блогом (и мне как переводчику тоже интересно узнать мнение пользователей Хабра в комментариях).

  1. Согласованное видение требует централизованного проектирования

  2. Языки высокого уровня требуют больше проектирования, чем языки низкого уровня

  3. Вам нужны междисциплинарные команды, чтобы объединить разрозненные области

  4. Трудные и скучные задачи тоже нужно делать

  5. Решения, которые принимаются коллективно, могут вам не нравиться

  6. Разработчики компании работают на компанию, а не только на себя

  7. Унифицированные вычисления требуют унифицированного дизайна

  8. Унифицированное представление требует унифицированного дизайна

  9. Открытый исходный код не выводит на рынок крупные технологические инновации

  10. Платное программное обеспечение предлагает открытые условия

  11. Для поддержания долгосрочных исследований и разработок необходим постоянный доход

  12. Плохой дизайн стоит дорого

1. Согласованное видение требует централизованного проектирования

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

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

Вы можете получить представление о том, как много всего происходит, просмотрев 300 с лишним часов прямых трансляций совещаний Wolfram Design Review.

Практические преимущества этого включают:

  • Сама концепция унифицированных вычислений во многом принадлежит Вольфраму

  • Высокая обратная и прямая совместимость по мере распространения вычислений на новые области

  • Согласованность различных видов вычислений (единый синтаксис, согласованная документация, общие типы данных, которые работают во многих функциях, и т.д.)

2. Языки высокого уровня требуют больше проектирования, чем языки низкого уровня

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

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

Практические преимущества этого включают:

  • Единый язык для всех областей кодирования (вычисления, наука о данных, создание интерфейсов, системная интеграция, отчетность, управление процессами и т. д.), позволяющий интегрировать рабочие процессы, для которых они сходятся.

  • Код, который в среднем в семь раз короче, чем на Python, в шесть раз короче, чем на Java, в три раза короче, чем на R.

  • Минимум зависимостей (отсутствие коллекций конкурирующих библиотек из разных источников с независимой и смещенной совместимостью).

3. Вам нужны междисциплинарные команды, чтобы объединить разрозненные области

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

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

Практические преимущества этого включают:

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

  • Задачи, в которых используются различные данные и вычислительные домены, не сложнее, чем задачи, специфичные для конкретного домена.

  • Появление новых областей, например, таких как блокчейн (да, эта статья довольно старая — из тех времен, когда криптовалюта была популярнее чем LLM, прим. переводчика).

4. Трудные и скучные задачи тоже нужно делать

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

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

Некоторые практические преимущества этого включают:

  • Десятки тысяч страниц последовательно и четко организованной документации с более чем 100 000 примеров.

  • Самый унифицированный интерфейс блокнота в мире, объединяющий рабочие процессы исследования, разработки кода, представления и развертывания в единое целое.

  • Развертывание по принципу на многих платформах как локально, так и в облаке один раз без адаптации к типу платформы.

5. Решения, которые принимаются коллективно, могут вам не нравиться

Плохое руководство — это всегда плохо, но хорошее руководство, как правило, лучше, чем компромиссы, достигнутые в комитетах.

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

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

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

На практике, если вы посмотрите на историю Wolfram Research, вы увидите:

  • Постоянная разработка всех аспектов технологического стека Wolfram.

  • Согласованность дизайна и совместимость кода и документов на протяжении 30 лет.

  • Постоянство цен и коммерческой политики на протяжении 30 лет.

6. Разработчики компании работают на компанию, а не только на себя

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

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

Практические преимущества включают:

7. Унифицированные вычисления требуют унифицированного дизайна

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

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

Типичные неуправляемые разработчики открытых исходных текстов с одним доменом не смогут легко добиться такой унификации, какими бы знатоками они ни были в своей области.

Практические преимущества этого включают:

  • Позволяет избежать затрат на переключение между системами и спецификациями. Избавляет от необходимости писать избыточный «склеивающий» код для объединения разных библиотек с разным дизайном.

  • Мгновенный доступ к непредвиденным в момент проектирования функциям без необходимости искать библиотеки.

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

  • Ориентированный на задачи дизайн языка Wolfram Language позволяет вашему коду получать преимущества от новых алгоритмов без необходимости его переписывать.

8. Унифицированное представление требует унифицированного дизайна

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

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

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

Практические примеры этого включают:

  • Язык Wolfram Language может использовать те же операции для создания или преобразования многих типов данных, документов, интерфейсов и даже самого себя.

  • Инструменты машинного обучения Wolfram автоматически воспринимают текст, звуки, изображения, числовые и категориальные данные.

  • Помимо выполнения геометрических расчетов, геометрические представления в языке Wolfram Language можно использовать для ограничения оптимизации, определения областей интеграции, управления огибающей визуализации, задания граничных значений для PDE-решателей, создания игровых объектов Unity и генерации 3D-моделей.

9. Открытый исходный код не выводит на рынок крупные технологические инновации

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

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

Хотя коммерческая модель, конечно, не гарантирует инноваций, стабильные потоки прибыли необходимы для финансирования долгосрочных усилий, необходимых для доведения инноваций до уровня пригодности продукта. За 30 лет компания Wolfram создала ключевые инновации, не в последнюю очередь благодаря концепции вычислений как единой унифицированной области.

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

Другие примеры инноваций Wolfram включают:

  • Вольфрам изобрел вычислительный блокнот, который был частично повторен Jupyter и другими.

  • Компания Wolfram изобрела концепцию автоматического создания интерактивных компонентов в блокнотах с помощью своей функции Manipulate (сейчас ее также используют другие компании).

  • Компания Wolfram разрабатывает автоматический выбор алгоритмов для всех суперфункций, ориентированных на решение задач (Predict, Classify, NDSolve, Integrate, NMinimize и т.д.).

10. Платное программное обеспечение предлагает открытые условия

Бесплатное программное обеспечение не безвозмездно. Оно может не стоить вам денег наперед, но есть и другие способы его монетизации, или же оно может обойтись вам дороже впоследствии. Альтернативные бизнес-модели, сопутствующие открытому исходному коду, а также отложенные и скрытые расходы могут вам подойти, но важно понимать их и их последствия. Если вы не задумываетесь об издержках или считаете, что их нет, то, скорее всего, впоследствии вы окажетесь в затруднительном положении.

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

«Открытый исходный код» — это зачастую просто бизнес-модель, которая в целом делится на четыре группы:

Freemium: Модель freemium — бесплатная базовая технология с дополнительными платными функциями (дополнительные библиотеки и наборы инструментов, процессорное время, развертывание и т. д.) — часто основывается на вашей неспособности предсказать свои долгосрочные потребности. Из-за инвестиций вашего времени в бесплатный компонент вы оказываетесь «слишком глубоко», когда вам нужно начинать платить. Проблема с этой моделью заключается в том, что она создает мотивацию для разработчика к дизайну, который кажется полезным, но не содержит важных компонентов, особенно функций, которые важны в последующей разработке или в производстве, таких как функции безопасности.

Коммерческие ловушки: Коммерческая ловушка заставляет вас поверить, что вы получаете что-то бесплатно, хотя это не так. В каком-то смысле модель Freemium иногда так и поступает, не сообщая заранее о том, какие детали вам в итоге понадобятся и за что придется платить. Но есть и другие, более прямые ловушки, например, бесплатное программное обеспечение, использующее запатентованную технологию. Вы получаете программу бесплатно, но как только вы начинаете ее использовать, вас начинают преследовать за патентные пошлины. Другая распространенная ловушка — свободное программное обеспечение, которое становится несвободным, как это произошло недавно с Java, или начинает включать несвободные компоненты, которые постепенно вбивают клин несвободной зависимости, пока поставщик не сможет потребовать от вас то, что он хочет.

Эксплуатация пользователей: Различные формы бизнес-моделей основаны на извлечении выгоды из вас и ваших взаимодействий. Самые распространенные из них — это подача вам рекламы, сбор данных о вас или предоставление вам предвзятых рекомендаций. Эта модель создает мотивацию для разработки рабочих процессов, направленных на максимизацию скрытой выгоды, например способов заставить вас увидеть больше рекламы, раскрыть больше ваших данных или продать влияние на вас. Хотя это не обязательно вредно, стоит попытаться понять, как вы предоставляете скрытую выгоду и считаете ли вы это приемлемым.

Бесплатность — побочный эффект: Программное обеспечение создается кем-то для собственных нужд, которые он не заинтересован коммерциализировать или защищать. Хотя это действительно свободное программное обеспечение, основной мотивацией разработчика являются его собственные потребности, а не ваши. Если ваши потребности не совпадают, это может привести к проблемам в поддержке или направлениях развития. Программное обеспечение, разработанное на средства исследовательских грантов, сталкивается с аналогичной проблемой. Гранты заставляют разработчиков уделять больше внимания тому, чтобы произвести впечатление на финансирующие организации, которые предоставляют гранты, чем тому, чтобы произвести впечатление на конечных пользователей программного обеспечения. Поскольку большинство исследовательских грантов выдаются на определенный срок, они также заставляют сосредоточиться на первоначальной поставке, а не на долгосрочной поддержке. В долгосрочной перспективе несовпадение интересов оборачивается для вас затратами времени и сил на адаптацию инструмента к вашим потребностям или на обход решений его разработчиков. Конечно, если ваше программное обеспечение финансируется за счет грантов или работы ученых и сотрудников, финансируемых государством, то вы также платите налоги — но, думаю, этого не избежать!

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

Безусловно, многие коммерческие компании, выпускающие платное программное обеспечение, вели себя очень плохо и были источником страха «блокировки поставщика», который делает открытый исходный код привлекательным. Иногда это происходит из-за несоответствия краткосрочных интересов руководства долгосрочным интересам компании, а иногда просто потому, что они считают это хорошей идеей. Все, что я могу сделать, это обратиться к истории Wolfram: за 30 лет мы сохранили цены и модели лицензирования удивительно стабильными (хотя каждый год вы получаете больше за свои деньги) и всегда избегали недокументированных, зашифрованных и неэкспортируемых форматов данных и документов и других неприятных трюков, связанных с блокировкой. Мы всегда старались быть незаменимыми, а не «запертыми».

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

Среди преимуществ выбранной нами модели — следующие:

  • Стек технологий «все в одном», в котором есть все, что нужно для решения конкретной задачи.

  • Никакого скрытого сбора данных, продажи или внешней рекламы.

  • Долгосрочное развитие и поддержка.

11. Для поддержания долгосрочных исследований и разработок необходим постоянный доход

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

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

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

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

Вы видите практическую пользу от постоянных, финансируемых клиентами инвестиций в технологии Wolfram:

12. Плохой дизайн стоит дорого

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

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

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

Вывод: Отказ от открытого исходного кода делает язык Wolfram Language возможным

Как я уже говорил в самом начале, модель с открытым исходным кодом может очень хорошо работать в небольших, замкнутых подмножествах вычислений, где небольшие команды могут сосредоточиться на локальных вопросах проектирования. Действительно, стек Wolfram Technology использует и вносит свой вклад в ряд отличных библиотек с открытым исходным кодом для специализированных задач, таких как MXNet (обучение нейронных сетей), GMP (высокоточные численные вычисления), LAPACK (численная линейная алгебра) и для многих из 185 форматов импорта/экспорта, автоматизированных с помощью команд Import и Export языка Wolfram Language. Там, где это имеет смысл, мы делаем самостоятельные проекты с открытым исходным кодом, такие как Wolfram Demonstrations Project, новый Wolfram Function Repository и такие компоненты, как Client Library for Python.

Но наше видение грандиозно — объединить все вычисления в единый связный язык, и для этого модель разработки FOSS не очень подходит.

Главный вопрос: как организовать такой грандиозный проект и как его финансировать, чтобы поддерживать усилия, необходимые для его разработки и последовательной реализации? Лицензии и цены — это детали, которые вытекают из этого. Создав компанию, которая может жестко координировать работу команд, и получая стабильный доход от продажи инструментов, которые нужны клиентам и за которые они с удовольствием платят, мы смогли добиться значительного прогресса в решении этой задачи, причем так, что уже готовы к следующему раунду разработки. Я не верю, что это было бы возможно при использовании подхода с открытым исходным кодом, и я не верю, что будущее, которое мы запланировали, будет таким же.

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

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


ссылка на оригинал статьи https://habr.com/ru/articles/846468/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *