Регулирование индустрии программного обеспечения [закрыто]

Каждые несколько лет кто-то предлагает более жесткие правила для индустрии программного обеспечения.

Эта статья IEEE в последнее время привлекает внимание к этой теме.

Если бы разработчики программного обеспечения, которые пишут программы для систем, подвергающих общественный риск физическому или финансовому риску, знали, что они будут проверены на их компетентность, можно подумать, что это уменьшит недостатки и сбои в коде - и, возможно, спасет несколько жизней в результате сделки.

Я скептически отношусь к ценности и достоинствам этого. На мой взгляд, это похоже на захват земли теми, кто это предложил.

Цитата, которая подтверждает это для меня:

Экзамен будет проверять базовые знания, а не владение предметом

потому что большие сбои (например, THERAC-25 ) кажутся сложными, тонкие проблемы, которых «базовые знания» никогда не смогут предотвратить.

Игнорирование любых локальных проблем (таких как существующая защита прав инженера в некоторых юрисдикциях):

Цели благородны - избегайте шарлатанов / шарлатанов ¹ и сделайте это различие более очевидным для тех, кто покупает их программное обеспечение. Может ли жесткое регулирование индустрии программного обеспечения когда-либо достичь своей первоначальной цели?

¹ Точно так же, как было задумано регулирование медицинской профессии.

Представление о том, что инженеры-программисты могут попасть в ту же классификацию, что и медицинские работники или бухгалтеры, является неосведомленным представлением о «проблеме», которую они пытаются решить. Прежде чем я выскажу свое мнение по этому поводу, давайте разберем некоторые аргументы г-на Торнтона, который является заместителем председателя регулирующего органа, предлагающего это законодательство.

«Так же, как практикующие профессионалы, такие как врачи, бухгалтеры и медсестры, имеют лицензию, так и инженеры-программисты», - говорит Торнтон. « Общественность должна иметь возможность полагаться на какие-то полномочия при выборе подрядчика для написания программного обеспечения».

- Митч Торнтон, заместитель председателя IEEE по лицензированию и регистрации

Это звучит очень разумно на поверхности. В конце концов, есть и другие отрасли, которые можно считать «успешно регулируемыми». Под успешным регулированием я подразумеваю, что, если вы посмотрите на доктора на желтых страницах, вы можете быть достаточно уверены, что он или она получил полное образование в аккредитованном университете, сдал ряд экзаменов и закончил резидентуру. Вот некоторые «успешно регулируемые» отрасли (с точки зрения профессиональных кадров).

• Адвокаты
• Врачи
• бухгалтера
• Ядерщики
• Парикмахеры ( не шучу )

В конце концов, вы не хотите, чтобы кто-то удалял эту опухоль из поджелудочной железы или работал на центрифугах этой атомной электростанции в непосредственной близости от города. Почему не должно быть подобных ограничений для разработчиков программного обеспечения?

Только те, чьи программы могут «поставить под угрозу общественное здоровье или безопасность, безопасность, собственность или экономику, должны быть проверены»

Это расплывчатое утверждение, открытое для либеральной интерпретации и применения. Я мог бы привести аргумент, что Apple Inc. или Facebook являются неотъемлемыми частями американской экономики - нужна ли мне специальная лицензия правительства для написания кода для них сейчас, так как, если я отключу сайт своей некомпетентностью, я могу повредить американцу экономика? На моей последней работе я случайно отключил зерновой элеватор из-за неисправной работы cron - возможно, поставив под угрозу снабжение продовольствием.

Я понимаю, что я избегаю истинного намерения этого предложения. Идея заключается в том, чтобы гарантировать, что человек, пишущий код для антиблокировочной тормозной системы на вашей новой Jetta, компетентен и имеет соответствующую лицензию на написание кода для антиблокировочной тормозной системы. На твоей джетте.

Вот проблема: разработка программного обеспечения в наше время включает в себя все, и вы не можете проверить каждую дисциплину. Бизнес-правила слишком специфичны и слишком различны от дисциплины к дисциплине. Наш гипотетический инженер, пишущий код для системы ABS на Jetta, может написать что-то совершенно другое для системы ABS на Elantra. Должен ли он пройти повторную сертификацию?

