Cada pocos años, alguien propone una regulación más estricta para la industria del software.
Este artículo de IEEE ha estado recibiendo atención últimamente sobre el tema.
Si los ingenieros de software que escriben programas para sistemas que exponen al público a riesgos físicos o financieros supieran que se les evaluaría su competencia, según el pensamiento, reduciría las fallas y fallas en el código, y tal vez salvaría algunas vidas en el negocio.
Soy escéptico sobre el valor y el mérito de esto. En mi opinión, parece una apropiación de tierras por parte de quienes lo propusieron.
La cita que lo confirma para mí es:
El examen evaluará los conocimientos básicos, no el dominio de la materia.
porque las grandes fallas (por ejemplo, THERAC-25 ) parecen ser problemas complejos y sutiles que el "conocimiento básico" nunca sería suficiente para prevenir.
Ignorando cualquier problema local (como las protecciones existentes del título de Ingeniero en algunas jurisdicciones):
Los objetivos son nobles: evitar los charlatanes / charlatanes 1 y hacer que esa distinción sea más obvia para aquellos que compran su software. ¿Puede una regulación más estricta de la industria del software lograr su objetivo original?
1 Exactamente como se pretendía hacer la regulación de la profesión médica.
fuente
Respuestas:
La opinión de que los ingenieros de software pueden ser encasillados en la misma clasificación que los profesionales médicos o contadores es una visión ignorante del "problema" que están tratando de resolver. Antes de dar mi opinión sobre esto, analicemos algunos de los argumentos del Sr. Thornton, quien es Vicepresidente del organismo regulador que propone esta legislación.
Esto suena muy razonable en la superficie. Después de todo, hay otras industrias que podrían considerarse "reguladas con éxito". Por exitosamente regulado quiero decir que si busca a un médico en las páginas amarillas, puede estar razonablemente seguro de que él o ella ha tenido una educación exhaustiva en una universidad acreditada y ha aprobado varios exámenes y completado una residencia. Aquí hay algunas industrias "exitosamente reguladas" (en términos de personal profesional).
Después de todo, no desea que cualquiera extraiga ese tumor de su páncreas o trabaje en las centrífugas de esa central nuclear a las afueras de la ciudad. ¿Por qué no deberían existir restricciones similares para los ingenieros de software?
Esta es una declaración vaga y abierta a interpretaciones y aplicaciones liberales. Podría argumentar que Apple Inc. o Facebook son partes integrales de la economía estadounidense: ¿necesito una licencia especial del gobierno para escribir código para ellos ahora, ya que si derribo el sitio con mi incompetencia podría dañar al estadounidense? ¿economía? En mi último trabajo, accidentalmente apagué un elevador de granos con un trabajo cron defectuoso, posiblemente poniendo en peligro el suministro de alimentos.
Me doy cuenta de que estoy evitando la intención real de esta propuesta. La idea detrás de esto es garantizar que la persona que escribe el código para el Sistema de frenos antibloqueo en su nuevo Jetta sea competente y tenga la licencia adecuada para escribir el código de un Sistema de frenos antibloqueo. En tu Jetta.
Aquí está el problema: la ingeniería de software en este día y edad abarca todo y no es posible probar para cada disciplina. Las reglas comerciales son demasiado específicas y varían de disciplina en disciplina. Nuestro ingeniero hipotético escribiendo código para el sistema ABS en un Jetta podría estar escribiendo algo completamente diferente para el sistema ABS en un Elantra. ¿Tiene que volver a certificarse?
¿Y qué pasa si prueba para todas estas disciplinas derivadas? Supongamos por un momento que cada programador que trabaja en un sitio web de comercio electrónico se certifica como un programador capaz de comercio electrónico. ¿Entonces? ¿Significa esto de repente que estos programadores y compañías realmente harán la validación necesaria y desarrollarán el cumplimiento de PCI? Incluso si lo hacen, los problemas técnicos seguirán ocurriendo.
Aquí está el pateador. La falta de conocimientos básicos nunca es el problema. Mis frenos antibloqueo no dejaron de funcionar porque Chuck estaba luchando con los conceptos de una estructura de control. Fracasaron porque hubo un fallo en el que el ABS se apagó debido a un cortocircuito eléctrico en las luces traseras y la energía no se desvió correctamente. O algo.
El software de la bomba de insulina que escribí no dejó de funcionar porque me faltan habilidades básicas; se detuvo porque hubo un error en la forma en que medí la dispensación de insulina cuando mi compañero de equipo europeo usó el sistema métrico y yo no.
Eso es algo que puede tener en cuenta en el desarrollo, pero nunca podría probar con una certificación .
Esto es lo que sucederá si esta "certificación" entra en vigencia: la cantidad de incidentes se mantendrá exactamente igual. ¿Por qué? Porque no hace nada para eliminar el problema real de una falla de ABS o bomba de insulina.
fuente
Qué afortunado de que nadie muera gracias a la regulación médica, que nadie sea herido por fraude gracias a la regulación financiera, que nadie tenga su casa embargada gracias a la regulación de la vivienda, que nadie se corte el pelo gracias a la regulación del peluquero, y que ningún avión se estrelle nunca gracias a la regulación de aeronaves.
Obviamente, la presencia de regulación no implica la ausencia de fallas o fallas. Por el contrario, la presencia de fallas o fallas no implica que la regulación prevenga esas fallas o fallas. Los ingenieros de software ya están altamente regulados como miembros de las respectivas industrias críticas para la seguridad, y fuera de esas industrias hay poca necesidad.
fuente
La historia ha demostrado, acertadamente, creo, que la diferencia entre un excelente artesano y un mediocre no puede probarse con ninguna forma de medida objetiva. El conocimiento básico no es un gran programador, la sabiduría y la experiencia, que realmente no se puede enseñar o medir objetivamente, de cómo aplicar ese conocimiento básico.
Además, estas pruebas generalmente terminan siendo solo algunas palabras de moda y procedimientos concretos y, al principio, no pueden medir nada sustantivo.
Si la industria del software quisiera desarrollar un gremio de algún tipo, esa sería una forma mucho mejor de abordar el problema. Sin embargo, la centralización solo tiene el poder de destruir la excelencia: no crearla.
Además, los problemas que esta medida está tratando de prevenir probablemente no sean detectados por una prueba de todos modos. De todos modos, también me encantaría ver a @ThomasOwens responder a esta.
Lo que sería el papel del gobierno, al menos desde la ideología estadounidense, sería responsabilizar a las compañías de software por cualquier daño a la propiedad causado por su software defectuoso o inseguro. Esto alentaría a las empresas a hacer cumplir sus propios estándares y asumir la responsabilidad personal del asunto. Esta es siempre una mejor solución, y no contiene un gobierno centralizado que sobrepase sus límites.
Actualizar
Estaba pensando en esto un poco más anoche con una cerveza o diez.
Todo lo que hizo la regulación del campo médico fue exterminar todos los paradigmas menos uno. Si su objetivo era eliminar a los médicos homeópatas y naturopáticos, a quienes el operador amablemente denominó "charlatanes", entonces dicha regulación fue exitosa. Sin embargo, no estoy de acuerdo con que tal cosa sea rentable para nadie, excepto para las personas que escriben la legislación. Piensa en lo que ha hecho esto. Ha aumentado el costo de la atención médica a niveles insostenibles, ha aumentado considerablemente los niveles de responsabilidad para los médicos y ha eliminado del mercado todo el poder de elección y autodeterminación del consumidor. No hay más mercado para ideas en la comunidad médica, y ahora se suprimen los nuevos tratamientos y formas de pensar sobre la medicina. Además, la barrera para ingresar al campo es increíblemente alta y, como resultado, tenemos una escasez de buenos MD s. Además, las agencias reguladoras tienen el poder de controlar el suministro de médicos para que a su vez puedan controlar el precio que se les paga a los médicos.
De hecho, hay algunas ganancias que hemos recibido de la regulación médica, pero los costos son demasiado altos.
Lo mismo ocurrirá con los ingenieros de software si se aprueba dicha regulación. Puedo verlo ahora, las agencias reguladoras dictaminarán que la programación orientada a objetos es el único estándar de diseño y que los programadores funcionales y de procedimiento no podrán practicar. Luego comenzarán a decirnos que no podemos administrar nuestra propia memoria porque no es segura. Luego, meterán JAVA y C # en nuestras gargantas y nos dirán que tenemos que usarlo mientras Oracle y Microsoft se vuelven más gordos y felices. La innovación será sofocada y la creatividad será prohibida. Microsoft y Google redactarán la legislación, por lo que las reglas del mercado se inclinarán hacia su propia rentabilidad y contra el bienestar social.
Además, permítanme recordarles a todos que las computadoras comenzaron como un aficionado y un esfuerzo académico. Aparte de las guerras de Unix de los años 80 y principios de los 90, hemos tenido sistemas operativos gratuitos, compiladores gratuitos, programas gratuitos, etc. Esto terminaría rápidamente. El mundo que nos dejaron Richard Stallman, Linus Torvalds y Dennis Richtie se desvanecerá gradualmente de la existencia.
En resumen, ¿me canso de tener que competir con "Te diseñaré un sitio de WordPress CMS por $ 25 por hora" o con "cualquier aplicación de iPhone por $ 500"? ¿No realmente por qué? Porque soy muy bueno en lo que hago y los clientes que quiero están dispuestos a pagar por la excelencia. Cuando asumo un proyecto de forma independiente o en mi lugar de trabajo, corro el riesgo de que mis f * & ^ ups sobre mi propia cabeza y reputación. Eso me seguirá a donde quiera que vaya. Además, la mayoría de las personas saben que obtienen lo que pagan. De todos modos, un cliente que solo está dispuesto a pagarme el precio que le pagan a su chico del césped será una pesadilla. Si el gobierno fijara la estructura legal para obligar a los proveedores de servicios a compensar sus daños, entonces habría muy pocos programadores malos que todavía tuvieran empleo en el campo.
Por cierto, todavía tenemos malos médicos, la única diferencia es que hay muy pocas fuerzas para sacarlos del mercado. Si tuvieran que asumir la responsabilidad de sus propias acciones, estarían fuera del negocio antes de tener otra oportunidad de causar estragos incompetentes sobre sus clientes.
fuente
Noticias de Silicon Valley - 31 de junio de 2015
Horror: programador no certificado hizo abortar programa
Criminal: Se revocó la licencia del Dr. H. Acker Jr. por uso incorrecto del puntero e intentos de lectura del archivo del sistema
Anuncios: los programadores de Cobol certificados en 1975 deben volver a certificarse a más tardar en 2025
Anuncios: Certificación garantizada con Magic Knowledge Stuffers, Inc
fuente
Hay algunas formas diferentes de aplicar la regulación a cualquier profesión: un cuerpo de conocimiento bien definido, un código de ética, acreditación de programas educativos, certificación y licencias, y sociedades profesionales que apoyan el desarrollo profesional, así como los otros aspectos de un profesión. La ingeniería de software tiene la mayoría de las características de una profesión.
Me gusta pensar que comienza con el Cuerpo de Conocimientos de Ingeniería de Software (SWEBOK) y el Código de Ética y Práctica Profesional de Ingeniería de Software . Aunque la aceptación común de estos aún es bastante limitada, creo que sirven como una buena base para identificar los tipos de cosas que alguien que se identifica a sí mismo como ingeniero de software debería conocer y cómo esa persona debería actuar en calidad profesional. Eso no significa que estas son reglas estrictas, sino que estos documentos guían a los ingenieros de software profesionales en cuanto a lo que generalmente es relevante para el trabajo que se les puede pedir que hagan. El SWEBOK se revisa periódicamente para garantizar que siga siendo relevante.
La siguiente característica es la acreditación de los programas educativos. En los Estados Unidos, ABET maneja la acreditación de programas de ingeniería de software . También acreditan informática, tecnología de la información, ingeniería informática y otras profesiones relacionadas con la informática. ABET publica sus requisitos de programas acreditados en su sitio web: la ingeniería de software se considera un programa de ingeniería. El propósito de la acreditación es garantizar la coherencia entre los graduados de diferentes programas de ingeniería, al menos en términos de la materia que se enseña en el aula. No dice nada sobre la calidad de la educación.
Después de la graduación, la certificación y las licencias se utilizan para evaluar el conocimiento aprendido en el aula (y, en algunos casos, en el trabajo) frente a los cuerpos de conocimiento estándar. Aunque las escuelas acreditadas tienen un cuerpo definido de material para ser enseñado, no hay una medida de qué tan bien se enseña este material y cuánto aprenden los estudiantes al finalizar el programa. La certificación y las licencias proporcionan métodos para hacerlo: todos toman los mismos exámenes y demuestran un conocimiento en los diversos cuerpos de conocimiento en los que se basa la profesión. En ingeniería de software, el IEEE ofrece certificaciones que se basan en SWEBOK: el desarrollo de software certificado Asociado para personas mayores y recién graduados y el Profesional Certificado en Desarrollo de Softwarepara aquellos con experiencia en la industria. Para que estos agreguen valor, se requiere la aceptación de SWEBOK como una buena definición de lo que es la ingeniería de software.
Finalmente, las sociedades profesionales mantienen los documentos guía para la profesión, facilitan conferencias y publicaciones para el intercambio de conocimientos e ideas, cubren brechas entre la academia y la industria, etc. Las dos sociedades líderes son la IEEE Computer Society y la ACM , pero hay otras sociedades en todo el mundo. Estos envuelven todo en un pequeño paquete agradable y ayudan a entregar información a las personas adecuadas.
A partir de aquí, hay otras preguntas que hacer. ¿Es el desarrollo de software una disciplina de ingeniería? ¿La certificación o la licencia agregan algún valor a los ingenieros de software? ¿Es útil la certificación?
No creo que todo el desarrollo de software necesite el rigor de una disciplina de ingeniería. Eso no quiere decir que un estudio empírico y científico de la ciencia y la ingeniería del software de construcción no ayude a todos, lo hace. Sin embargo, hay una gran diferencia entre desarrollar el último videojuego, desarrollar el software integrado para un marcapasos o construir la próxima nave espacial. El énfasis es diferente en todos ellos: dos de los tres merecen la atención de un ingeniero experto. El otro puede aprender de las prácticas de ingeniería, pero no necesita confiar en ellas para completar con éxito el proyecto.
La certificación y la licencia requieren un cuerpo de conocimiento aceptado. El SWEBOK es un buen documento que proporciona una base sólida, pero no es ampliamente aceptado. A menos que pueda basar sus programas académicos y exámenes de certificación / licencia en algo concreto que sería aceptado por los profesionales, entonces realmente no tiene sentido. Si el SWEBOK o el documento alternativo se acepta ampliamente (al menos en aquellos campos que requieren el rigor de la ingeniería), entonces los exámenes de certificación o licencia pueden usarse para medir la comprensión del conocimiento requerido.
Sin embargo, hay un problema evidente con la certificación: es una prueba en un libro. Algunas personas son buenas para leer, aprender, memorizar y tomar un examen. Sin embargo, eso no significa que sean buenos ingenieros. La gente se desliza por las grietas todo el tiempo. Una certificación o licencia es solo un paso. En el trabajo, la capacitación y el asesoramiento de otros ingenieros experimentados es obligatorio para preparar a un buen profesional. Además, la capacidad de evitar que las personas practiquen en entornos críticos también puede ayudar a mitigar los riesgos para la sociedad y las empresas.
Un buen libro con una discusión bastante profunda sobre esto es el Desarrollo de software profesional de Steve McConnell : horarios más cortos, productos de mayor calidad, proyectos más exitosos y carreras mejoradas .
fuente
Si se aprueban las regulaciones gubernamentales, la industria del software en los EE. UU. Se contraerá significativamente, porque el costo asociado con el cumplimiento de esas regulaciones será más alto de lo que las nuevas empresas y las pequeñas empresas pueden pagar.
La escasez y el costo asociados con un título de Derecho o un Doctor en Medicina serán más o menos visibles en nuestra industria. No es bueno cuando la alternativa es que cada Joe podría construir el próximo Facebook.
La gente comete errores, y ninguna cantidad de regulación evitará que ocurran desastres. Considere la NASA, que tiene los requisitos más estrictos para el desarrollo de software conocidos por el hombre. ¿Todavía tienen errores de software? (Sí, sí, y muchas veces, ¡sí!)
El mercado resuelve estos problemas mucho mejor que las regulaciones. Las empresas que crean software que causa problemas son responsables por las personas a las que lesionan. El resto de nosotros no necesita pagar por sus errores.
fuente
En 1999, el ACM emitió una declaración sobre licencias cuando se retiró en gran medida del trabajo de IEEE SWEBOK. Después de revisar los documentos SWEBOK disponibles públicamente y la declaración de ACM, apoyo la opinión de ACM.
Echando un vistazo al artículo, se requiere que alguien con 4-6 años de experiencia tome el examen, que evalúa los conocimientos básicos. Eso es más que ridículo, y debería reírse por la puerta.
fuente
Los componentes de software de un dispositivo son un detalle de implementación. Por ejemplo, en la industria de los sistemas de control, todos los dispositivos de seguridad solían estar cableados y la gente no confiaba en el software. Sin embargo, ahora estamos viendo dispositivos de seguridad basados en software como relés de seguridad y PLC de seguridad. Estos son permisibles porque todavía tienen que cumplir con las regulaciones de la industria para dispositivos de seguridad (dependiendo de la categoría de seguridad). Por lo tanto, en algunos casos los dispositivos necesitan procesadores redundantes y código redundante escrito por dos equipos diferentes, etc.
Es el producto que debe cumplir con las pautas de seguridad para que el público pueda venderlo y consumirlo. Esas reglas no cambian porque el producto contiene software. El trabajo del ingeniero es asegurarse de que el producto cumpla con todos los criterios reglamentarios y, si contiene software, deben revisarlo y ser competentes en ese campo . Si no lo están, ellos (o su compañía) son responsables si aprobaron el diseño y resulta ser defectuoso.
Realmente no es necesario regular a todos los programadores solo porque algunos productos deben cumplir con requisitos más estrictos. En los casos en que dichos productos involucren software, necesita una disciplina de ingeniería bien desarrollada que pueda determinar de manera confiable que el componente de software cumple con los requisitos. En todo caso, eso es lo que significa el IEEE: el campo relativamente joven de la ingeniería de software debe desarrollarse al nivel de confiabilidad y confianza de otras disciplinas de ingeniería.
Realmente no tiene nada que ver con "programación" y todo que ver con "ingeniería".
Esto, por supuesto, nos devuelve al tema polémico de la diferencia entre un desarrollador y un ingeniero. Estos son generalmente dos roles diferentes que se superponen regularmente. La parte del desarrollador significa que haces software. La parte de ingeniería de la función significa que si estampa el diseño, asume la responsabilidad de la seguridad pública. Usted puede ser uno sin el otro.
fuente
El software ya está estrictamente regulado en la industria aeronáutica. Ver DO-178B .
Estoy seguro de que otros subconjuntos de la industria tienen sus normas.
El "software" abarca mucho en estos días. Creo que sería absurdo tener una regulación obligatoria que lo abarque todo.
fuente
La regulación de la industria del software se realiza mejor a través de la regulación de los procesos de Garantía de Calidad.
Esto ya está hecho: las grandes compañías de software tienen multitud de probadores, gerentes de control de calidad, suites de pruebas automatizadas, procesos de revisión de código, procesos de prueba, y así sucesivamente. Hay compañías cuyo propósito es realizar auditorías de calidad de software en otras compañías. Las organizaciones de estándares tienen pautas para el control de calidad y para las auditorías de control de calidad.
Dentro de una empresa, un ingeniero de software es responsable de la calidad de su trabajo. Sin embargo, sus controles y contrapesos se encuentran en los procesos de calidad de la empresa.
fuente
Es lo mismo que la mayoría de los intentos modernos de resolver "problemas relacionados con el software". Aquellos que intentan legislar tienen poco conocimiento de la raíz del problema. Si sigue el proceso prescrito (y la intención, por supuesto) al desarrollar un software crítico para la seguridad, sea que para las aeronaves, las plantas nucleares de equipos médicos, un solo error nunca será suficiente para causar una falla. Un algoritmo completo puede implementarse incorrectamente sin que nadie resulte perjudicado.
La FDA y el TLC requieren un análisis de riesgos y, en base a eso, una estrategia de mitigación. La última suele ser una estrategia de queso suizo donde uno acepta que cualquier mitigación es defectuosa, por lo que se aplican múltiples mitigaciones para el mismo riesgo (una mitigación también se puede aplicar a varios riesgos) cada mitigación es como una rebanada de queso suizo que puede ver a través de uno, tal vez dos rebanadas juntas, pero junte suficientes rebanadas y eso ya no es posible. Incluso cuando las mitigaciones se implementan perfectamente, eso no da como resultado un equipo 100% seguro. Si el análisis de riesgos es incorrecto, habrá riesgos en los que nadie pensó (Y2K).
Puede probar a los ingenieros todo lo que quiera, incluso podría probar sobre el tema y requerir un nivel extremadamente alto, pero sería muy importante. La mayoría de los errores críticos de seguridad son errores de integración. No son errores en el código de un solo hombre, sino que surgen debido a desalineaciones entre el software y el hardware de dos sistemas de software o porque una partícula alfa eliminó el contador del programa de su ubicación correcta.
He estado en varios sistemas críticos de seguridad con desarrolladores altamente experimentados y capaces, que pasarían cualquier prueba sensata en su campo. Nunca he estado en un proyecto donde no tuvimos un error crítico de seguridad. (Afortunadamente, nunca he estado en uno donde el sistema haya dañado a alguien)
fuente
Uno nunca puede eliminar completamente a los charlatanes y charlatanes porque existen en casi todas las profesiones, incluso en las profesiones médicas a pesar de las prácticas y tradiciones establecidas desde hace mucho tiempo.
Sin embargo, dado que esta afirmación es un acaparamiento de tierras, no estoy seguro de qué oscuro y aterrador señor de todas las cosas que TI está diabólicamente tramando su control y regulación sin restricciones del desarrollo de software. Si de hecho está hablando del IEEE, ciertamente tienen un aspecto regulatorio, pero el cumplimiento de los estándares del IEEE es más o menos a voluntad, y no a punta de pistola. Están tratando de desarrollar estándares universales de la industria para que todos hablemos el mismo idioma y aumentemos la eficiencia en todos los ámbitos.
Además, los estándares que establecen ayudan a legitimar las prácticas comunes y sientan las bases para que el desarrollo de software se convierta en un campo de ingeniería más disciplinado, no muy diferente de la ingeniería mecánica o la ingeniería química. Si bien el software se está acercando a ese objetivo, es probable que nunca sea completamente aceptado universalmente como una disciplina de ingeniería.
El problema central es que un desarrollador de software podría estar haciendo cualquier cosa, desde escribir un widget de escritorio bonito, hasta implementar sistemas de guía de misiles. En uno, la gravedad y la consecuencia del error es mucho mayor que el otro, y por lo tanto exige una disciplina de ingeniería estrictamente regulada para abordar de manera razonable, segura y eficiente. Esto es muy parecido a la gravedad del error en un puente que se diseña incorrectamente y que se derrumba como resultado. Los diseñadores del puente deben cumplir con mis estándares de ingeniería para garantizar la calidad.
fuente
No lo llamaría una regulación más estricta, sino barreras de entrada. En ese sentido, creo que hay mérito. Para una mayor calidad, eso es muy discutible.
Actualmente, cualquier John / Jane Doe puede escribir un programa. No hay barrera de entrada. Elija algunos libros sobre secuencias de comandos y tecnología web y comience a piratear, o peor aún, comience a buscar en Google cómo "hacerlo".
Cuando nosotros, como un todo colectivo, decidamos que tal vez es hora de aumentar las barreras de entrada, mantener a la industria a un nivel más alto, evolucionar de hacker / artesano a ingeniero, ese tipo de regulación en la que estoy metido.
Hay demasiados individuos no calificados que programan hoy. Ya sea que funcionen o no en sistemas críticos, todavía están produciendo código, todavía producen Big Balls of Mud .
En ese sentido, la autorregulación o la creación de barreras de entrada más acertadamente es algo bueno. Porque estamos diciendo, oye, no puedes salir de la calle y llamarte ingeniero de software. En realidad, tienes que demostrar un nivel de habilidad.
Demostrar habilidad es más que solo tomar una prueba u obtener una "insignia de honor". Una prueba es solo una validación. La validación real es la escuela, la pasantía, el aprendizaje, la tutoría para personas mayores, la práctica, todo es parte de ella.
Puedo ver lo que el IEEE está tratando de lograr, pero en este punto es un ejercicio infructuoso. La industria cambia rápidamente, hay demasiada demanda para sacar el producto por la puerta, la mentalidad de "pirata informático", etc. La regulación tiene que venir desde dentro, si es que lo hace.
fuente
No he leído el artículo, pero si la pregunta es si la regulación de la industria del software puede beneficiar a la humanidad, creo que depende de las circunstancias:
La industria en su conjunto abarca una amplia variedad de dominios, algunos de los cuales son críticos para la vida (por ejemplo, controlar la dosis de radiación en un dispositivo médico), y otros no (la aplicación de Facebook "¿Qué Muppet eres?"). No puedo ver ningún argumento a favor de la regulación para aplicaciones donde las apuestas son bajas.
Uno no debe comenzar con la regulación legal. Más bien, uno debe comenzar con un programa de certificación para desarrolladores. Solo si el programa de certificación produce algún beneficio medible debería haber una cuestión de regulación legal.
Incluso si un programa de certificación produce resultados medibles, es probable que la industria se estandarice al requerir esta certificación por razones estrictamente comerciales, y no necesitaríamos una regulación legal. (Es por eso que existen delegaciones como MCSE : las empresas prefieren contratar MCSE para los dominios en los que se capacita a MCSE).
Dicho todo esto, todavía quedan dominios en los que tiene sentido comercial causar daño (a menudo, estas son externalidades negativas , a veces son el resultado del poder de mercado para algunas instituciones). Por ejemplo, un área puede tener un solo hospital local; en este caso, la calidad del software de back-end puede marcar una gran diferencia en el nivel de atención que recibe un paciente, pero no hace mucha diferencia en qué hospital elige el paciente. Entonces, el hospital no necesariamente tiene muchos argumentos comerciales para invertir en desarrolladores de mayor calidad. En este caso, puede haber un caso de salud pública para regular a los desarrolladores que el hospital puede contratar.
EN MI HUMILDE OPINIÓN.
fuente
Tengo que responder a esta ...
Comenzando con lo que dijo @JonathanHenson y la entrada de @gnat, lo que digo está bien, las personas que tienen dinero pueden pagar por cosas certificadas, las personas o países que no tienen dinero no pueden pagar por las licencias (tanto por cosas certificadas ), por lo que aún habrá renegados si eso se pone en práctica. Incluso si los métodos de entrega tradicionales (y no tan tradicionales) están cerrados, las personas aún encontrarán formas de entregar software a los usuarios interesados. Incluso si significa desarrollar otro protocolo HTTP o incluso una pila de red completa alternativa, solo enfocada en hacer que las conexiones sean indetectables (vea el último párrafo, para alguien que pueda hacer esto).
Además, la idea de pagar por algo está en riesgo, ya que el mundo se está volviendo cada vez más pobre, por lo que cada vez más personas tendrán cada vez menos dinero para pagar las cosas, incluso hay países que solo usan el software FOSS, sin ningún tipo de certificación (Brasil e India vienen a la mente, pero hay otros seguros), y algunos de esos países se están volviendo grandes, realmente grandes. Y utilizan software no certificado creado por programadores desconocidos, cuya habilidad es desconocida.
Además, incluso si hay algún tipo de certificación, la certificación solo certificará el conocimiento, no la ética, solo piensa que algunos médicos usan órganos que las personas extraen de manera no autorizada, por lo que también habría programadores certificados que no tiene ética y escribe código descuidado ya sea intencionalmente o no. Mientras que en la mayoría de los proyectos FOSS, la mayoría de los programadores potencialmente no calificados también revisan el código de otros e intentan encontrar errores, de una manera que hace que la programación de pares sea algo poco.
Por último, ¿qué dices de los grupos de piratería (no grupos de piratas de sombrero negro, sino grupos de sombrero blanco o gris), que saben mucho más sobre seguridad y desarrollan software de seguridad de una manera que solo coincide con los programadores más especializados de ciertos departamentos gubernamentales.
fuente