#5: Выбор тактики, уточнение деталей (ч. 2)
<<НАЗАД | К ОГЛАВЛЕНИЮ | ВПЕРЁД>>
Должно ли государство финансировать разработку СПО?
До недавнего времени Россия обходилась без СПО, а СПО развивалось без финансовой поддержки со стороны России. Быть спонсором в чистом виде для каких-либо проектов без обратной отдачи в явном виде, государству не имеет смысла. Сегодня главными донорами наиболее крупных проектов являются известные зарубежные компании со всего мира, так что зависимости от единственного поставщика решений в данном случае нет, как и повода волноваться об информационной безопасности.
Нет смысла вкладывать деньги в проекты, если исполнители являются аутсорсерами. Также нет смысла централизованно оплачивать разработку ПО, распространение которого очень ограничено. Другое дело, есть смысл взять под контроль государства несколько наиболее критичных проектов по развитию массового прикладного ПО стратегического значения (браузер, почтовый клиент, офисный пакет и т.п.). Но апстрим у этих продуктов уже давно имеется, и он явно не в России.
Поэтому здесь необходимо стремиться к максимальному стимулированию Российских разработчиков, чтобы они подключались к соответствующим проектам и одновременно задабривать финансовыми вливаниями апстрим, чтобы к нашим разработчикам относились лояльно и чтобы максимально поддерживать эти проекты на должном уровне.
Независимо от того, где разработан дистрибутив СПО, процент кода непосредственного разработчика дистрибутива приближается к нулю. Как правило ЛЮБОЙ разработчик дистрибутива GNU/Linux - это конструктор собственных костылей (велосипедов), ко всему прочему старающийся угнаться за развитием СПО. Поэтому говорить о необходимости вливания бюджетных денег в разработку дистрибутива для государственных нужд лично я рассматриваю как попытку ввести в заблуждение руководство нашей страны.
К бюджетному финансированию таких проектов, как ядро Linux, стоит относиться весьма взвешенно. У конкретно данного проекта уже есть и очень солидные спонсоры, и несколько тысяч наиболее квалифицированных разработчиков. В таком проекте нас пока врядли будут воспринимать серьёзно. Но если Россия будет заниматься разработкой собственного железа, в частности процессоров, с апстримом Linux придётся считаться и договариваться.
Намного проще взять под свой контроль апстрим ядра GNU/Hurd. Это свободная ниша и одновременно перспективное для России направление, которое не исключает возможность заимствования части кода из ядра Linux.
Нужны ли госконтракты на централизованные закупки/внедрение СПО?
На мой взгляд, это тупиковый путь. Государству нужен один исполнитель, который будет за всё отвечать. Но СПО не принадлежит какой-либо одной Российской организации, у нас нет того, кто будет отвечать за каждую строчку кода. Развитие СПО децентрализованно, в противопоставление тому, что требуется 94-ФЗ, поэтому найти силы, способные объединиться для работы в одном общем направлении весьма проблематично. Мне кажется, что именно это и показал предыдущий Российский опыт централизованного внедрения СПО.
Несовместимость концепций или как скрестить ужа и ежа?
Существующая модель разработки и распространения СПО абсолютно несовместима с 94-ФЗ. Едва ли СПО будет подстраиваться под Российское законодательство, равно как и вряд ли Россия переделает 94-ФЗ специально для повсеместного внедрения СПО. Ужа и ежа скрестить невозможно, обозначенная проблема не решаема. Но, мне кажется, такой задачи и не нужно ставить перед собой.
Почему? Во-первых, государство - это не заказчик. Заказчиком могут выступать конкретные ведомства, в некоторых случаях привлекая средства из федерального бюджета. Во-вторых, именно заказчикам необходимо адаптироваться под существующую модель развития и распространения СПО, т.к. другой путь - это смотреть не в сторону использования СПО, а двигаться в каком-то другом направлении.
Имеются ли основания финансировать СПО за счёт средств федерального бюджета?
И внедрение, и разработка ПО для нужд не регионального, а федерального применения, действительно могут оплачиваться из средств федерального бюджета. Но здесь не идёт речи о дистрибутивах СПО. Только прикладное ПО специализированного назначения, например, клиент пенсионного учёта для предоставления в налоговую инспекцию. Для федеральной пенсионной системы ГВЦ Москвы разрабатывал систему централизованного сбора данных по пенсионным отчислениям ни один год, причём основана она была санах и солярке, а вот клиенты под эту систему были сделаны почему-то только под MS-DOS.
Однако централизованное финансирование и централизованное внедрение - это два разных понятия. Централизованно финансировать разработку и внедрение можно, но непосредственным внедрением, мне кажется, должны заниматься сами ведомства, на местах определяясь, кто будет внедрять и поддерживать ПО.
Какие разработки в ИТ являются наиболее приоритетными для государства?
Для достижения поставленных целей необходимо постепенно начинать двигаться одновременно в нескольких направлениях:
Должно ли государство финансировать разработку СПО?
До недавнего времени Россия обходилась без СПО, а СПО развивалось без финансовой поддержки со стороны России. Быть спонсором в чистом виде для каких-либо проектов без обратной отдачи в явном виде, государству не имеет смысла. Сегодня главными донорами наиболее крупных проектов являются известные зарубежные компании со всего мира, так что зависимости от единственного поставщика решений в данном случае нет, как и повода волноваться об информационной безопасности.
Нет смысла вкладывать деньги в проекты, если исполнители являются аутсорсерами. Также нет смысла централизованно оплачивать разработку ПО, распространение которого очень ограничено. Другое дело, есть смысл взять под контроль государства несколько наиболее критичных проектов по развитию массового прикладного ПО стратегического значения (браузер, почтовый клиент, офисный пакет и т.п.). Но апстрим у этих продуктов уже давно имеется, и он явно не в России.
Поэтому здесь необходимо стремиться к максимальному стимулированию Российских разработчиков, чтобы они подключались к соответствующим проектам и одновременно задабривать финансовыми вливаниями апстрим, чтобы к нашим разработчикам относились лояльно и чтобы максимально поддерживать эти проекты на должном уровне.
Независимо от того, где разработан дистрибутив СПО, процент кода непосредственного разработчика дистрибутива приближается к нулю. Как правило ЛЮБОЙ разработчик дистрибутива GNU/Linux - это конструктор собственных костылей (велосипедов), ко всему прочему старающийся угнаться за развитием СПО. Поэтому говорить о необходимости вливания бюджетных денег в разработку дистрибутива для государственных нужд лично я рассматриваю как попытку ввести в заблуждение руководство нашей страны.
К бюджетному финансированию таких проектов, как ядро Linux, стоит относиться весьма взвешенно. У конкретно данного проекта уже есть и очень солидные спонсоры, и несколько тысяч наиболее квалифицированных разработчиков. В таком проекте нас пока врядли будут воспринимать серьёзно. Но если Россия будет заниматься разработкой собственного железа, в частности процессоров, с апстримом Linux придётся считаться и договариваться.
Намного проще взять под свой контроль апстрим ядра GNU/Hurd. Это свободная ниша и одновременно перспективное для России направление, которое не исключает возможность заимствования части кода из ядра Linux.
Нужны ли госконтракты на централизованные закупки/внедрение СПО?
На мой взгляд, это тупиковый путь. Государству нужен один исполнитель, который будет за всё отвечать. Но СПО не принадлежит какой-либо одной Российской организации, у нас нет того, кто будет отвечать за каждую строчку кода. Развитие СПО децентрализованно, в противопоставление тому, что требуется 94-ФЗ, поэтому найти силы, способные объединиться для работы в одном общем направлении весьма проблематично. Мне кажется, что именно это и показал предыдущий Российский опыт централизованного внедрения СПО.
Несовместимость концепций или как скрестить ужа и ежа?
Существующая модель разработки и распространения СПО абсолютно несовместима с 94-ФЗ. Едва ли СПО будет подстраиваться под Российское законодательство, равно как и вряд ли Россия переделает 94-ФЗ специально для повсеместного внедрения СПО. Ужа и ежа скрестить невозможно, обозначенная проблема не решаема. Но, мне кажется, такой задачи и не нужно ставить перед собой.
Почему? Во-первых, государство - это не заказчик. Заказчиком могут выступать конкретные ведомства, в некоторых случаях привлекая средства из федерального бюджета. Во-вторых, именно заказчикам необходимо адаптироваться под существующую модель развития и распространения СПО, т.к. другой путь - это смотреть не в сторону использования СПО, а двигаться в каком-то другом направлении.
Имеются ли основания финансировать СПО за счёт средств федерального бюджета?
И внедрение, и разработка ПО для нужд не регионального, а федерального применения, действительно могут оплачиваться из средств федерального бюджета. Но здесь не идёт речи о дистрибутивах СПО. Только прикладное ПО специализированного назначения, например, клиент пенсионного учёта для предоставления в налоговую инспекцию. Для федеральной пенсионной системы ГВЦ Москвы разрабатывал систему централизованного сбора данных по пенсионным отчислениям ни один год, причём основана она была санах и солярке, а вот клиенты под эту систему были сделаны почему-то только под MS-DOS.
Однако централизованное финансирование и централизованное внедрение - это два разных понятия. Централизованно финансировать разработку и внедрение можно, но непосредственным внедрением, мне кажется, должны заниматься сами ведомства, на местах определяясь, кто будет внедрять и поддерживать ПО.
Какие разработки в ИТ являются наиболее приоритетными для государства?
Для достижения поставленных целей необходимо постепенно начинать двигаться одновременно в нескольких направлениях:
Развитие электронной промышленности, в первую очередь процессоры, GPU и сетевое оборудование;
Поддержка Национальной Программной Платформы (среда исполнения, возможно компиляторы и другие средства разработки);
Поддержка самых востребованных прикладных программ для максимального числа существующих платформ (браузер, почтовый клиент, офисный пакет и т.п.);
Отказ от повсеместного использования проприетарных решений, отказ от решений единственного поставщика, стремление к максимальной диверсификации платформ;
Приведение законодательства и методических рекомендаций в соответствие с обозначенными стратегическими целями.