А что если вы пройдете тестирование по всем этим производным дисциплинам? Предположим на мгновение, что каждый программист, работающий на веб-сайте электронной коммерции, получает сертификат программиста, способного к электронной торговле. Так? Значит ли это вдруг означает , что эти программисты и компании будут фактически сделать необходимые проверки и построить на соответствие PCI? Даже если они это сделают - глюки все равно будут.

По словам Митча Торнтона, заместителя председателя комитета по лицензированию и регистрации IEEE, экзамен будет проверять наличие базовых знаний, а не владение предметом.

Вот кикер. Отсутствие базовых знаний никогда не является проблемой. Мои антиблокировочные тормоза не перестали работать, потому что Чак боролся с концепциями управляющей структуры. Они потерпели неудачу, потому что был сбой, когда ABS отключился из-за короткого замыкания в задних фонарях, и питание не было правильно перенаправлено. Или что-то.

Программное обеспечение для инсулиновой помпы, которое я написал, не перестало работать, потому что мне не хватает базовых навыков; это прекратилось, потому что была ошибка в том, как я измерял дозировку инсулина, когда мой европейский товарищ по команде использовал метрическую систему, а я нет.

Это то, что вы можете учитывать при разработке, но вы никогда не сможете проверить с помощью сертификации .

Вот что произойдет, если эта «сертификация» вступит в силу: количество инцидентов останется неизменным. Почему? Потому что это ничего не делает, чтобы устранить реальную проблему отказа АБС или инсулиновой помпы.

Как удачно, что никто не умирает благодаря медицинскому регулированию, никто не пострадал от мошенничества благодаря финансовому регулированию, никто не лишил своего дома взыскания благодаря жилищному регулированию, никто не получает плохую стрижку благодаря регулированию парикмахера, и ни один самолет никогда не падает благодаря регулированию самолета.

Очевидно, что наличие регулирования не означает отсутствие недостатков или сбоев. И наоборот, наличие недостатков или отказов не означает, что регулирование предотвратит эти недостатки или сбои. Инженеры-программисты уже строго регламентированы как члены соответствующих критически важных для безопасности отраслей, и за пределами этих отраслей нет особой необходимости.

Как показала меткость, история показала, что различие между хорошим мастером и посредственным не может быть проверено с помощью какой-либо объективной меры. Базовые знания не дают великому программисту, мудрости и опыта - который на самом деле нельзя научить или измерить объективно - того, как применять эти базовые знания.

Кроме того, эти тесты обычно заканчиваются несколькими модными словечками и конкретными процедурами и не позволяют измерить что-либо существенное для начала.

Если индустрия программного обеспечения хотела бы создать какую-то гильдию, это было бы гораздо лучшим способом решения этой проблемы. Однако централизация может разрушить только превосходство, а не создать его.

Кроме того, проблемы, которые эта мера пытается предотвратить, скорее всего, не будут обнаружены тестом. В любом случае, я также хотел бы, чтобы @ThomasOwens ответил на этот вопрос.

Роль правительства, по крайней мере исходя из американской идеологии, состоит в том, чтобы привлечь к ответственности разработчиков программного обеспечения за любой ущерб собственности, вызванный их дефектным или небезопасным программным обеспечением. Это будет стимулировать компании применять свои собственные стандарты и нести личную ответственность по этому вопросу. Это всегда лучшее решение, и оно не содержит централизованного правительства, выходящего за границы.

Обновить

Я думал об этом еще немного вчера вечером за пивом или десятью.

Все, что регулировало медицинскую область, было уничтожить все парадигмы, кроме одной. Если их целью было отсеять гомеопатов и натуропатов, которых любезно называли «кряками», то такое регулирование было успешным. Однако я не согласен с тем, что такая вещь выгодна всем, кроме людей, пишущих законодательство. Подумай о том, что это сделало. Это привело к тому, что стоимость медицинского обслуживания поднялась до неприемлемого уровня, значительно повысило уровень ответственности для врачей-медиков и лишило потребителей возможности выбора и самоопределения с рынка. В медицинском сообществе больше нет места для идей, и новые методы лечения и способы мышления о медицине теперь подавлены. Кроме того, барьер для выхода на поле невероятно высок, и в результате у нас не хватает хороших MD s. Кроме того, регулирующие органы имеют полномочия контролировать поставки врачей, чтобы они, в свою очередь, могли контролировать цену, которую платят врачи.

