#6: Выбор тактики, уточнение деталей (ч. 3)
<<НАЗАД | К ОГЛАВЛЕНИЮ | ВПЕРЁД>>
Нужен ли единый госдистрибутив СПО?
Нет, не нужен. Государство не является заказчиком, заказчиками могут выступать конкретные государственные ведомства и у них могут быть совершенно разные потребности. Им всем необязательно ориентироваться на режим строгой секретности, свойственный военным и спецслужбам. И тем более, чем больше будет поставщиков решений и подходов, тем проще будет достичь оговоренных целей.
Нужен ли единый госрепозиторий СПО?
Да, такой репозиторий нужен, но не один. Таких репозиториев должно быть много, они могут располагаться в пределах России где угодно, иметь разную степень доступности для широких масс и разработчиков. Для достижения намеченных целей в первую очередь необходимо создать инфраструктуру совместной разработки ПО, а не только хранить ранее созданное. Но, как известно, у разработчиков могут существенно различаться подходы к необходимому инструментарию. Поэтому навязывать всем единую систему, заточенную исключительно под одну группу разработчиков, пусть даже самую сильную команду, в корне неверно. Почему, например, девятиклассник Петя не может создать хорошую программу для тестирования учеников? Он может, но чтобы заставить его освоить какую-то непривычную для него среду «единого госрепозитория» придётся ни один год обучать этого Петю, после чего не факт, что у него появится желание работать с этой средой коллективного творчества.
Каковы основные задачи государственного репозитория СПО? Во-первых, хранить разработанное на деньги государства, защищая свои инвестиции. Лучше хранить не в одном месте, значит репозиториев должно быть несколько. Во-вторых, обеспечить однообразный инструмент для коллектива разработчиков. Привлечь как можно больше именно Российских разработчиков СПО к наиболее насущным проектам. А для этого нужна диверсификация в предлагаемых площадках, каждая - со своим инструментарием и политикой приёмки кода и патчей. В третьих, обеспечить доступность СПО для других. Это обязанность государства в случае использования «copyleft»-ного СПО и это полностью согласуется с исходными целями: что сделано раз, могут использовать и другие, причём не только ведомства, но и простые граждане.
Почему сборка ПО для государственных нужд должна выполняться именно в России?
Единственное требование, которое действительно имеет значение, это воспроизводимость сборки заказанного государственной организацией конечного программного продукта, т.е. необходимы все исходники, сборочная среда и точная инструкция по сборке, дающая возможность воспроизвести сборку конечного продукта из исходных текстов. Поскольку и сам заказчик, и исполнитель находятся в России, а приёмка работ по госконтракту требует такого тестирования, вполне логично предположить, что воспроизвести сборку проще на территории заказчика. Главное требование заключается не в том, где выполняется проверка воспроизводимости сборки, а сам факт того, чтобы такое тестирование проводилось и было изначально оговорено в государственном контракте.
Чтобы быть уверенными, что предоставленная исполнителем сборочная среда не создаёт никаких сюрпризов в бинарном результате, совершенно необязательно, чтобы она была «эталонной», достаточно ограничиться методикой тройного бутстрапа: сначала из доступных исходников сборочной среды в бинарной сборочной среде создаётся полностью вся сборочная среда (бинарники), она создаёт из исходников вторую бинарную сборочную среду, а та, в свою очередь - третью. Затем результат работы первой и второй среды сравнивается: вторая и третья сборочные системы должны быть абсолютно эквивалентными.
Выполнение сборки заказанного программного продукта должно выполняться уже с использованием третьей созданной сборочной среды, все предыдущие результаты отбрасываются. Повторять тройной бутстрап сборочной среды для каждой заказанной программы, понятное дело, ни к чему, кроме того, заказчик вполне может договорится с исполнителем, чтобы сборка и тестирование проводились в уже ранее проверенной заказчиком сборочной системе, для чего она предоставляется исполнителю в виде бинарников, исходников и описания тройного бутстрапа. Но это требование не должно навязываться исполнителям во избежании ограничения конкуренции.
Ничего революционно нового, примерно так собирается GCC в любом дистрибутиве, схожим образом создаются стейджи Gentoo Linux. Вполне достойный способ избавиться от страшного понятия «эталон», в особенности страшного потому, что им назовут инструментальное средство единственного поставщика решений и плакали тогда мечты о диверсификации.
Почему не может быть исключений для «ПО стратегического значения»?
ОС на десктопе госчиновника - это не ядерный щит, а всего лишь инструмент для работы. В плане информационной безопасности и независимости государства, только лишь от ОС на десктопах - мало что зависит. Теоретически, централизованные закупки СПО оптом сразу для всех организаций могли бы оказаться выгодней, если бы одновременно было соблюдено сразу несколько условий:
Боюсь, что ни одно из перечисленных условий невыполнимо. Практика внедрения СПО в России уже это показала. Таким образом, нет никакого смысла приравнивать СПО к ядерному щиту. Необходима иная тактика.
Нужен ли единый госдистрибутив СПО?
Нет, не нужен. Государство не является заказчиком, заказчиками могут выступать конкретные государственные ведомства и у них могут быть совершенно разные потребности. Им всем необязательно ориентироваться на режим строгой секретности, свойственный военным и спецслужбам. И тем более, чем больше будет поставщиков решений и подходов, тем проще будет достичь оговоренных целей.
Нужен ли единый госрепозиторий СПО?
Да, такой репозиторий нужен, но не один. Таких репозиториев должно быть много, они могут располагаться в пределах России где угодно, иметь разную степень доступности для широких масс и разработчиков. Для достижения намеченных целей в первую очередь необходимо создать инфраструктуру совместной разработки ПО, а не только хранить ранее созданное. Но, как известно, у разработчиков могут существенно различаться подходы к необходимому инструментарию. Поэтому навязывать всем единую систему, заточенную исключительно под одну группу разработчиков, пусть даже самую сильную команду, в корне неверно. Почему, например, девятиклассник Петя не может создать хорошую программу для тестирования учеников? Он может, но чтобы заставить его освоить какую-то непривычную для него среду «единого госрепозитория» придётся ни один год обучать этого Петю, после чего не факт, что у него появится желание работать с этой средой коллективного творчества.
Каковы основные задачи государственного репозитория СПО? Во-первых, хранить разработанное на деньги государства, защищая свои инвестиции. Лучше хранить не в одном месте, значит репозиториев должно быть несколько. Во-вторых, обеспечить однообразный инструмент для коллектива разработчиков. Привлечь как можно больше именно Российских разработчиков СПО к наиболее насущным проектам. А для этого нужна диверсификация в предлагаемых площадках, каждая - со своим инструментарием и политикой приёмки кода и патчей. В третьих, обеспечить доступность СПО для других. Это обязанность государства в случае использования «copyleft»-ного СПО и это полностью согласуется с исходными целями: что сделано раз, могут использовать и другие, причём не только ведомства, но и простые граждане.
Почему сборка ПО для государственных нужд должна выполняться именно в России?
Единственное требование, которое действительно имеет значение, это воспроизводимость сборки заказанного государственной организацией конечного программного продукта, т.е. необходимы все исходники, сборочная среда и точная инструкция по сборке, дающая возможность воспроизвести сборку конечного продукта из исходных текстов. Поскольку и сам заказчик, и исполнитель находятся в России, а приёмка работ по госконтракту требует такого тестирования, вполне логично предположить, что воспроизвести сборку проще на территории заказчика. Главное требование заключается не в том, где выполняется проверка воспроизводимости сборки, а сам факт того, чтобы такое тестирование проводилось и было изначально оговорено в государственном контракте.
Чтобы быть уверенными, что предоставленная исполнителем сборочная среда не создаёт никаких сюрпризов в бинарном результате, совершенно необязательно, чтобы она была «эталонной», достаточно ограничиться методикой тройного бутстрапа: сначала из доступных исходников сборочной среды в бинарной сборочной среде создаётся полностью вся сборочная среда (бинарники), она создаёт из исходников вторую бинарную сборочную среду, а та, в свою очередь - третью. Затем результат работы первой и второй среды сравнивается: вторая и третья сборочные системы должны быть абсолютно эквивалентными.
Выполнение сборки заказанного программного продукта должно выполняться уже с использованием третьей созданной сборочной среды, все предыдущие результаты отбрасываются. Повторять тройной бутстрап сборочной среды для каждой заказанной программы, понятное дело, ни к чему, кроме того, заказчик вполне может договорится с исполнителем, чтобы сборка и тестирование проводились в уже ранее проверенной заказчиком сборочной системе, для чего она предоставляется исполнителю в виде бинарников, исходников и описания тройного бутстрапа. Но это требование не должно навязываться исполнителям во избежании ограничения конкуренции.
Ничего революционно нового, примерно так собирается GCC в любом дистрибутиве, схожим образом создаются стейджи Gentoo Linux. Вполне достойный способ избавиться от страшного понятия «эталон», в особенности страшного потому, что им назовут инструментальное средство единственного поставщика решений и плакали тогда мечты о диверсификации.
Почему не может быть исключений для «ПО стратегического значения»?
ОС на десктопе госчиновника - это не ядерный щит, а всего лишь инструмент для работы. В плане информационной безопасности и независимости государства, только лишь от ОС на десктопах - мало что зависит. Теоретически, централизованные закупки СПО оптом сразу для всех организаций могли бы оказаться выгодней, если бы одновременно было соблюдено сразу несколько условий:
Разработка СПО находится полностью под контролем государства;
Поставщик(и) СПО во всех смыслах крупнее Microsoft;
У всех госорганизаций потребности в ПО очень схожи;
Боюсь, что ни одно из перечисленных условий невыполнимо. Практика внедрения СПО в России уже это показала. Таким образом, нет никакого смысла приравнивать СПО к ядерному щиту. Необходима иная тактика.