Комментарии 11
В вопросе импортзамещения важно не забывать, что переход на open source с точки зрения регулятора импортозамещением вовсе не является.
Однако крупному бизнесу утвердили формы отчетности по импортозамесу с доп. колонкой про OSS, что уже неплохо. Они там весело ставят плюсики на AirFlow, LibreOffice и Ubuntu... А вот бюджетникам нужен именно импортозамес. Также он нужен частникам - "критичникам", с объектами КИС. Но там почти всё импортозамещать еще нечем. Вообще премьерство тов. Мишустина М.В. благотворно сказывается на росте понимания исп. властью роли СПО и неизбежности не-100% импортозамеса. СПО д.б. быть уравнено в правах с импортозамесом.
А ещё стоит учитывать что оос может чудесным образом стать closed source ну буквально вот совсем скоро
Сильно зависит от владельца СПО, например 2 из 3 в данной статье это проекты ASF (Apache Software Foundation) и вероятность, что эти проекты станут closed source очень низкая.
А сердцем системы является софт у кторого де факто (именно де факто, а не по фантазиям локальных сборщиков) один контрибьютер который дает 99% кода, который в очередной раз перепродан и сильно сократил штат.
Я лично как PMC (Project Management Committee) Apache Airflow не знаю кто тот самый контрибьютор, что дает 99% кода? Свою лепту вносят на регулярной основе довольно много крупных компаний и сторонних контрибьюторов, это если брать конкретный проект внутри ASF.
Шанс, что в один момент времени тот или иной проект ASF проект станет мало интересным для пользователей/контрибьюторов/PMC всегда есть, в таком случае проект закончит свое существование в Apache Attic - это обычный жизненный цикл.
Я далее продолжу примеры конкретного Apache Airflow, так как все же считаю себя достаточно компетентным в вопросах кто и как его использует и кто вносит свою лепту. "Локальный сборщик" в данном случае это не только импортозаместитель, но и такие компании как Amazon, Google, Microsoft, Huawei, Yandex, Astronomer и прочие кто предоставляют свой Managed service вокруг Airflow. Эти компании должны быть напрямую заинтересованы в развитии проекта (уточнение это их право, но не обязанность), а так же упрощение самой "перепаковки" под свои нужды, чтобы не приходилось мучительно больно каждый раз патчить новую версию.
И тут вариантов несколько - это забить и плыть по течению или вносить свою лепту в проект, упрощая жизнь себе и прочим пользователям/компаниям. Хороший пример это AWS, который сначала внедрил у себя MWAA, помучался с ним и выделил целую команду кто занимается внесение изменений (это может быть даже и не fulltime, этой информации у меня нет). И как результат, за последние год-полтора довольно много фундаментальных изменений было внесено именно этой командой, естественно их цель и мотивация понятна - сделать жизнь легче их работодателю, чтобы он мог получить конкурентное преимущество перед остальными игроками рынка, так как ему придется меньше плясать с патчами вокруг ванильной версии, но остальные также могут пользоваться этими наработками. Есть и плохие примеры, когда тот или иной игрок не участвует в жизни проекта, печально но ладно.
Наверное каждый "перепаковщик" должен как минимум интересоваться как там дела у конкретного проекта, какая там активность, а то может оказаться что проект живой, а на деле нет (косо смотрю на Apache OpenOffice).
Если отойти немного от конкретного проекта конкретного некоммерческого фонда и задаться вопросом: "может ли тот или иной СПО софт стать закрытым или перейти на 'своеобразные' лицензии?", то ответ будет да и примеров много, за последнее время. Другое дело если этот какой либо фонд (не обязательно ASF), у которого основная цель выпускать СПО, тут скорее вопрос в другом, когда конкретный проект потеряет основную массу пользователей или наоборот приобретет, в момент когда другой СПО перестанет (пусть даже формально) быть таковым.
А какая альтернатива была GP при выборе? И был ли выбор? Пишите о преимуществах как будто прям по десяткам критериев что-то смотрели и выбирали.
GP - технологический труп с кучей недостатков (одним из главных является низкая производительность которую заливают железом) и дорогой в эксплуатации
Альтернатив по факту и не было, на рынке РФ и для On-prem решений в части задач классической регламентной отчетности - альтернатив почти нет. Есть что-то близкое, появляющееся на рынке и не совсем зрелое, но тот факт, что де-факто GP и его сборки сейчас используются в большинстве крупных и средних проектов импортозамещения или внедрения хранилищ в госсекторе и не только - говорит о развитии этой СУБД. Но недостатки есть, как и у любой другой СУБД, с этим никто не спорит.
Так все ставят потому что альтернатив нет или потому что все ставят? Что первично?
Что вы вкладываете в термин развитие? Я вот с GP знаком с 2013г примерно, плотно работаю с 2016 года с 4й версии и с этого времени наблюдаю чудовищную стагнацию технологическую. GP так ничего не не предложил за это время.
Greenplum, NiFi и Airflow на страже импортозамещения: но есть нюансы