Действительно, есть некоторые выгоды, которые мы получили от медицинского регулирования, но затраты слишком высоки.

То же самое случится с разработчиками программного обеспечения, если такое регулирование будет принято. Теперь я вижу, что регулирующие органы будут определять, что объектно-ориентированное программирование является единственным стандартом проектирования, и функциональным и процедурным программистам не разрешат практиковаться. Затем они начнут говорить нам, что нам не разрешено управлять собственной памятью, потому что это небезопасно. Затем они впихнут JAVA и C # в горло и скажут нам, что мы должны его использовать, в то время как Oracle и Microsoft становятся толще и счастливее. Инновации будут подавлены, а творчество окажется вне закона. Microsoft и Google напишут законодательство, поэтому правила рынка будут направлены на их собственную прибыльность и на социальное благополучие.

Кроме того, позвольте мне напомнить всем, что компьютеры начинали как увлечение и академическая деятельность. Кроме войн Unix 80-х и начала 90-х у нас были бесплатные операционные системы, бесплатные компиляторы, бесплатные программы и так далее ... Это быстро закончится. Мир, который нам завещали Ричард Столлман, Линус Торвальдс и Деннис Ричти, постепенно исчезнет.

Таким образом, я устал от необходимости конкурировать с «Я разработаю для вас сайт WordPress CMS за 25 долларов в час» или с «любым приложением для iPhone за 500 долларов»? Не совсем, почему? Потому что я чертовски хорош в том, что я делаю, и клиенты, которых я хочу, готовы платить за превосходство. Когда я беру на себя проект самостоятельно или по месту работы, я беру на себя ответственность за свою собственную голову и репутацию. Это будет следовать за мной, куда бы я ни шел. Кроме того, большинство людей знают, что они получают то, за что платят. Клиент, который готов заплатить мне только ту цену, которую они платят своему газонному парню, будет в любом случае кошмаром, чтобы иметь дело с ним. Если бы правительство установило правовую структуру, чтобы заставить поставщиков услуг компенсировать их ущерб, тогда было бы очень мало плохих программистов, которые все еще имели бы работу на местах.

Кстати, у нас все еще есть плохие врачи, с той лишь разницей, что сил вывести их с рынка очень мало. Если бы им пришлось взять на себя ответственность за свои собственные действия, они бы прекратили свою деятельность, прежде чем у них появился еще один шанс нанести некомпетентный ущерб своим клиентам.

Новости Кремниевой долины - 31 июня 2015 г.

Ужас: Несертифицированный программист сделал отмену программы

«Я никогда не смогу снова бежать», выводит жертва. Полиция расследует.

Преступник: лицензия доктора Х. Акера-младшего отозвана за неправильное использование указателя и попытки чтения из системного файла

Адвокат говорит, что будет апелляция в Верховный суд.

Объявления: сертифицированные в 1975 году программисты Cobol должны пройти переаттестацию не позднее 2025 года.

Сертификация IEEE с тех пор не изменилась.

Объявления: Сертификация гарантируется с Magic Knowledge Stuffers, Inc

Учи себя программированию за 21 день.

Существует несколько различных способов применения регулирования к любой профессии - четко определенная совокупность знаний, кодекс этики, аккредитация образовательных программ, сертификация и лицензирование, а также профессиональные общества, поддерживающие профессиональное развитие, а также другие аспекты профессии. Разработка программного обеспечения имеет большинство характеристик профессии.

Мне нравится думать об этом как о начале Сводки знаний по разработке программного обеспечения (SWEBOK) и Кодекса этики и профессиональной практики разработки программного обеспечения . Хотя общее их принятие все еще довольно ограничено, я думаю, что они служат хорошей основой для определения типов вещей, о которых кто-то, идентифицирующий себя как инженер-программист, должен знать, и как такой человек должен действовать в профессиональном качестве. Это не означает, что это жесткие правила, скорее, эти документы направляют профессиональных инженеров-программистов в отношении того, что обычно относится к работе, которую они могут попросить сделать. SWEBOK время от времени пересматривается, чтобы обеспечить его актуальность.

