Ещё один аргумент против "интеграции с мировым сообществом Open Source"
Добавлено: 03.09.20 11:58
В качестве такого аргумента я обычно приводил наличие закладок.
Второй аргумент - лучше выпускать продукт, чем предоставлять услуги на рынке труда.
Для организации выгоднее набрать дешёвых русскоязычных программистов и увеличить свою маржу. При этом
будет то ограничение, что и для поддержки потом придётся использовать только русскоязычных программистов. Но таковые
программисты и сейчас дешевле индусов и турок, в кроссовере работают русские, Восточная Европа типа румын, латинская
Америка и Индия. Т.е. да, дешёвые индийские программисты существуют, но их качество при этом за ту же цену ниже, чем у русских.
Таким образом, может оказаться, что есть смысл вести разработку на русском. Правда, тут возникнет проблема, что при продаже в иноязычном мире
потребуется перевод, но возможно, что делать каждый раз этот перевод будет дешевле, чем содержать англоязычных специалистов.
Для частного же лица или команды, предоставляющей услуги на рынке труда, выгоднее сделать Vendor Lock, чтобы нельзя было заменить данное частное лицо на англоговорящее. Language Lock является подмножеством Vendor Lock, поддержку продукта можно замкнуть на русскоязычных программистов и это выгодно всему сообществу русскоязычных программистов.
Правда, если заказчик адекватный и отслеживает процесс, это может не прокатить.
Это были старые аргументы. Новый аргумент состоит в том, что "интеграция с мировым сообществом" означает принятие как плюсов, так и минусов данной интеграции. Минусов много:
* хаотичность развития. Новые технологии приходят в моду из-за того, что кто-то вложил кучу денег в их раскрутку, а не потому, что они лучше старых. Пример - react
* низкая квалификация тех, кто принимает решения, по обе стороны моды. Законодатели мод могут сдуру раскрутить какой-нибудь node.js для серверных применений, а последователи просто тащат в проекте всё что ни попадя, главное, чтобы оно было в моде и сулило в будущем повышение доходов (хотя мода зачастую проходит и инвестиции в изучение новой модной технологии оказываются напрасными)
* наследие, ввиду чего в работе возникает масса затруднений и ограничений. Например, есть близкие по области применения и смыслу Руби, Питон, Перл и PHP - все они нужны. Аналогичная ситуация с Си, С++ и Растом (причём у С++ ещё и множество разных стандартов и конкурирующих библиотек, делающих одно и то же)
Сейчас технология находится в таком состоянии, что "стереть всё и переписать заново" выглядит достаточно разумной альтернативой, вопрос лишь в том, что это чертовски дорого. Однако у государства заведомо достаточно ресурсов для этого, кроме того оно, государство, всё равно занимается этим.
Всякие там Астра Линуксы, Мои Офисы, Эльбрусы и Касперски ОС являются частными случаями, но вместо того, чтобы взять и переделать сразу всё, переделывают по частям, в итоге все недостатки сохраняются.
Второй аргумент - лучше выпускать продукт, чем предоставлять услуги на рынке труда.
Для организации выгоднее набрать дешёвых русскоязычных программистов и увеличить свою маржу. При этом
будет то ограничение, что и для поддержки потом придётся использовать только русскоязычных программистов. Но таковые
программисты и сейчас дешевле индусов и турок, в кроссовере работают русские, Восточная Европа типа румын, латинская
Америка и Индия. Т.е. да, дешёвые индийские программисты существуют, но их качество при этом за ту же цену ниже, чем у русских.
Таким образом, может оказаться, что есть смысл вести разработку на русском. Правда, тут возникнет проблема, что при продаже в иноязычном мире
потребуется перевод, но возможно, что делать каждый раз этот перевод будет дешевле, чем содержать англоязычных специалистов.
Для частного же лица или команды, предоставляющей услуги на рынке труда, выгоднее сделать Vendor Lock, чтобы нельзя было заменить данное частное лицо на англоговорящее. Language Lock является подмножеством Vendor Lock, поддержку продукта можно замкнуть на русскоязычных программистов и это выгодно всему сообществу русскоязычных программистов.
Правда, если заказчик адекватный и отслеживает процесс, это может не прокатить.
Это были старые аргументы. Новый аргумент состоит в том, что "интеграция с мировым сообществом" означает принятие как плюсов, так и минусов данной интеграции. Минусов много:
* хаотичность развития. Новые технологии приходят в моду из-за того, что кто-то вложил кучу денег в их раскрутку, а не потому, что они лучше старых. Пример - react
* низкая квалификация тех, кто принимает решения, по обе стороны моды. Законодатели мод могут сдуру раскрутить какой-нибудь node.js для серверных применений, а последователи просто тащат в проекте всё что ни попадя, главное, чтобы оно было в моде и сулило в будущем повышение доходов (хотя мода зачастую проходит и инвестиции в изучение новой модной технологии оказываются напрасными)
* наследие, ввиду чего в работе возникает масса затруднений и ограничений. Например, есть близкие по области применения и смыслу Руби, Питон, Перл и PHP - все они нужны. Аналогичная ситуация с Си, С++ и Растом (причём у С++ ещё и множество разных стандартов и конкурирующих библиотек, делающих одно и то же)
Сейчас технология находится в таком состоянии, что "стереть всё и переписать заново" выглядит достаточно разумной альтернативой, вопрос лишь в том, что это чертовски дорого. Однако у государства заведомо достаточно ресурсов для этого, кроме того оно, государство, всё равно занимается этим.
Всякие там Астра Линуксы, Мои Офисы, Эльбрусы и Касперски ОС являются частными случаями, но вместо того, чтобы взять и переделать сразу всё, переделывают по частям, в итоге все недостатки сохраняются.