Tansu писал(а):
Скажите, а Вы кто, который несёт "ответственность за ГИС проекты" и предлагает их вывести на уровень национального масштаба?
А если в один момент Вы уйдёте из проекта и что, всё остановится?
Пока гарантом выступаете Вы лично. А как предложенные Вами "несколько тысяч пользователей из системы Минздрава и Санэпидемнадзора" будут требовать улучшения качества своих систем, от кого вернее? К какой марке они будут предъявлять свои претензии или они будут обращаться лично к Вам? Или же гарантом выступает фирма, в которой Вы работаете? Она имеет полномочия определять стандарты в технологических системах? Можете не отвечать на вопросы - они риторические...
Несмотря на то, что вопросы "риторические", я на них постараюсь ответить.
Во-первых не надо путать заявку, поданную на конкурс и мою работу в проекте с "несколькими тысячами пользователей". Описание нынешнего моего проекта было приведено в контексте ответа на вопрос Максима Дубинина. Конкретно в этом проекте я являюсь руководителем ГИС подразделения и отвечаю за работу и отказоустойчивость разрабатываемых нами ГИС средств перед руководством компании. Средств, разрабатываемых на базе опенсорса. Гарантом для конечного пользователя выступает компания. А сама работа со странами ведется в рамках международной программы по контролю за распространением особо опасных заболеваний. И составлен контракт в соответствии с международными стандартами, в том числе в софтверной области.
Гарантом, в конечном итоге, всегда выступает именно компания в рамках ответственности, предусмотренной контрактом. Не стандарты, а контракт, составленный в соответствии с ними.
И доверие или недоверие заказчика вызывает именно компания-исполнитель и ее устойчивость. Microsoft, ESRI и т.п., их финансовая состоятельность и репутация, обусловленная внедрениями и опытом работы вызывает доверие или недоверие заказчика когда он думает о гарантиях.
И чем больше организаций (как заказчиков, так и поставщиков услуг) будет вовлечено в адекватное (!) использование открытого ПО тем лучше. Если проект, даже крупный и государственный может быть реализован на опенсорсе, то почему бы этого не сделать?
Tansu писал(а):
Знаете что меня поразило в России? Не отсутствие технологий или специалистов, а не принятие подходов международного стандарта в работе. В России нет стремления к стандарту - во всём: абы как бы лишь бы работало.
Простой пример.Имеется в муниципалитете нехилый пучок ПО, и очень хороший базовый фон, и вот специалист, который на все ручки мастер, в полном смысле этого слова, пытается всё это привести с помощью открытого ПО к какой-то системе. А муниципалитет сидит и дрожит, как бы этот спец не покинул их, так как все что они сделали, полетит к праху. Сколько еще будут экспериментировать умелые ручки очередной светлой головы и мучить систему в муниципалитете например? Это хорошая экономия? А как же гарантия качества, сохранности данных и т.д.и т.п
А как же конечные пользователи? Им не понять, что там экономия бюджета или эксперименты...Им хочется результата - хорошего.
Экономия бюджета это тоже не на последнем месте. Просто все должно быть соразмерно и адекватно. Гарантий, что на проприетарном софте вы получите "хороший результат" вам тоже никто не даст. И тем не менее авторитет компании выступает в роли такого гаранта. Взять хотя бы Microsoft. В одном из достаточно крупных проектов у нас использовался MS Biztalk. Его использование было согласовано со всеми, включая местное представительство Microsoft. И но был прописан в эскизном проекте. На деле, обнаружился баг, которые не смогли устранить ни наши специалисты, ни срочно присланные представители Microsoft. Проблему признали, но сделать было ничего нельзя. И никто в MS от этого харакири не сделал и пользоваться их продуктами меньше не стали. Обошлись другими средствами. Был бы опенсорс, баг устранить было бы реальнее. Если брать европейский опыт, то в Дании, например, открытое ПО имеет тендерное преимущество в процессе госзакупок.
А то что во многих конторах бывают незаменимые специалисты, да есть такая проблема. И это не проблема опенсорса и "умелых ручек", а проблема организации процесса разработки.