Следующая характеристика - аккредитация образовательных программ. В США аккредитация программ по разработке программного обеспечения осуществляется ABET . Они также аккредитуют информатику, информационные технологии, вычислительную технику и другие профессии, связанные с компьютерами. ABET публикует свои требования к аккредитованным программам на своем веб-сайте - разработка программного обеспечения считается инженерной программой. Целью аккредитации является обеспечение согласованности среди выпускников различных инженерных программ, по крайней мере, с точки зрения предмета, преподаваемого в классе. Это ничего не говорит о качестве образования.

После окончания обучения сертификация и лицензирование используются для оценки знаний, полученных в классе (и, в некоторых случаях, на работе), в сравнении со стандартными совокупностями знаний. Несмотря на то, что в аккредитованных школах имеется определенный объем материала для преподавания, не существует показателя того, насколько хорошо этот материал преподается и сколько учащихся учат по завершении программы. Сертификация и лицензирование предоставляют методы для этого - все сдают одни и те же экзамены и демонстрируют знания в различных областях знаний, на которых основана профессия. В разработке программного обеспечения IEEE предлагает сертификаты, основанные на SWEBOK - сертифицированной разработке программного обеспечения. Сотрудник для пожилых людей и недавних выпускников и сертифицированный специалист по разработке программного обеспечениядля тех, кто имеет опыт работы в отрасли. Для того, чтобы они добавили ценность, требуется принятие SWEBOK в качестве хорошего определения того, что такое разработка программного обеспечения.

Наконец, профессиональные общества поддерживают руководящие документы для профессии, организуют конференции и публикации для обмена знаниями и идеями, ликвидируют разрыв между академическими кругами и промышленностью и так далее. Двумя ведущими обществами являются IEEE Computer Society и ACM , но есть и другие сообщества по всему миру. Они упаковывают все в приятный маленький пакет и помогают доставлять информацию нужным людям.

Отсюда есть и другие вопросы. Является ли разработка программного обеспечения инженерной дисциплиной? Добавляет ли сертификация или лицензирование какую-либо ценность для разработчиков программного обеспечения? Полезна ли сертификация?

Я не думаю, что вся разработка программного обеспечения нуждается в строгости инженерной дисциплины. Нельзя сказать, что эмпирическое, научное исследование науки и техники создания программного обеспечения не помогает всем - оно делает. Однако есть большая разница между разработкой новейшей видеоигры, разработкой встроенного программного обеспечения для кардиостимулятора или созданием следующего космического корабля. Акцент на всех них различен - два из трех заслуживают внимания опытного инженера. Другие могут извлечь уроки из инженерных практик, но им не нужно полагаться на них, чтобы успешно завершить проект.

Сертификация и лицензирование требуют общепринятых знаний. SWEBOK - хороший документ, который обеспечивает прочную основу, но он не получил широкого распространения. Если вы не можете основывать свои академические программы и экзамены на сертификацию / лицензирование на чем-то конкретном, что было бы принято практиками, то в этом нет никакого смысла. Если SWEBOK или альтернативный документ становится общепринятым (по крайней мере, в тех областях, которые требуют строгого проектирования), то сертификационные или лицензионные экзамены могут быть использованы для оценки понимания необходимых знаний.

Однако есть одна вопиющая проблема с сертификацией - это тест по книге. Некоторые люди умеют читать, учиться, запоминать и сдавать экзамены. Однако это не значит, что они хороший инженер. Люди проскальзывают сквозь трещины все время. Сертификация или лицензия - это только один шаг. На рабочем месте обучение и наставничество со стороны других опытных инженеров является обязательным для подготовки хорошего специалиста. Кроме того, способность предотвращать практику людей в критических ситуациях также может помочь снизить риски для общества и бизнеса.

Хорошей книгой с достаточно глубоким обсуждением этого является профессиональная разработка программного обеспечения Стива Макконнелла : более короткие сроки, более качественные продукты, более успешные проекты и расширенные карьеры .

Если правительственные нормативные акты будут приняты, индустрия программного обеспечения в США значительно сократится, поскольку затраты, связанные с соблюдением этих нормативных требований, будут выше, чем стартапы и малые предприятия могут себе позволить.

