Привет, Хабр! Недавно мы провели опрос, чтобы выяснить, что читатели Хабра думают об использовании открытых продуктов в финтехе — строго регулируемой и консервативной отрасли. Вопросы нам помогли составить эксперты компании Osnova, чей платежный процессинг на открытом коде позволяет любой компании оперативно разворачивать собственную платежную инфраструктуру. Мы проанализировали 558 ответов и заметили некоторые закономерности — ими и поделимся в этом посте.
Коробки не нужны
Мы начали наш опрос с ключевого вопроса — что предпочитают видеть в финтехе читатели Хабра: коробки или открытый код. Мы, конечно, знали, что опенсорс на Хабре любят, но перевес оказался всё равно неожиданно большим — за проприетарные решения проголосовало всего 6,81 %.
Остальные респонденты за открытый код — полностью или частично. Аж 51,43 % опрошенных — за полную открытость кода в финтехе.
22,94 % не столь категоричны, но всё равно осторожничают — они за то, чтобы ядро продукта было закрытым, а вот часть, которая нужна для внедрения в сторонние системы, может быть открытой и свободной. Правда, функциональность системы и определяется ядром. Это означает, что любое изменение под себя возможно только через разработчика продукта. Это отдельный контракт, где разработчик может диктовать любые условия, ведь его ничто не сдерживает, как и в случае с полностью закрытым продуктом.
Оставшиеся 18,82 % респондентов за опенсорс, но и к коробкам относятся спокойно: они не считают, что закрытость кода ведёт к программному рабству, потому что никто же не мешает перейти на другой продукт. Формально так и есть, но тут возникает вопрос стоимости этого перехода. Реальность такова, что переход с одного закрытого продукта на другой, с меньшей стоимостью лицензий, может окупаться годами. И по мнению наших экспертов, вендор-лок зависит в первую очередь не от лицензии, а от реализации программного продукта.
Не столько лицензия подразумевает вендор-лок, сколько решение, которое вы используете. Некоторые вещи сложно заменить другими. Могу рассказать историю из практики: когда мы разрабатывали наше решение, в самом-самом начале, нам очень подходило key-value-хранилище. И по ряду причин мы выбрали Riak — у него есть особенности API, которые очень хорошо подходили для наших задач, иначе нам пришлось бы делать некоторую обвязку. Однако компании, которая стояла за Riak, уже лет 6 как не существует. Хотя база до сих пор развивается Open-Source-сообществом, как и ряд других аналогичных решений, но специалистов на рынке уже нет. Казалось бы, ну что в этом такого, ну key-value и key-value: отдаёшь ключ — получаешь значение. Но, например, есть всякие дополнительные возможности: вторичные индексы, ещё что-то — с которыми прям очень хорошо. У нас получился такой прям вендор-лок на Riak, который стоил нам определённых усилий для избавления, и мы до сих пор с этим боремся.
Сергей Елин
тимлид ERLANG-разработчиков Osnova
Итак, за открытый код — большинство. Давайте рассмотрим более подробно, на чём основано это мнение наших респондентов.
Безопаснее ли в коробке
Ух ты! За коробки вновь меньшинство, но интересно другое — их опять 6,81 %! Случайность? Или всё же дело в том, что именно аспект безопасности в первую очередь повлиял на выбор респондентов в прошлом вопросе, когда они голосовали за полностью закрытый продукт?
А в каких случаях вопросы безопасности интересуют компании больше, чем вопросы развития собственных бизнес-процессов и связанные с этими вопросами модификации используемых продуктов? Когда компании могут подстроиться под предлагаемый коробочным решением бизнес-процесс — и это возможно, если компания ещё не слишком выросла. Ну или если решение идеально покрывает потребности компании, но в такое слабо верится — всё-таки небольшим компаниям важно гибко изменять свои бизнес-процессы в соответствии с изменениями рынка.
Крупные игроки рынка склонны выбирать проприетарные решения из соображений безопасности. Они полагаются на внешний аудит безопасности проприетарных решений, а сами не особо нуждаются в изменениях бизнес-процессов, либо готовы такими изменениями пренебречь.
14,16 % респондентов готовы отдать поиск багов на откуп сообществу — но при условии, что код всё ещё остается закрытым и ошибки исправляются исключительно вендором на основе отчётов пользователей.
Треть опрошенных — 37,81 % респондентов — считают открытую модель разработки более безопасной. Им важно самостоятельно убедиться в безопасности кода и контролировать процесс исправления ошибок. Аудит безопасности необходим, обычно это внутренняя история банка, но иногда она выходит за его пределы, когда набирается комьюнити из одной или нескольких компаний, которые готовы проводить эту работу публично и взаимодействовать с разработчиком.
А вот большинство респондентов (41,22 %) оказались смельчаками — они выбирают открытый код и верят в то, что естественный отбор продуктов под натиском кибератак рано или поздно покажет, кому доверять можно, а кому — нет. В таком подходе, конечно, есть рациональное зерно, но вряд ли кто-то в финтехе будет использовать продукт без достаточных гарантий. Хотя такой ответ может быть выбран просто потому, что собственных ресурсов на это не хватит.
Пилить или не пилить, вот в чём вопрос…
В вопросах допиливания под свои нужды сторонников идеи «отдать всё вендору, пусть сам возится» оказалось больше, чем в прошлые разы, уже 8,24 %. Они уверены, что финтех — это не место для ручной доработки напильником и лучше заплатить вендору, чтобы тот внёс необходимые изменения. Думаем, здесь тоже есть корреляция с прошлым вопросом: вендор обеспечивает безопасность, вендор обеспечивает и доработки. И если речь идёт об адекватных суммах и небольших изменениях, то почему бы и нет.
Большинство ответивших же, напротив, хотят и могут дорабатывать продукт — таких набралось аж 46,42 %. В этом вопросе энтузиастов даже чуть больше, чем мы насчитали в прошлый раз. Причины могут быть разными: иногда стоимость работ меньше, чем в случае с коробочным решением, а иногда контроль над решением важнее. Бывает так, что коробочное решение просто плохо вписывается в инфраструктуру и процессы, и тогда открытое решение будет дешевле. Впрочем, порой случается и наоборот.
Но не все сторонники открытого кода готовы сами работать напильником — 24,37 % предпочли бы, чтобы продукт был бесплатный, но доработка производилась его создателями или специалистами высокого класса. Ведь кто, как не разработчик продукта, знает все его нюансы. А значит, он доработает решение с меньшими затратами времени и средств.
В этом случае за поддержку решения вполне разумно заплатить. Многие Open-Source-продукты, например GitLab, так и развиваются, предоставляя платную поддержку и контрактное сопровождение специфических запросов клиентов, точно так же как это делают проприетарные вендоры. Да, у GitLab есть лицензионная Enterprise Edition, но поддержка и сопровождение составляют значительную долю доходов. Когда твой исходный код открыт, ты не можешь задирать цены на реализацию более-менее востребованных фич, так как с определённого уровня цен клиенту будет выгоднее нанять собственную команду для разработки. Поэтому стоимость контрактов на поддержку в случае открытого ПО ниже.
А у пятой части респондентов — 21 % — просто не хватает ресурсов на допиливание. Когда компания небольшая, проще не подстраивать продукты под себя, а подстроить собственные процессы под продукт. И такое встречается чаще, чем можно подумать.
Крупные вендоры и открытый код: YES/NO?
В вопросе о том, определит ли открытый код в будущем, выживет ли условный Facebook или даже Microsoft, перевес в сторону опенсорса уже не так велик — лишь около 38 % посчитали, что на каком-то этапе своего развития большая часть важного и критичного софта будет именно с открытыми исходниками. И при этом почти 28 % полагают, что компании будут всё больше закрываться инфраструктурно даже при наличии открытых исходников. А чуть больше 20 % склоняются к тому, что если что-то и будет открываться, то незначительная часть, и то ради маркетинга. Ещё 13,26 % считают, что компании будут открывать исходные коды просто потому, что это не повлияет на их доход, так как они зарабатывают на доступе к сервисам. В результате какого-то преобладающего мнения нет: примерно 48 % считают, что так или иначе будут преобладать закрытые решения, а оставшиеся респонденты склоняются в сторону открытости ПО в крупных компаниях.
Сложно ответить однозначно, в каком направлении будут двигаться вендоры. Но, скорее всего, все эти векторы развития будут существовать параллельно, в зависимости от рода деятельности, размера и выбранной бизнес-модели компании-разработчика. Да и опрос показывает, что доминирующее мнение о необходимости открытия исходников на деле не так уж сильно отрывается от остальных, чтобы говорить от том, что именно по этому сценарию пойдёт развитие крупных корпораций.
А вдруг украдут?
Тут мы посмотрим глазами разработчиков на дилемму: открывать код или не стоит. Оптимистов, которые верят в то, что в мире открытого кода не принято воровать, немного — всего 6,81 %. Интересно, что противоположных им по мнению сторонников «всё спрятать, а то любой желающий украдёт» гораздо больше — почти 25 %.
Остальные участники опроса не бросаются в крайности и оценивают риски взвешенно. 37 % разделяют мнение создателей Osnova, что для достаточно крупного продукта риск создания форка, который бы мог вытеснить родительский продукт, крайне невысоки, ведь для этого нужно знать систему не хуже разработчика. Ещё чуть больше 31 % респондентов тоже не боятся открытого кода, но в защите своих ноу-хау полагаются на патенты и закон.
Попробуем разобраться. Допустим, мы не очень большая компания и наше решение приглянулось крупному игроку. Последнему, чтобы взять наше решение и развивать его как собственный продукт, понадобится задействовать ресурсы, которые будут на порядок превосходить наши ресурсы. Ему ещё нужно разобраться в системе, проанализировать узкие места и в короткие сроки «догнать» разработчика, иначе конкурировать с нами он не сможет. Опять же, есть юридические и репутационные риски. Крупной корпорации проще купить в этом случае разработчика, возможно даже предоставив ему большую степень свободы в своих действиях в отношении развития продукта. Это неплохой сценарий, взаимовыгодный. Что касается патентов, то заморачиваться с ними стоит, только если решение настолько прорывное, что переворачивает всё с ног на голову, иначе может оказаться так, что овчинка не стоит выделки.
Но есть также и другой сценарий развития событий. Когда продукт предоставляет некоторый сервис, существует риск того, что кто-то просто будет периодически забирать исходники и начнёт предоставлять точно такой же сервис. Такие прецеденты уже встречались, взять хотя бы Sentry, популярную систему мониторинга и логирования приложений. Она в своё время провела ряд изменений в политике лицензирования, когда столкнулась с тем, что некоторые недобросовестные компании занимались откровенным плагиатом как исходного кода, так и маркетинговых материалов, чтобы напрямую конкурировать с компанией. Тем не менее Sentry сохранила свою открытую модель разработки, используя исключительно юридические рычаги воздействия на недобросовестных конкурентов.
Роман Шеховцов, корпоративный архитектор Центра развития финансовых технологий РСХБ, в диалоге со спикером «Основы» высказал интересную мысль:
“
Я за конкуренцию. Я считаю, что это очень полезно, и в первую очередь для основного разработчика. Во-первых, там (с форком другой компании) может быть своя история, и они пойдут в другом направлении, перестав быть конкурентами. Но скорее всего, как Сергей (спикер Osnova) рассказывал, придут с форком к основному разработчику. Потому что никто не знает продукт лучше его изначального разработчика. Ну, а конкуренция — она подстёгивает, заставляет делать продукт лучше, неинтересно же пилить продукт, когда сравнить не с кем
За «бесплатное» можно и доплатить
Вновь категоричных сторонников опенсорса большинство — 48,75 % опрошенных готовы платить за коммерческие версии, поддержку и всячески стимулировать развитие открытого продукта. Это коррелирует с количеством респондентов, которые хотят и могут дорабатывать исходный код. Выглядит логично, так как иногда такой подход позволяет перенаправить собственные ресурсы на решение более специфичных для компании задач на выбранном стеке, воспользовавшись поддержкой разработчика, который знает свой продукт намного лучше. А значит, коммерческая версия порой может оказаться дешевле собственной разработки.
Четверть опрошенных хабровчан (25,63 %) платить тоже готовы, но только за техническую поддержку и доработку. Тут отсутствует собственная активная разработка, поэтому энтерпрайз-версии выглядят такими же проприетарными решениями, как и полностью закрытый код.
19,35 % готовы использовать открытый исходный код в рамках лицензий, но не готовы платить ни в каком виде разработчику.
А 6,27 % опрошенных просто готовы творить с кодом что угодно. Скорее всего, это всё те же респонденты, которые ранее были за закрытый код — не очень знакомые с опенсорсом на практике, они не понимают, что им может помешать. «Вот код, и я могу его взять и буду делать с ним всё, что захочу, кто ж меня остановит?» А ведь в финтехе (внезапно!) есть чуть больше институтов, регулирующих эти вопросы. За неправомерное использование программного обеспечения банк может не только крупный штраф схлопотать, но и, если скандал выйдет на международный уровень, доиграться до отзыва лицензии.
Пациент скорее выживет, чем нет
Сложная техническая система живуча, если способна выполнять свои функции после повреждения или разрушения её отдельных элементов. В нашем следующем вопросе мы интересовались: а что будет с Open-Source-системой после отказа одного из самых главных её компонентов — основного разработчика — от дальнейшей разработки этой системы?
21,51 % считают, что открытость может кода спасти продукт от гибели. Ещё 37,81 % считают, что не всегда: если какие-то компоненты завязаны на внутренние решения компании (сервера, закрытые микросервисы и т. п.), то без них получится «машина без колёс». Казалось бы, всё на месте, но не едет — и вам придётся переписывать ключевые компоненты самостоятельно. Но, по правде говоря, такое решение сложно назвать полностью открытым.
33,69 % ответивших склоняются к мнению, что открытый код в мире финтеха ещё не означает, что всё будет работать. Вам придётся заново и самостоятельно поднимать инфраструктуру вокруг решения, договариваясь с платёжными системами, банками, самостоятельно проходить все регуляторные процедуры и сертификацию. Реалии таковы, что финтех обязан иметь собственную инфраструктуру и минимально зависеть от внешних поставщиков, а программное обеспечение зачастую нуждается в доработке. То есть, это возможно независимо от того, есть ли у продукта разработчик или нет, иногда компания или группа компаний, использующих исходный код, подхватывают падающее знамя разработки просто потому, что они очень сильно завязаны на продукт. Это и произошло с Riak, как уже упоминал Сергей из Оsnova.
6,99 % опрошенных согласны с тем, что код зависит от конкретных личностей. Уже в который раз мы видим эту цифру, близкую к 6,81 %, и это наводит на определённые мысли о связи со сторонниками коробок. Что ж, здесь они высказывают не лишённое оснований мнение: бывает, что проект просто затухает без ведущих разработчиков, так как ни у кого больше нет достаточной экспертизы и мотивации для его развития.
Но есть ещё одна серьёзная опасность, особенно когда за проектом стоит небольшая группа людей или вообще один разработчик. Дело в том, что открытый исходный код очень просто… закрыть! Нажал владелец кнопку, ввёл подтверждение — и нет больше репозитория! Мы как-то привыкли, что открытый исходный код существует как данность и никуда не девается. Можно тут вспомнить случай из опыта нашего эксперта, который зашёл на страницу репозитория Actix Web, использовавшегося в его проекте, и был очень удивлён, получив 404-й ответ. Сначала удивлён, а потом шокирован, когда понял, что у него не сохранилось последней версии репозитория с влитыми багфиксами. Никому даже в голову не пришло, что открытый код может просто исчезнуть! К счастью, разработчик в итоге передал исходники в комьюнити, и разработка продолжилась.
Или вот взять CentOS в её классическом исполнении. За ней стоит огромная компания: Red Hat по праву считается одним из крупнейших поставщиков корпоративных решений для серверов и десктопов. Это коммерческий Linux, занимающий до 95 % мощностей инфраструктуры некоторых компаний. CentOS как открытая версия Red Hat Enterprise для многих компаний была основой инфраструктуры и ступенькой, по которой заходила коммерческая версия. И тут Red Hat говорят: мы CentOS как проект с фиксированными версиями сворачиваем, поддержку через год прекращаем, вот вам роллинг-релизы. Но в финтехе важна стабильность, поэтому немногие готовы вскочить на роллинг-релиз, нет уверенности, что подобные релизы будут тестироваться должным образом. А взять и переехать на первый попавшийся дистрибутив не так просто: есть собственная специфика. Что делать? Возможно, стоит поискать форк. Их сейчас три, самым перспективным для финтеха выглядит пока оракловский. Тоже крупная компания, авось не бросят.
Vendor lock-in всё ещё возможен
Что ж, проблема vendor lock-in, похоже, и впрямь беспокоит пользователей и разработчиков. Так что ещё один вопрос был целиком посвящён тому, станет ли вообще открытый исходный код спасением от неё.
Почти четверть респондентов (24,19 %) уверены, что открытый код не гарантирует защиту от vendor lock-in, что всегда можно заблокировать инфраструктуру вокруг него. Ряды скептиков дополняют и следующие 16,49 %, которые считают, что вендор может ограничить использование кода в новых версиях не физически, а лицензионно. Вы сможете продолжать использовать старые версии, но не получите доступ к новым возможностям и API, и ваш код превратится в тыкву. Оба этих ответа в сумме близки к 37,81 % ответов предыдущего вопроса, и мы можем предположить, что блокирования инфраструктуры или изменения лицензий проектов опасаются очень многие. Возможно, эти страхи и мешают им уверенно использовать продукты с открытым исходным кодом.
36,74 % верят в открытый код больше и полагают, что открытость исходного кода может всё же помочь, хоть и частично, — она позволит или выиграть время на замену компонентов, или перейти на другое решение. А оптимистов в этот раз не так много, менее четверти — лишь 22,58 % уверены, что открытый код свободен от vendor lock-in и он не только даёт выгоду, но также ограждает пользователей от действий производителя. Однако мы тут вместо долгих рассуждений просто напомним про Riak, Actix Web и CentOS (см. выше), да и вы можете продолжить список в комментариях. Так что тут всё индивидуально — какой-то код позволяет избежать vendor lock-in, какой-то не очень.
И профи открыты открытому коду
Раз уж взялись про стереотипы мнений в отношении открытого кода, то нельзя было не спросить хабровчан, правда ли они считают, что открытое ПО — удел любителей. И вновь противников опенсорса с мнением, что в открытый код котрибьютит кто попало, оказалось меньше всех. Знаете сколько? Ну вы поняли — 6,81 %!
9,32 % полагают, что крупные игроки рынка софта относятся с осторожностью к открытому коду потому, что сами пользователи, увидев код, возмутятся: «Что это за ужас вы нам продаёте?».
44,98 % респондентов вновь оптимистичны и считают, что открытый исходный код — это лицо компании, так что поддерживать его будут на высоком уровне, чтоб не стыдно показать было. И ещё немалая доля хабровчан — 39,89 % — полагают, что открытость не равна анархии, потому что открыты только исходники, а сама разработка ничем не отличается от проприетарной.
С некоторыми мнениями и мы бы согласились, потому что код проприетарного продукта порой действительно может вселять ужас — впрочем, и среди опенсорса такое иногда случается. Но часто бывает, что опенсорс — это побочный продукт коммерческой деятельности, направленный на обкатку решений силами комьюнити, и там будут те же правила, код-ревью, тестирование и контроль качества на всех этапах. Да и само комьюнити многое делает: всем же нужен качественный код, и в итоге все в выигрыше. А уже имея качественный код на руках — держим марку и продвигаем бренд. Так что, когда мы говорим о достаточно большом и популярном продукте, вряд ли можно назвать его разработчиков и пользователей любителями. Скажем больше: когда нас начинающие разработчики спрашивают, где посмотреть примеры хорошего исходного кода, мы удивляемся: «Да вон же опенсорс-проекты лежат, по вашим темам, написанные профессионалами, смотрите на здоровье!».
За ваши деньги — что угодно
Мы уже выяснили, что за доработку открытого кода хабровчане платить в целом готовы, а как насчёт техподдержки?
Категоричные «нет» — пусть и по разным причинам — выразили очень малые доли опрошенных (3,76 % считают, что к коду имеют доступ слишком много людей и полного контроля тут быть не может, а ещё 4,12 % лучше за эти деньги свою поддержку организуют). Опять в сумме около 7 %… ну ладно, чуть больше, но картина всё равно знакомая. Совпадение? Не думаем.
16,85 % респондентов тоже озабочены контролем — полагают, что платная поддержка возможна, но при условии полного контроля разработки. И 19,18 % выбрали ответ: «Да, но чтобы она не мешала заработку экспертов из сообщества или сторонних компаний, специализирующихся на техподдержке». Например, это может выглядеть так: основное ядро процессинга поддерживает разработчик, а адаптеры — дополнительные микросервисы, умеющие работать с этим ядром, — их создатели. Но мы ведь в реальном мире живём, как же здоровая конкуренция?
Зато большинство в этом пункте опроса абсолютное — 56,09 % за идею платной техподдержки, потому что, хоть технически грамотный клиент и сам может развернуть крупное решение, подобное Osnova, в финансовой сфере лучше всё-таки оставить вопрос техподдержки в руках авторов кода. Этот результат должен порадовать коллег из Osnova, хотя мы бы поспорили с тем, что в финтехе не принято городить свои платёжные системы на коленке. Ещё как разворачивают и даже собственные форки запиливают. Порой приходят в ту же Osnova с вопросами, предложениями и готовыми кейсами. Ну и иногда за техподдержкой — тоже взаимовыгодно.
Какие критерии важны, какие критерии нужны
Ну что ж, если большинство всё-таки за открытый код в финтехе, то по каким критериям хабровчане выбирали бы платёжную систему на основе открытого кода? Вот мы их об этом и спросили.
Просто посмотрим на распределение результатов:
Документированность даже чуть-чуть обгоняет безопасность, а вместе они занимают почти половину ответов. Дальше идёт открытость кода, возможность доработки под себя и масштабируемость. Вместе с ответами про документацию эти три вопроса набирают примерно такое же количество процентов, как и предыдущие вопросы про доработку продукта. Это ожидаемо и похоже на правду. Замыкают рейтинг репутация компании и недорогая стабильная поддержка.
Почему документация так вырвалась вперёд? Потому что встречаются плохо документированные продукты, интеграция которых превращается в боль, потерянные часы и дни в попытках понять, как же это всё заставить работать. С хорошей документацией можно спрогнозировать темпы работ и избежать многих неприятностей, а с плохой — запросто сорвать дедлайны и понести убытки. А чтобы не понести убытки, важна также и безопасность, может, поэтому они вместе лидируют с почти равными голосами?
Made in Russia?
Что ещё может влиять на выбор финтех-продукта? Мы решили выяснить, важна ли для хабровчан страна происхождения открытого кода.
Приятно видеть, что космополитов, не обращающих внимания на гражданство кода, больше половины. А вот 23,30 %, хоть и поддерживают международное взаимодействие, хотели бы видеть основной состав команды из России — потому что ему будет лучше знакома специфика страны. 13,80 % за решения только от российских разработчиков. 9,32 %, напротив, опасаются, что российские продукты могут не одобрить за рубежом просто потому, что они как раз из России.
Платёжная система на опенсорсе — зверь редкий
И это факт. А вот почему так получается — мы спросили пользователей Хабра.
Очень мало людей считает, что это не интересно (8,78 %). В основном обращают внимание на сложность (32,62 %), исторические причины (24,55 %), организационные (21,51 %) и финансовые (12,54 %). Сложность у таких продуктов действительно высокая, соответственно высоки и затраты, а с ними риски, да и конкурировать приходится. Из этого можно сделать вывод, что выйти на рынок с таким решением непросто.
Есть ли будущее у Open Source в финтехе?
Про сторонников проприетарности и закрытого кода в этом вопросе можно сказать кратко: 6,99 %. Мы уже привыкли. Но стабильность радует — люди тверды в своей позиции.
Удивительно, но оптимисты, которые за полную открытость и энтузиазм, на этот раз сдали позиции и заняли лишь второе место, набрав 38,89 % голосов. Большинство же респондентов считают, что опенсорс — это, конечно, круто и интересно, но рынок финтеха пока к нему не готов, вот, может, не в ближайшее время, а когда-нибудь потом…
Что ж, на этом вопросы закончились. Но завершить наш анализ мы бы хотели цитатой эксперта, которая лучше всего подведёт черту под размышлениями об опенсорсе в финтехе:
Когда мы смотрим на какой-то продукт, мы в первую очередь смотрим ведь не на то, открыт код или закрыт. Мы смотрим на то, насколько эффективно он помогает решить наши проблемы и насколько хорошо выполняет наши задачи. Если мы говорим о каких-то областях применения, то найти хорошее, качественное Open-Source-решение можно и не смочь, его просто нет. Но открытость при прочих равных — приятный плюс. Мы же не всё разрабатываем сами, стараемся также использовать Open-Source-решения. Можно посмотреть продукт, понять, насколько он хорошо может удовлетворить потребности конечного пользователя, разобраться, как он работает, заглянув в исходники. Мы понимаем, что сам по себе продукт никому не интересен на рынке; интересно, насколько хорошо, эффективно и недорого он позволяет решать проблемы наших клиентов.
Сергей Елин
тимлид ERLANG-разработчиков Osnova
Надеемся, и опрос, и наш анализ были вам интересны. Если у вас появились какие-то свои мысли и гипотезы, почему ответы склонялись в ту или иную сторону, а также если у вас был и/или есть свой опыт в части опенсорса в финтехе — поделитесь в комментариях, будет здорово.
Привет, Хабр! Недавно мы провели опрос, чтобы выяснить, что читатели Хабра думают об использовании открытых продуктов в финтехе — строго регулируемой и консервативной отрасли. Вопросы нам помогли составить эксперты компании Osnova, чей платежный процессинг на открытом коде позволяет любой компании оперативно разворачивать собственную платежную инфраструктуру. Мы проанализировали 558 ответов и заметили некоторые закономерности — ими и поделимся в этом посте.
Коробки не нужны
Мы начали наш опрос с ключевого вопроса — что предпочитают видеть в финтехе читатели Хабра: коробки или открытый код. Мы, конечно, знали, что опенсорс на Хабре любят, но перевес оказался всё равно неожиданно большим — за проприетарные решения проголосовало всего 6,81 %.
Остальные респонденты за открытый код — полностью или частично. Аж 51,43 % опрошенных — за полную открытость кода в финтехе.
22,94 % не столь категоричны, но всё равно осторожничают — они за то, чтобы ядро продукта было закрытым, а вот часть, которая нужна для внедрения в сторонние системы, может быть открытой и свободной. Правда, функциональность системы и определяется ядром. Это означает, что любое изменение под себя возможно только через разработчика продукта. Это отдельный контракт, где разработчик может диктовать любые условия, ведь его ничто не сдерживает, как и в случае с полностью закрытым продуктом.
Оставшиеся 18,82 % респондентов за опенсорс, но и к коробкам относятся спокойно: они не считают, что закрытость кода ведёт к программному рабству, потому что никто же не мешает перейти на другой продукт. Формально так и есть, но тут возникает вопрос стоимости этого перехода. Реальность такова, что переход с одного закрытого продукта на другой, с меньшей стоимостью лицензий, может окупаться годами. И по мнению наших экспертов, вендор-лок зависит в первую очередь не от лицензии, а от реализации программного продукта.
Не столько лицензия подразумевает вендор-лок, сколько решение, которое вы используете. Некоторые вещи сложно заменить другими. Могу рассказать историю из практики: когда мы разрабатывали наше решение, в самом-самом начале, нам очень подходило key-value-хранилище. И по ряду причин мы выбрали Riak — у него есть особенности API, которые очень хорошо подходили для наших задач, иначе нам пришлось бы делать некоторую обвязку. Однако компании, которая стояла за Riak, уже лет 6 как не существует. Хотя база до сих пор развивается Open-Source-сообществом, как и ряд других аналогичных решений, но специалистов на рынке уже нет. Казалось бы, ну что в этом такого, ну key-value и key-value: отдаёшь ключ — получаешь значение. Но, например, есть всякие дополнительные возможности: вторичные индексы, ещё что-то — с которыми прям очень хорошо. У нас получился такой прям вендор-лок на Riak, который стоил нам определённых усилий для избавления, и мы до сих пор с этим боремся.
Сергей Елин
тимлид ERLANG-разработчиков Osnova
Итак, за открытый код — большинство. Давайте рассмотрим более подробно, на чём основано это мнение наших респондентов.
Безопаснее ли в коробке
Ух ты! За коробки вновь меньшинство, но интересно другое — их опять 6,81 %! Случайность? Или всё же дело в том, что именно аспект безопасности в первую очередь повлиял на выбор респондентов в прошлом вопросе, когда они голосовали за полностью закрытый продукт?
А в каких случаях вопросы безопасности интересуют компании больше, чем вопросы развития собственных бизнес-процессов и связанные с этими вопросами модификации используемых продуктов? Когда компании могут подстроиться под предлагаемый коробочным решением бизнес-процесс — и это возможно, если компания ещё не слишком выросла. Ну или если решение идеально покрывает потребности компании, но в такое слабо верится — всё-таки небольшим компаниям важно гибко изменять свои бизнес-процессы в соответствии с изменениями рынка.
Крупные игроки рынка склонны выбирать проприетарные решения из соображений безопасности. Они полагаются на внешний аудит безопасности проприетарных решений, а сами не особо нуждаются в изменениях бизнес-процессов, либо готовы такими изменениями пренебречь.
14,16 % респондентов готовы отдать поиск багов на откуп сообществу — но при условии, что код всё ещё остается закрытым и ошибки исправляются исключительно вендором на основе отчётов пользователей.
Треть опрошенных — 37,81 % респондентов — считают открытую модель разработки более безопасной. Им важно самостоятельно убедиться в безопасности кода и контролировать процесс исправления ошибок. Аудит безопасности необходим, обычно это внутренняя история банка, но иногда она выходит за его пределы, когда набирается комьюнити из одной или нескольких компаний, которые готовы проводить эту работу публично и взаимодействовать с разработчиком.
А вот большинство респондентов (41,22 %) оказались смельчаками — они выбирают открытый код и верят в то, что естественный отбор продуктов под натиском кибератак рано или поздно покажет, кому доверять можно, а кому — нет. В таком подходе, конечно, есть рациональное зерно, но вряд ли кто-то в финтехе будет использовать продукт без достаточных гарантий. Хотя такой ответ может быть выбран просто потому, что собственных ресурсов на это не хватит.
Пилить или не пилить, вот в чём вопрос…
В вопросах допиливания под свои нужды сторонников идеи «отдать всё вендору, пусть сам возится» оказалось больше, чем в прошлые разы, уже 8,24 %. Они уверены, что финтех — это не место для ручной доработки напильником и лучше заплатить вендору, чтобы тот внёс необходимые изменения. Думаем, здесь тоже есть корреляция с прошлым вопросом: вендор обеспечивает безопасность, вендор обеспечивает и доработки. И если речь идёт об адекватных суммах и небольших изменениях, то почему бы и нет.
Большинство ответивших же, напротив, хотят и могут дорабатывать продукт — таких набралось аж 46,42 %. В этом вопросе энтузиастов даже чуть больше, чем мы насчитали в прошлый раз. Причины могут быть разными: иногда стоимость работ меньше, чем в случае с коробочным решением, а иногда контроль над решением важнее. Бывает так, что коробочное решение просто плохо вписывается в инфраструктуру и процессы, и тогда открытое решение будет дешевле. Впрочем, порой случается и наоборот.
Но не все сторонники открытого кода готовы сами работать напильником — 24,37 % предпочли бы, чтобы продукт был бесплатный, но доработка производилась его создателями или специалистами высокого класса. Ведь кто, как не разработчик продукта, знает все его нюансы. А значит, он доработает решение с меньшими затратами времени и средств.
В этом случае за поддержку решения вполне разумно заплатить. Многие Open-Source-продукты, например GitLab, так и развиваются, предоставляя платную поддержку и контрактное сопровождение специфических запросов клиентов, точно так же как это делают проприетарные вендоры. Да, у GitLab есть лицензионная Enterprise Edition, но поддержка и сопровождение составляют значительную долю доходов. Когда твой исходный код открыт, ты не можешь задирать цены на реализацию более-менее востребованных фич, так как с определённого уровня цен клиенту будет выгоднее нанять собственную команду для разработки. Поэтому стоимость контрактов на поддержку в случае открытого ПО ниже.
А у пятой части респондентов — 21 % — просто не хватает ресурсов на допиливание. Когда компания небольшая, проще не подстраивать продукты под себя, а подстроить собственные процессы под продукт. И такое встречается чаще, чем можно подумать.
Крупные вендоры и открытый код: YES/NO?
В вопросе о том, определит ли открытый код в будущем, выживет ли условный Facebook или даже Microsoft, перевес в сторону опенсорса уже не так велик — лишь около 38 % посчитали, что на каком-то этапе своего развития большая часть важного и критичного софта будет именно с открытыми исходниками. И при этом почти 28 % полагают, что компании будут всё больше закрываться инфраструктурно даже при наличии открытых исходников. А чуть больше 20 % склоняются к тому, что если что-то и будет открываться, то незначительная часть, и то ради маркетинга. Ещё 13,26 % считают, что компании будут открывать исходные коды просто потому, что это не повлияет на их доход, так как они зарабатывают на доступе к сервисам. В результате какого-то преобладающего мнения нет: примерно 48 % считают, что так или иначе будут преобладать закрытые решения, а оставшиеся респонденты склоняются в сторону открытости ПО в крупных компаниях.
Сложно ответить однозначно, в каком направлении будут двигаться вендоры. Но, скорее всего, все эти векторы развития будут существовать параллельно, в зависимости от рода деятельности, размера и выбранной бизнес-модели компании-разработчика. Да и опрос показывает, что доминирующее мнение о необходимости открытия исходников на деле не так уж сильно отрывается от остальных, чтобы говорить от том, что именно по этому сценарию пойдёт развитие крупных корпораций.
А вдруг украдут?
Тут мы посмотрим глазами разработчиков на дилемму: открывать код или не стоит. Оптимистов, которые верят в то, что в мире открытого кода не принято воровать, немного — всего 6,81 %. Интересно, что противоположных им по мнению сторонников «всё спрятать, а то любой желающий украдёт» гораздо больше — почти 25 %.
Остальные участники опроса не бросаются в крайности и оценивают риски взвешенно. 37 % разделяют мнение создателей Osnova, что для достаточно крупного продукта риск создания форка, который бы мог вытеснить родительский продукт, крайне невысоки, ведь для этого нужно знать систему не хуже разработчика. Ещё чуть больше 31 % респондентов тоже не боятся открытого кода, но в защите своих ноу-хау полагаются на патенты и закон.
Попробуем разобраться. Допустим, мы не очень большая компания и наше решение приглянулось крупному игроку. Последнему, чтобы взять наше решение и развивать его как собственный продукт, понадобится задействовать ресурсы, которые будут на порядок превосходить наши ресурсы. Ему ещё нужно разобраться в системе, проанализировать узкие места и в короткие сроки «догнать» разработчика, иначе конкурировать с нами он не сможет. Опять же, есть юридические и репутационные риски. Крупной корпорации проще купить в этом случае разработчика, возможно даже предоставив ему большую степень свободы в своих действиях в отношении развития продукта. Это неплохой сценарий, взаимовыгодный. Что касается патентов, то заморачиваться с ними стоит, только если решение настолько прорывное, что переворачивает всё с ног на голову, иначе может оказаться так, что овчинка не стоит выделки.
Но есть также и другой сценарий развития событий. Когда продукт предоставляет некоторый сервис, существует риск того, что кто-то просто будет периодически забирать исходники и начнёт предоставлять точно такой же сервис. Такие прецеденты уже встречались, взять хотя бы Sentry, популярную систему мониторинга и логирования приложений. Она в своё время провела ряд изменений в политике лицензирования, когда столкнулась с тем, что некоторые недобросовестные компании занимались откровенным плагиатом как исходного кода, так и маркетинговых материалов, чтобы напрямую конкурировать с компанией. Тем не менее Sentry сохранила свою открытую модель разработки, используя исключительно юридические рычаги воздействия на недобросовестных конкурентов.
Роман Шеховцов, корпоративный архитектор Центра развития финансовых технологий РСХБ, в диалоге со спикером «Основы» высказал интересную мысль:
“
Я за конкуренцию. Я считаю, что это очень полезно, и в первую очередь для основного разработчика. Во-первых, там (с форком другой компании) может быть своя история, и они пойдут в другом направлении, перестав быть конкурентами. Но скорее всего, как Сергей (спикер Osnova) рассказывал, придут с форком к основному разработчику. Потому что никто не знает продукт лучше его изначального разработчика. Ну, а конкуренция — она подстёгивает, заставляет делать продукт лучше, неинтересно же пилить продукт, когда сравнить не с кем
За «бесплатное» можно и доплатить
Вновь категоричных сторонников опенсорса большинство — 48,75 % опрошенных готовы платить за коммерческие версии, поддержку и всячески стимулировать развитие открытого продукта. Это коррелирует с количеством респондентов, которые хотят и могут дорабатывать исходный код. Выглядит логично, так как иногда такой подход позволяет перенаправить собственные ресурсы на решение более специфичных для компании задач на выбранном стеке, воспользовавшись поддержкой разработчика, который знает свой продукт намного лучше. А значит, коммерческая версия порой может оказаться дешевле собственной разработки.
Четверть опрошенных хабровчан (25,63 %) платить тоже готовы, но только за техническую поддержку и доработку. Тут отсутствует собственная активная разработка, поэтому энтерпрайз-версии выглядят такими же проприетарными решениями, как и полностью закрытый код.
19,35 % готовы использовать открытый исходный код в рамках лицензий, но не готовы платить ни в каком виде разработчику.
А 6,27 % опрошенных просто готовы творить с кодом что угодно. Скорее всего, это всё те же респонденты, которые ранее были за закрытый код — не очень знакомые с опенсорсом на практике, они не понимают, что им может помешать. «Вот код, и я могу его взять и буду делать с ним всё, что захочу, кто ж меня остановит?» А ведь в финтехе (внезапно!) есть чуть больше институтов, регулирующих эти вопросы. За неправомерное использование программного обеспечения банк может не только крупный штраф схлопотать, но и, если скандал выйдет на международный уровень, доиграться до отзыва лицензии.
Пациент скорее выживет, чем нет
Сложная техническая система живуча, если способна выполнять свои функции после повреждения или разрушения её отдельных элементов. В нашем следующем вопросе мы интересовались: а что будет с Open-Source-системой после отказа одного из самых главных её компонентов — основного разработчика — от дальнейшей разработки этой системы?
21,51 % считают, что открытость может кода спасти продукт от гибели. Ещё 37,81 % считают, что не всегда: если какие-то компоненты завязаны на внутренние решения компании (сервера, закрытые микросервисы и т. п.), то без них получится «машина без колёс». Казалось бы, всё на месте, но не едет — и вам придётся переписывать ключевые компоненты самостоятельно. Но, по правде говоря, такое решение сложно назвать полностью открытым.
33,69 % ответивших склоняются к мнению, что открытый код в мире финтеха ещё не означает, что всё будет работать. Вам придётся заново и самостоятельно поднимать инфраструктуру вокруг решения, договариваясь с платёжными системами, банками, самостоятельно проходить все регуляторные процедуры и сертификацию. Реалии таковы, что финтех обязан иметь собственную инфраструктуру и минимально зависеть от внешних поставщиков, а программное обеспечение зачастую нуждается в доработке. То есть, это возможно независимо от того, есть ли у продукта разработчик или нет, иногда компания или группа компаний, использующих исходный код, подхватывают падающее знамя разработки просто потому, что они очень сильно завязаны на продукт. Это и произошло с Riak, как уже упоминал Сергей из Оsnova.
6,99 % опрошенных согласны с тем, что код зависит от конкретных личностей. Уже в который раз мы видим эту цифру, близкую к 6,81 %, и это наводит на определённые мысли о связи со сторонниками коробок. Что ж, здесь они высказывают не лишённое оснований мнение: бывает, что проект просто затухает без ведущих разработчиков, так как ни у кого больше нет достаточной экспертизы и мотивации для его развития.
Но есть ещё одна серьёзная опасность, особенно когда за проектом стоит небольшая группа людей или вообще один разработчик. Дело в том, что открытый исходный код очень просто… закрыть! Нажал владелец кнопку, ввёл подтверждение — и нет больше репозитория! Мы как-то привыкли, что открытый исходный код существует как данность и никуда не девается. Можно тут вспомнить случай из опыта нашего эксперта, который зашёл на страницу репозитория Actix Web, использовавшегося в его проекте, и был очень удивлён, получив 404-й ответ. Сначала удивлён, а потом шокирован, когда понял, что у него не сохранилось последней версии репозитория с влитыми багфиксами. Никому даже в голову не пришло, что открытый код может просто исчезнуть! К счастью, разработчик в итоге передал исходники в комьюнити, и разработка продолжилась.
Или вот взять CentOS в её классическом исполнении. За ней стоит огромная компания: Red Hat по праву считается одним из крупнейших поставщиков корпоративных решений для серверов и десктопов. Это коммерческий Linux, занимающий до 95 % мощностей инфраструктуры некоторых компаний. CentOS как открытая версия Red Hat Enterprise для многих компаний была основой инфраструктуры и ступенькой, по которой заходила коммерческая версия. И тут Red Hat говорят: мы CentOS как проект с фиксированными версиями сворачиваем, поддержку через год прекращаем, вот вам роллинг-релизы. Но в финтехе важна стабильность, поэтому немногие готовы вскочить на роллинг-релиз, нет уверенности, что подобные релизы будут тестироваться должным образом. А взять и переехать на первый попавшийся дистрибутив не так просто: есть собственная специфика. Что делать? Возможно, стоит поискать форк. Их сейчас три, самым перспективным для финтеха выглядит пока оракловский. Тоже крупная компания, авось не бросят.
Vendor lock-in всё ещё возможен
Что ж, проблема vendor lock-in, похоже, и впрямь беспокоит пользователей и разработчиков. Так что ещё один вопрос был целиком посвящён тому, станет ли вообще открытый исходный код спасением от неё.
Почти четверть респондентов (24,19 %) уверены, что открытый код не гарантирует защиту от vendor lock-in, что всегда можно заблокировать инфраструктуру вокруг него. Ряды скептиков дополняют и следующие 16,49 %, которые считают, что вендор может ограничить использование кода в новых версиях не физически, а лицензионно. Вы сможете продолжать использовать старые версии, но не получите доступ к новым возможностям и API, и ваш код превратится в тыкву. Оба этих ответа в сумме близки к 37,81 % ответов предыдущего вопроса, и мы можем предположить, что блокирования инфраструктуры или изменения лицензий проектов опасаются очень многие. Возможно, эти страхи и мешают им уверенно использовать продукты с открытым исходным кодом.
36,74 % верят в открытый код больше и полагают, что открытость исходного кода может всё же помочь, хоть и частично, — она позволит или выиграть время на замену компонентов, или перейти на другое решение. А оптимистов в этот раз не так много, менее четверти — лишь 22,58 % уверены, что открытый код свободен от vendor lock-in и он не только даёт выгоду, но также ограждает пользователей от действий производителя. Однако мы тут вместо долгих рассуждений просто напомним про Riak, Actix Web и CentOS (см. выше), да и вы можете продолжить список в комментариях. Так что тут всё индивидуально — какой-то код позволяет избежать vendor lock-in, какой-то не очень.
И профи открыты открытому коду
Раз уж взялись про стереотипы мнений в отношении открытого кода, то нельзя было не спросить хабровчан, правда ли они считают, что открытое ПО — удел любителей. И вновь противников опенсорса с мнением, что в открытый код котрибьютит кто попало, оказалось меньше всех. Знаете сколько? Ну вы поняли — 6,81 %!
9,32 % полагают, что крупные игроки рынка софта относятся с осторожностью к открытому коду потому, что сами пользователи, увидев код, возмутятся: «Что это за ужас вы нам продаёте?».
44,98 % респондентов вновь оптимистичны и считают, что открытый исходный код — это лицо компании, так что поддерживать его будут на высоком уровне, чтоб не стыдно показать было. И ещё немалая доля хабровчан — 39,89 % — полагают, что открытость не равна анархии, потому что открыты только исходники, а сама разработка ничем не отличается от проприетарной.
С некоторыми мнениями и мы бы согласились, потому что код проприетарного продукта порой действительно может вселять ужас — впрочем, и среди опенсорса такое иногда случается. Но часто бывает, что опенсорс — это побочный продукт коммерческой деятельности, направленный на обкатку решений силами комьюнити, и там будут те же правила, код-ревью, тестирование и контроль качества на всех этапах. Да и само комьюнити многое делает: всем же нужен качественный код, и в итоге все в выигрыше. А уже имея качественный код на руках — держим марку и продвигаем бренд. Так что, когда мы говорим о достаточно большом и популярном продукте, вряд ли можно назвать его разработчиков и пользователей любителями. Скажем больше: когда нас начинающие разработчики спрашивают, где посмотреть примеры хорошего исходного кода, мы удивляемся: «Да вон же опенсорс-проекты лежат, по вашим темам, написанные профессионалами, смотрите на здоровье!».
За ваши деньги — что угодно
Мы уже выяснили, что за доработку открытого кода хабровчане платить в целом готовы, а как насчёт техподдержки?
Категоричные «нет» — пусть и по разным причинам — выразили очень малые доли опрошенных (3,76 % считают, что к коду имеют доступ слишком много людей и полного контроля тут быть не может, а ещё 4,12 % лучше за эти деньги свою поддержку организуют). Опять в сумме около 7 %… ну ладно, чуть больше, но картина всё равно знакомая. Совпадение? Не думаем.
16,85 % респондентов тоже озабочены контролем — полагают, что платная поддержка возможна, но при условии полного контроля разработки. И 19,18 % выбрали ответ: «Да, но чтобы она не мешала заработку экспертов из сообщества или сторонних компаний, специализирующихся на техподдержке». Например, это может выглядеть так: основное ядро процессинга поддерживает разработчик, а адаптеры — дополнительные микросервисы, умеющие работать с этим ядром, — их создатели. Но мы ведь в реальном мире живём, как же здоровая конкуренция?
Зато большинство в этом пункте опроса абсолютное — 56,09 % за идею платной техподдержки, потому что, хоть технически грамотный клиент и сам может развернуть крупное решение, подобное Osnova, в финансовой сфере лучше всё-таки оставить вопрос техподдержки в руках авторов кода. Этот результат должен порадовать коллег из Osnova, хотя мы бы поспорили с тем, что в финтехе не принято городить свои платёжные системы на коленке. Ещё как разворачивают и даже собственные форки запиливают. Порой приходят в ту же Osnova с вопросами, предложениями и готовыми кейсами. Ну и иногда за техподдержкой — тоже взаимовыгодно.
Какие критерии важны, какие критерии нужны
Ну что ж, если большинство всё-таки за открытый код в финтехе, то по каким критериям хабровчане выбирали бы платёжную систему на основе открытого кода? Вот мы их об этом и спросили.
Просто посмотрим на распределение результатов:
Документированность даже чуть-чуть обгоняет безопасность, а вместе они занимают почти половину ответов. Дальше идёт открытость кода, возможность доработки под себя и масштабируемость. Вместе с ответами про документацию эти три вопроса набирают примерно такое же количество процентов, как и предыдущие вопросы про доработку продукта. Это ожидаемо и похоже на правду. Замыкают рейтинг репутация компании и недорогая стабильная поддержка.
Почему документация так вырвалась вперёд? Потому что встречаются плохо документированные продукты, интеграция которых превращается в боль, потерянные часы и дни в попытках понять, как же это всё заставить работать. С хорошей документацией можно спрогнозировать темпы работ и избежать многих неприятностей, а с плохой — запросто сорвать дедлайны и понести убытки. А чтобы не понести убытки, важна также и безопасность, может, поэтому они вместе лидируют с почти равными голосами?
Made in Russia?
Что ещё может влиять на выбор финтех-продукта? Мы решили выяснить, важна ли для хабровчан страна происхождения открытого кода.
Приятно видеть, что космополитов, не обращающих внимания на гражданство кода, больше половины. А вот 23,30 %, хоть и поддерживают международное взаимодействие, хотели бы видеть основной состав команды из России — потому что ему будет лучше знакома специфика страны. 13,80 % за решения только от российских разработчиков. 9,32 %, напротив, опасаются, что российские продукты могут не одобрить за рубежом просто потому, что они как раз из России.
Платёжная система на опенсорсе — зверь редкий
И это факт. А вот почему так получается — мы спросили пользователей Хабра.
Очень мало людей считает, что это не интересно (8,78 %). В основном обращают внимание на сложность (32,62 %), исторические причины (24,55 %), организационные (21,51 %) и финансовые (12,54 %). Сложность у таких продуктов действительно высокая, соответственно высоки и затраты, а с ними риски, да и конкурировать приходится. Из этого можно сделать вывод, что выйти на рынок с таким решением непросто.
Есть ли будущее у Open Source в финтехе?
Про сторонников проприетарности и закрытого кода в этом вопросе можно сказать кратко: 6,99 %. Мы уже привыкли. Но стабильность радует — люди тверды в своей позиции.
Удивительно, но оптимисты, которые за полную открытость и энтузиазм, на этот раз сдали позиции и заняли лишь второе место, набрав 38,89 % голосов. Большинство же респондентов считают, что опенсорс — это, конечно, круто и интересно, но рынок финтеха пока к нему не готов, вот, может, не в ближайшее время, а когда-нибудь потом…
Что ж, на этом вопросы закончились. Но завершить наш анализ мы бы хотели цитатой эксперта, которая лучше всего подведёт черту под размышлениями об опенсорсе в финтехе:
Когда мы смотрим на какой-то продукт, мы в первую очередь смотрим ведь не на то, открыт код или закрыт. Мы смотрим на то, насколько эффективно он помогает решить наши проблемы и насколько хорошо выполняет наши задачи. Если мы говорим о каких-то областях применения, то найти хорошее, качественное Open-Source-решение можно и не смочь, его просто нет. Но открытость при прочих равных — приятный плюс. Мы же не всё разрабатываем сами, стараемся также использовать Open-Source-решения. Можно посмотреть продукт, понять, насколько он хорошо может удовлетворить потребности конечного пользователя, разобраться, как он работает, заглянув в исходники. Мы понимаем, что сам по себе продукт никому не интересен на рынке; интересно, насколько хорошо, эффективно и недорого он позволяет решать проблемы наших клиентов.
Сергей Елин
тимлид ERLANG-разработчиков Osnova
Надеемся, и опрос, и наш анализ были вам интересны. Если у вас появились какие-то свои мысли и гипотезы, почему ответы склонялись в ту или иную сторону, а также если у вас был и/или есть свой опыт в части опенсорса в финтехе — поделитесь в комментариях, будет здорово.