Дефицит и стоимость, связанные с юридической степенью или доктором медицины, станут более или менее заметными в нашей отрасли. Не очень хорошо, когда альтернативой является то, что каждый Джо потенциально может построить следующий Facebook.

Люди делают ошибки, и никакое регулирование не предотвратит бедствия. Рассмотрим NASA, которое предъявляет самые строгие требования к разработке программного обеспечения, известные человеку. У них все еще есть ошибки программного обеспечения? (Да, да, и много раз, да!)

Рынок решает эти проблемы намного лучше, чем нормативные акты. Компании, разрабатывающие программное обеспечение, вызывающее проблемы, несут ответственность за травмы. Остальным из нас не нужно платить за свои ошибки.

В 1999 году ACM опубликовал заявление о лицензировании, когда он в основном отказался от работы IEEE SWEBOK. Изучив общедоступные документы SWEBOK и заявление ACM, я поддерживаю мнение ACM.

Взглянув на статью, кто-то с 4-6 лет опыта должен сдать экзамен, который проверяет базовые знания. Это нелепо, и надо смеяться над дверью.

Программные компоненты устройства являются деталями реализации. Например, в индустрии систем управления все защитные устройства были зашиты, и люди не доверяли программному обеспечению. Однако сейчас мы видим программные защитные устройства, такие как реле безопасности и защитные ПЛК. Это допустимо, потому что они все еще должны соответствовать отраслевым нормам для устройств безопасности (в зависимости от категории безопасности). Следовательно, в некоторых случаях устройствам нужны избыточные процессоры и избыточный код, написанный двумя разными командами и т. Д.

Это продукт, который должен соответствовать правилам безопасности, если он продается и потребляется населением. Эти правила не меняются, потому что продукт содержит программное обеспечение. Работа инженера состоит в том, чтобы убедиться, что продукт соответствует всем нормативным критериям, и если он содержит программное обеспечение, он должен проверить программное обеспечение и быть компетентным в этой области . Если это не так, они (или их компания) несут ответственность, если они одобрили проект, и он оказался неисправным.

Вам на самом деле не нужно регулировать всех программистов только потому, что некоторые продукты должны соответствовать более строгим требованиям. В тех случаях, когда такие продукты включают программное обеспечение, вам необходима хорошо разработанная инженерная дисциплина, которая может надежно определить, соответствует ли программный компонент требованиям. Во всяком случае, это то, что означает IEEE: относительно молодая область разработки программного обеспечения должна быть развита до уровня надежности и доверия других инженерных дисциплин.

Это действительно не имеет никакого отношения к «программированию» и всему, что связано с «разработкой».

Это, конечно, приводит нас к спорному вопросу о различии между разработчиком и и инженером. Как правило, это две разные роли, которые регулярно пересекаются. Часть разработчика означает, что вы делаете программное обеспечение. Инженерная часть роли означает, что если вы печатаете дизайн, вы берете на себя ответственность за общественную безопасность. Вы можете быть одним без другого.

Программное обеспечение уже жестко регламентировано в авиационной промышленности. Смотри DO-178B .

Я уверен, что у других подмножеств отрасли есть свои нормы.

«Программное обеспечение» охватывает так много в наши дни. Я думаю, что было бы абсурдно иметь какое-либо обязательное всеобъемлющее регулирование.

Регулирование индустрии программного обеспечения лучше всего осуществляется через регулирование процессов обеспечения качества.

Это уже сделано - крупные компании-разработчики программного обеспечения имеют множество тестировщиков, менеджеров по обеспечению качества, автоматизированных пакетов тестирования, процессов проверки кода, процессов тестирования и так далее. Есть компании, все цели которых - аудит качества программного обеспечения других компаний. У организаций по стандартизации есть руководящие принципы для QA и Аудитов QA.

Внутри компании инженер-программист отвечает за качество своей работы. Их сдержки и противовесы, однако, находятся в процессах качества компании.

Это так же, как большинство современных попыток решения "проблем, связанных с программным обеспечением". Те, кто пытается издавать законы, мало знают о коренном ходе проблемы. Если при разработке программного обеспечения, критически важного для безопасности, следовать установленному процессу (и намерению, конечно), будь то для самолетов, ядерных установок медицинского оборудования, одной ошибки никогда не будет достаточно, чтобы вызвать сбой. Весь алгоритм может быть реализован неправильно, без ущерба для любого.

FDA и FTA требуют анализа рисков и основаны на стратегии смягчения. Последнее обычно представляет собой стратегию швейцарского сыра, в которой принимается, что какое-либо смягчение является ошибочным, поэтому применяется несколько мер по снижению риска для одного и того же риска (одно смягчение может также применяться к нескольким рискам) каждое смягчение похоже на кусок швейцарского сыра, который вы можете просмотреть один, может быть, два ломтика, вместе взятые, но сложите достаточно ломтиков, и это больше невозможно. Даже тогда, когда меры по снижению риска реализованы идеально, это не приводит к 100% безопасности оборудования. Если анализ риска будет неправильным, будут риски, о которых никто не задумывался (Y2K).

Вы можете тестировать инженеров, сколько хотите, даже тестировать по предмету и требовать очень высокого уровня, но это будет иметь большое значение. Большинство критических ошибок безопасности - ошибки интеграции. Они не являются ошибками в коде одного человека, а возникают из-за несоответствия между программным и аппаратным обеспечением двух программных систем или из-за того, что альфа-частица выбила программный счетчик из правильного местоположения.

Я был на нескольких критически важных для безопасности системах с опытными и способными разработчиками, которые прошли бы любое разумное испытание в своей области. Я никогда не был в проекте, где у нас не было критической ошибки безопасности. (К счастью, я никогда не был на том, где система когда-либо вредила кому-либо)

Никогда нельзя полностью уничтожить шарлатанов и шарлатанов, потому что они существуют практически во всех профессиях, даже в медицинских профессиях, несмотря на давно сложившиеся практики и традиции.

Хотя это утверждение является захватом земли, я не уверен, что темный и страшный повелитель всех вещей, которые ИТ-отдел дьявольски замышляет, его беспрепятственный контроль и регулирование разработки программного обеспечения. Если вы на самом деле говорите об IEEE, у них, безусловно, есть регуляторный аспект, но соответствие стандартам IEEE более или менее по желанию, а не под угрозой. Они пытаются разработать универсальные отраслевые стандарты, чтобы мы все говорили на одном языке и повышали эффективность по всем направлениям.

Кроме того, изложенные ими стандарты помогают легитимизировать общие практики и закладывают основу для разработки программного обеспечения, чтобы в конечном итоге стать более дисциплинированной областью разработки, в отличие от машиностроения или химической инженерии. Хотя программное обеспечение приближается к этой цели, оно, вероятно, никогда не будет полностью общепринятым в качестве инженерной дисциплины.

Основная проблема заключается в том, что разработчик программного обеспечения может делать что угодно, от написания симпатичного рабочего стола до реализации систем наведения ракет. В одном случае серьезность и последствия ошибки намного выше, чем в другом, и, следовательно, требуется строго регламентированная инженерная дисциплина для разумного, безопасного и эффективного подхода. Это очень похоже на серьезность ошибки в неправильно спроектированном мосту и в результате его разрушения. Дизайнеры моста должны соблюдать мои инженерные стандарты, чтобы обеспечить качество.

Я не назвал бы это более жестким регулированием, но вместо этого препятствия для входа. В этом отношении я думаю, что есть заслуга. Для повышения качества, это очень спорно.

В настоящее время любой Джон / Джейн Доу может написать программу. Там нет барьера для входа. Возьмите несколько книг по сценариям и веб-технологиям и начните взламывать, или, что еще хуже, просто начните поискать в Google, как это сделать.

Когда мы, как коллективное целое, решаем, может быть, пришло время увеличить барьеры для входа, поднять отрасль на более высокий стандарт, превратиться из хакера / ремесленника в инженера, - вот такое регулирование, на котором я все нахожусь.

Сегодня слишком много неквалифицированных людей программируют. Работают ли они на критических системах или нет, они все еще производят код, все еще производят Big Balls of Mud .

В этом отношении, саморегулирование или, более точно, создание барьеров для входа - это хорошо. Потому что мы говорим: эй, ты не можешь просто выйти с улицы и назвать себя инженером программного обеспечения. Вы действительно должны продемонстрировать уровень мастерства.

Демонстрация навыка - это больше, чем просто прохождение теста или получение «знака чести». Тест - это просто проверка. Настоящая проверка - школа, стажировка, ученичество, наставничество у пожилых людей, практика - все это является частью этого.

Я вижу, чего пытается достичь IEEE, но на данный момент это бесполезное занятие. Индустрия быстро меняется, слишком высокий спрос на продукт, «хакерское» мышление и т. Д. Регулирование должно исходить изнутри, если оно вообще происходит.

Я не читал статью, но если вопрос в том, может ли регулирование индустрии программного обеспечения принести пользу человечеству, я думаю, что это зависит от обстоятельств:

1. Индустрия в целом включает в себя широкий спектр доменов, некоторые из которых являются жизненно важными (например, контроль дозы облучения в медицинском устройстве), а некоторые нет (приложение Facebook «Какой маппет вы?»). Я не вижу никаких аргументов для регулирования для приложений, где ставки низкие.

2. Не следует начинать с правового регулирования. Скорее, следует начать с программы сертификации для разработчиков. Вопрос о правовом регулировании может возникнуть только в том случае, если программа сертификации приносит ощутимую пользу.

3. Даже если программа сертификации дает измеримые результаты, вполне вероятно, что отрасль стандартизирует требование этой сертификации по сугубо деловым причинам, и нам не потребуется правовое регулирование. (Вот почему существуют такие делегации, как MCSE - компании предпочитают нанимать MCSE для доменов, в которых обучаются MCSE.)

4. Тем не менее, все еще остаются области, в которых с деловой точки зрения имеет смысл причинять вред (часто это негативные внешние эффекты , иногда они являются результатом влияния на рынке для некоторых учреждений). Например, область может иметь одну местную больницу; в этом случае качество внутреннего программного обеспечения может иметь огромное значение для уровня обслуживания, которое получает пациент, но не имеет такого большого значения в том, какую больницу выбирает пациент. Больница тогда не обязательно имеет много экономических обоснований для инвестирования в более качественных разработчиков. В этом случае может быть случай общественного здравоохранения для регулирования застройщиков, которых больнице разрешено нанимать.

ИМХО.

Я должен ответить на этот ...

Начиная с того, что сказал @JonathanHenson, и с появлением @gnat, я говорю, что все в порядке, люди, у которых есть деньги, могут платить за сертифицированные вещи, люди или страны, у которых нет денег, не могут платить за лицензии (так много за сертифицированные вещи ), так что все еще будут отступники, если это войдет в практику. Даже если традиционные (и не очень традиционные) методы доставки закрыты, люди все равно найдут способы доставки программного обеспечения заинтересованным пользователям. Даже если это означает разработку другого протокола HTTP или даже альтернативного целого сетевого стека, сосредоточенного только на том, чтобы сделать соединения необнаружимыми (см. Последний абзац, для кого-то, кто мог бы сделать это).

Кроме того, сама идея оплаты чего-либо находится под угрозой, поскольку мир становится все беднее и беднее, поэтому все больше и больше людей будут иметь все меньше и меньше денег для оплаты вещей, есть даже страны, которые используют только программное обеспечение FOSS, без каких-либо сертификация (на ум приходят Бразилия и Индия, но есть и другие), и некоторые из этих стран становятся большими, действительно большими. И они используют несертифицированное программное обеспечение, созданное неизвестными программистами, мастерство которых неизвестно.

Кроме того, даже если есть какой-то тип сертификации, сертификация будет сертифицировать только знания, а не этику, просто подумайте, что некоторые врачи используют органы, которые были извлечены несанкционированным образом у людей, поэтому были бы также сертифицированные программисты, которые бы не иметь этики и писать неаккуратный код намеренно или непреднамеренно. В то время как в большинстве проектов FOSS большинство потенциально неквалифицированных программистов также рассматривают код других и пытаются найти ошибки, что делает парное программирование чем-то незначительным.

Наконец, что вы говорите о хакерских группах (не хакерских группах, а белых или серых), которые знают гораздо больше о безопасности и разрабатывают программное обеспечение для безопасности таким образом, чтобы это соответствовало только наиболее специализированным программистам из определенных государственных ведомств.