definición:

El software de código abierto (OSS) es un software comercial cuya propiedad total se obtiene simplemente aceptando cumplir con la licencia de OSS adjunta, sin la verificación inmediata de un tercero. Aceptar la Licencia de OSS permite a las personas, corporaciones o entidades gubernamentales copiar, distribuir y ejecutar aplicaciones de OSS para su código fuente legible por humanos con la frecuencia y amplitud que sea necesaria, y otorgar licencia tras licencia, según los requisitos de distribución, para extender O extender la aplicación OSS. Los pagos por OSS son indirectos y en la mayoría de los casos incluyen el acuerdo de compartir el valor con la comunidad que mantiene la aplicación en forma de correcciones y extensiones de la aplicación.

Palabras clave:

FOSS, software libre y de código abierto, software de código abierto, OSS

MITRE SE Funciones y expectativas:

Los ingenieros de sistemas (SE) de MITRE deben comprender los posibles beneficios, riesgos y limitaciones de aplicar el software de código abierto (OSS) y los procesos de soporte relacionados para la construcción de grandes sistemas y sistemas de sistemas. Para garantizar el cumplimiento de las reglamentaciones federales que exigen la selección y el uso de software comercial aplicable en lugar de nuevos desarrollos, deben comprender cómo y dónde se aplican las capacidades de OSS a la integración del sistema, la asistencia al usuario final y la configurabilidad. Deben comprender cómo se compara el OSS con otras formas de software comercial en términos de costo de adquisición, soporte a largo plazo, escalabilidad, adaptabilidad, seguridad y resiliencia frente a requisitos cambiantes. Los SE deben tener una comprensión particular de las propiedades de seguridad del OSS en los niveles de ingeniería y proceso, y cómo estas propiedades se comparan con otros tipos de software comercial y gubernamental. Deben comprender el estado de certificación de los principales paquetes de OSS y cómo funciona la certificación en el modelo de propiedad distribuida de OSS. Deben saber cómo interactuar satisfactoria y productivamente con la comunidad de soporte de OSS, que utiliza una economía basada en el trueque en la que se pagan las correcciones de software y las extensiones de la funcionalidad de la aplicación en lugar de tarifas.

fondo

En el campo de la ingeniería de software de la ingeniería de sistemas y en la empresa de ingeniería intensiva en información, pocos temas tienen más probabilidades de provocar una respuesta más fuerte que el software de código abierto. Esta reacción proviene en gran medida del modelo de propiedad de OSS basado en la comunidad, en el que cualquiera que acepte seguir la licencia de OSS correspondiente recibe la misma propiedad que cualquier otro usuario. Esta descentralización de la autoridad de cambio de ingeniería viola una de las suposiciones más antiguas y arraigadas de la ingeniería de software: que el software de alta calidad, altamente confiable y digno de confianza solo se puede producir si se desarrolla utilizando software de primer nivel bien controlado y centrado en la autoridad. Es posible - proceso de desarrollo a la baja. OSS no solo abandona la necesidad de una autoridad de desarrollo centralizada, sino que también cambia radicalmente este concepto al otorgar el control del proceso de desarrollo a la colaboración informal de los programadores. Debido a que en la ingeniería de software, los codificadores a menudo son vistos como los actores con menos probabilidades de comprender los requisitos y más propensos a violar las reglas diseñadas para garantizar la integridad, calidad, mantenibilidad y seguridad del sistema, el control de cambios se otorga al proceso del codificador. A menudo visto con desconfianza.

Sin embargo, esta visión está cambiando. La primera razón es la creciente comprensión de que, así como las economías de mercado planificadas no pueden competir con las economías de libre mercado en el fomento de la innovación y el uso eficiente de los recursos, la gestión estrictamente centralizada de los grandes esfuerzos de desarrollo de software es menos eficaz que fomentar la innovación y la adaptación locales. El OSS fomenta esta innovación local y hace que los resultados legibles por humanos de la innovación local estén fácilmente disponibles para inspección y análisis en cualquier nivel deseado.

Otra razón es pragmática. El uso de OSS es común tanto en sistemas privados como gubernamentales y ha estado en uso durante muchos años [1]. El software de comunicaciones (TCP/IP) que originalmente hizo posible Internet fue el OSS, al igual que muchos de los primeros sistemas de servidor que proporcionaban datos útiles. Microsoft es una de las muchas empresas comerciales que hacen un amplio uso del software de código abierto para crear y expandir sus líneas de productos. Internet Explorer es un ejemplo bien conocido de una utilidad de Microsoft que se basa en gran medida en OSS. Esencialmente, todos los productos modernos de Apple, desde Mac hasta iPod y iPhone, se basan en OSS con una capa delgada de software personalizado encima. Google es otro líder de la industria que usa mucho OSS en productos internos y comerciales. Apple y Google también son excelentes ejemplos de cómo el uso efectivo de OSS puede permitir que los diseñadores costosos se centren no en mantener el código heredado, sino en desarrollar funciones completamente nuevas, lo que permite una innovación más rápida. Finalmente, casi todos los equipos de red y cajas de hardware personalizadas que se venden en el mercado abierto hoy en día se construyen en su mayoría o en su totalidad con OSS. OSS es popular entre los proveedores de equipos por su bajo costo, fácil escalabilidad, flexibilidad para adaptarse a nuevos entornos, amplia gama de funciones disponibles y confiabilidad comprobada en el campo.

Beneficios y uso del gobierno

El 16 de octubre de 2009, el Departamento de Defensa de EE. UU. (DoD) publicó una política actualizada sobre el uso de software de código abierto (OSS) [2, 3]. Esta política enfatiza y explica el estado legal de OSS como una forma de software comercial, lo que significa que cumple con la ley de EE. UU. (10 USC 2377), el derecho de preferencia para comprar artículos comerciales. No incluir una evaluación de las opciones de OSS al revisar las opciones comerciales para reducir costos y mejorar la calidad de los sistemas del Departamento de Defensa puede violar esta ley sin darse cuenta. El sitio para desarrolladores de la Casa Blanca [4] dirige a los desarrolladores de software a los sitios del Proyecto de la Casa Blanca (desarrollo de código abierto distribuido) [5] y Drupal (blogs de código abierto) en GitHub [6, 7].

Mejores prácticas y lecciones aprendidas

Lea y comprenda la página web del Departamento de Defensa de EE. UU. sobre software libre y de código abierto (FOSS) [8]. El Departamento de Defensa de EE. UU. pasó varios años creando tres documentos que analizan y describen el papel del OSS en el sistema DoD. El sitio cubre la política del Departamento de Defensa sobre código abierto, preguntas frecuentes sobre el rol federal y el estado legal del código abierto, y una encuesta de OSS sobre su amplia popularidad e importancia para el Departamento de Defensa que se remonta a 2003. La página web se escribió de manera genérica y se aplica con poca variación a otros departamentos y agencias federales. En particular, los ingenieros de software de MITRE Systems que trabajan con el Departamento de Defensa deben asegurarse de haber revisado la Declaración de política del Departamento de Defensa, publicada en el sitio el 16 de octubre de 2009.
Cuanto más grande sea la comunidad que soporte OSS, mayor será la reducción en los costos de soporte a largo plazo. Esta regla general está en el corazón de cómo OSS proporciona ventajas significativas de costo y capacidad al construir sistemas grandes. Vale la pena señalar que no tiene nada que ver con la capacidad de modificar el código en sí mismo y, de hecho, podría verse seriamente afectado por un proyecto inmaduro interesado en modificar el código fuente de OSS. Debido a que OSS admite el trabajo como federación, es más rentable para los miembros individuales cuando la federación es lo más grande posible. Estos beneficios de costos se agravan aún más si la comunidad de soporte de OSS es lo suficientemente grande como para incluir expertos de clase mundial en funcionalidades específicas de OSS, ya que estos miembros a menudo pueden resolver problemas difíciles en una fracción del tiempo requerido por un soporte más amplio.
Evite la proliferación de licencias de OSS. Ya hay demasiadas licencias OSS. No importa cuán tentador pueda ser para las organizaciones crear sus propias licencias de OSS únicas, cada licencia solo confundirá aún más a los desarrolladores, abogados y gerentes de proyecto que tienen que lidiar con ella, y también tenderá a segmentar a los desarrolladores disponibles para respaldar esas nuevas licencias. piscina. Cuatro tipos principales de licencia suelen ser suficientes:
- Licencia Pública General GNU1 (GPL): Esta popular licencia requiere que cualquier nuevo código fuente creado usando el código fuente GPL debe estar bajo licencia GPL, es decir, debe retribuir a la comunidad OSS que creó el primer código fuente. Si bien esta característica hace que la GPL sea controvertida, también es muy buena para estabilizar la infraestructura profunda de un sistema o red porque elimina cualquier motivo de lucro para cambiarlo arbitrariamente. Partes del kernel de Linux se crean bajo la licencia GPL, lo que demuestra otra característica de la GPL: la capacidad de usar interfaces estándar para los componentes de la GPL sin usar el software GPL.
- Licencia pública general reducida de GNU (LGPL): esta es una variante de la GPL que permite que los componentes de la GPL se incrusten como "componentes de biblioteca" en código que no es GPL. Es popular entre las pequeñas empresas a las que les gusta el modelo GPL pero no quieren impedir que las empresas usen o compren componentes de su software.
- Berkeley Software Distribution (BSD)/Apache: estas licencias permisivas permiten a las empresas "capturar" copias del código fuente y tratar esas copias, y cualquier cambio que les hagan, como propiedad. Apple ha aprovechado esta característica de la licencia BSD para crear su línea actual de computadoras personales Mac, iPods y iPhones. Debido al alto costo de mantener grandes cantidades de código fuente solo, la mayoría de los contribuyentes de licencias BSD/Apache continúan brindando soporte a sus productos OSS en modo comunitario. Para los ingenieros de sistemas, las licencias BSD y Apache deben verse como herramientas para garantizar que las pequeñas empresas involucradas en el trabajo de sistemas grandes tengan un fuerte incentivo de costos para adaptar la funcionalidad OSS disponible bajo las licencias BSD o Apache. Por ejemplo, elegir un modelo de licencia similar a BSD para la versión inicial del software de comunicaciones de Internet (TCP/IP) ayudó a que el código fuera aceptado por docenas de pequeñas y grandes empresas con redes únicas y lanzar la primera Internet funcional.
- Sin licencia (Código del gobierno): Este es un estado legalmente requerido para el código desarrollado por empleados del gobierno. Si bien se aproxima a la licencia BSD o Apache al permitir que cualquier persona la use, causaría una confusión considerable si un individuo o una empresa eligiera registrar los derechos de autor de un trabajo completo "tal cual" sin reconocer su origen gubernamental.
No asuma que los abogados involucrados entenderán la licencia de OSS. Los abogados con poco conocimiento de software, y más específicamente de cómo el software se traduce de un código fuente legible a un código de máquina ejecutable, tendrán dificultades incluso para leer la licencia GPL y la licencia LGPL, y mucho menos para comprenderlas. Las licencias BSD y Apache evitan los detalles de la estructura del software y son más fáciles de entender para los abogados. Por lo general, los abogados prefieren BSD y Apache por una sola razón: los conocen. Esta desafortunada situación está mejorando lentamente, pero en el caso de GPL y LGPL, los programadores aún saben más sobre el significado y las implicaciones de estas licencias que los abogados encargados de evaluar sus implicaciones. Las empresas sociales deben ser conscientes de esta posible desconexión y, si es posible, remitir a los asesores a los documentos pertinentes, como las Preguntas frecuentes (FAQ) en el sitio web DoD FOSS[3].
Utilice OSS para estabilizar la infraestructura compartida. Aquí, la infraestructura se refiere a grandes sistemas o componentes de software de sistemas que establecen funciones básicas como la creación de redes y el intercambio de datos. Como demuestra la historia de los proyectos de Internet más exitosos de todos los proyectos de infraestructura de sistemas, el uso de OSS para fomentar el intercambio de capacidades fundamentales puede ser una herramienta poderosa para facilitar el surgimiento de nuevas capacidades más complejas y, a menudo, inesperadas. infraestructura. El OSS también puede ayudar a estabilizar los grandes sistemas al eliminar los incentivos de ganancias para que las empresas cambien las funciones arbitrariamente o fijen a los clientes en conjuntos de funciones únicas. Finalmente, dado que la infraestructura suele ser la pieza de código menos innovadora, el uso de OSS libera recursos intelectuales para un nuevo trabajo de diseño más innovador.
Use OSS para ayudar a enfocar recursos costosos en la innovación. El resultado final de descomponer problemas "resueltos" de un sistema grande y trasladarlos a OSS se muestra en la estructura piramidal de la Figura 1. El concepto principal del diagrama es que al desglosar las capacidades que son estables, cambian con relativa lentitud y cuentan con el respaldo adecuado de la comunidad de OSS, las organizaciones pueden sacar a los diseñadores y programadores que tanto necesitan de los roles de soporte. Pueden trasladarlos a funciones más innovadoras que se centren en las necesidades más críticas de la organización, a menudo aprovechando las múltiples capacidades exploratorias y de creación de prototipos del OSS (consulte las siguientes dos entradas).

Figura 1. La pirámide arquitectónica I-4

Se recomienda el uso de puestos de contacto de OSS. Los enlaces de OSS son programadores expertos encargados de rastrear, participar y utilizar el conjunto de aplicaciones de OSS correspondiente. Un enlace de OSS con experiencia puede ayudar a garantizar que las necesidades de una organización sean comprendidas y respaldadas por su comunidad de soporte, y puede proporcionar asesoramiento interno rápidamente disponible sobre si una combinación de capacidades de OSS cumple o respalda los requisitos identificados a nivel del sistema y cómo lo hace. Los puestos de enlace de OSS no son estándar en términos de descripciones de trabajo de ingeniería de software estándar, pero brindan una de las formas más efectivas de garantizar que los requisitos amplios no terminen traduciéndose de manera inapropiada en proyectos de desarrollo de software a largo plazo, que en el mejor de los casos son simplemente copiado a través de Funciones ya disponibles en OSS.
Conozca los beneficios del OSS para la creación de prototipos exploratorios. Por muchas de las mismas razones por las que OSS es una poderosa herramienta exploratoria de creación de prototipos, también proporciona un enfoque poderoso para los problemas de integración típicos de los problemas de ingeniería de sistemas grandes y complejos. OSS incluye paquetes y lenguajes diseñados específicamente para ayudar a traducir entre tipos de datos y protocolos de comunicación diferentes y, a menudo, inesperados. Para sistemas grandes y complejos, una de las ventajas más importantes de tales herramientas OSS habilitadas para traducción es que pueden usarse para ayudar a simular las entradas e interacciones esperadas de componentes más antiguos y obsoletos de tales sistemas. Dado que cambiar dichos componentes heredados suele ser costoso y arriesgado, poder crear interfaces tan "suaves" para sistemas heredados mientras se mantienen los protocolos y estándares actuales en el resto del sistema es muy útil para minimizar el nivel general de valor de riesgo para el artículo.
Conozca los beneficios de OSS para sistemas e integración de sistemas. Por muchas de las mismas razones por las que OSS es una poderosa herramienta exploratoria de creación de prototipos, también proporciona un enfoque poderoso para los problemas de integración típicos de los problemas de ingeniería de sistemas grandes y complejos. OSS incluye paquetes y lenguajes diseñados específicamente para ayudar a traducir entre tipos de datos y protocolos de comunicación diferentes y, a menudo, inesperados. Para sistemas grandes y complejos, una de las ventajas más importantes de tales herramientas OSS habilitadas para traducción es que pueden usarse para ayudar a simular las entradas e interacciones esperadas de componentes más antiguos y obsoletos de tales sistemas. Dado que cambiar dichos componentes heredados suele ser costoso y arriesgado, poder crear interfaces tan "suaves" para sistemas heredados mientras se mantienen los protocolos y estándares actuales en el resto del sistema es extremadamente valioso para minimizar el nivel general de riesgo del proyecto.
Trate la licencia OSS como cualquier otra licencia propietaria. Es muy inusual que un gran proyecto de desarrollo federal considere violar seriamente sus acuerdos de licencia con grandes empresas de software propietario como Oracle, IBM o Microsoft. Irónicamente, sin embargo, en parte debido al concepto erróneo común de que OSS se refiere a software "gratuito" sin ataduras, es sorprendentemente común que los desarrolladores violen la licencia OSS, como eliminar la licencia OSS del código fuente. No solo es una muy mala idea desde el punto de vista de la calidad del desarrollo y el soporte a largo plazo, sino que también es ilegal y poco ético, y podría dar lugar a acciones legales por parte de grupos de vigilancia como la Free Software Foundation (FSF) [8]. Más importante aún, altera el modelo federado de participación y contribución, que es donde radica el verdadero potencial de reducción de costos de OSS. Los ingenieros de sistemas deben hacer todo lo posible para garantizar que, en cualquier proyecto, la licencia OSS se respete en la misma medida que cualquier otra licencia comercial.
Minimice la necesidad de software nuevo cuando construya sistemas grandes. Históricamente, los proyectos de software han utilizado líneas de código escritas como una forma de medir el progreso, lo que lleva a una tendencia a pensar que más código es algo bueno. Sin embargo, dado que cada nueva línea de código conlleva un costo a largo plazo y una carga de confiabilidad que puede durar décadas, el objetivo real debe ser el opuesto: las SE siempre deben encontrar formas de minimizar la necesidad de software nuevo y único. requerido, pero debe ser relativamente pequeño, poderoso y único para el sistema que se está creando. Las funciones comunes, como el acceso a archivos ordinarios o la comunicación de red estándar, no se incluyen en esta categoría y siempre deben manejarse mediante la obtención de un software propietario o OSS estable y bien estandarizado.
Totalmente en desacuerdo con cualquier noción de OSS como "código fuente gratuito" para acelerar el desarrollo interno. Los costos de soporte de código a largo plazo siempre se ven eclipsados por cualquier tipo de software. Solo por esta razón, ver el OSS como un código fuente "gratuito" para acelerar los objetivos de desarrollo a corto plazo es una visión miope y francamente peligrosa. Una buena analogía es esta: si su organización obtuviera todo el código fuente de Microsoft Windows de forma gratuita, pero estipulara que usted mismo tiene que corregir todos los errores y realizar todas las mejoras a partir de ese momento, ¿aceptaría la oferta? Los paquetes grandes de OSS son al menos tan complejos como Windows, por lo que adoptar al azar dicho código fuente en un pequeño proyecto interno incurriría en costos de soporte equivalentes a una bomba de relojería muy grande y que funciona rápidamente. Una regla general útil de tres pasos es probar primero el ejecutable, luego el soporte de la comunidad y finalmente el código nuevo:
- Pruebe siempre la versión ejecutable de OSS primero. OSS tiende a ser más configurable que las alternativas, por lo que el primer paso es consultar a un experto para ver si puede configurar fácilmente una aplicación OSS para satisfacer sus necesidades descargando OSS en forma binaria de "versión estándar". (Es posible que aún desee descargar y compilar la fuente localmente por razones de seguridad).
- A continuación, intente enviar cambios no confidenciales a la comunidad de soporte. Si alguna funcionalidad de una aplicación OSS debe cambiarse o extenderse absolutamente hasta el nivel del código fuente, intente expresar los cambios deseados de una manera que pueda enviarse directamente a la comunidad que respalda la aplicación. Este enfoque no solo reduce la necesidad de soporte de código fuente a largo plazo, sino que también ayuda a construir relaciones más sólidas con la comunidad de soporte.
- Solo como último recurso, desarrolle sus propios módulos. En esos casos excepcionales en los que los cambios de código nunca deben hacerse públicos, busque formas de desarrollar módulos independientes. Evite incluir cualquier código fuente OSS en tales módulos si es posible. Cada vez que se actualiza el OSS original, se debe verificar y actualizar cada línea del código fuente del OSS incluido en el nuevo módulo, lo que también complica innecesariamente el estado legal de los módulos.
Evite publicar el código del gobierno como OSS con demasiada indiferencia. Los proyectos gubernamentales responsables de productos GOTS (government-off-the-shelf) no confidenciales a menudo encuentran muy atractivas las funciones de soporte comunitario de OSS y se preguntan si pueden simplemente lanzar sus productos GOTS bajo la licencia OSS para explotar Fast menos costoso y más vulnerable. Ventaja Soporte a largo plazo para correcciones y mejoras en algunos proyectos OSS. La respuesta a esta pregunta es simple: no. Los valiosos atributos del soporte de OSS provienen de una comunidad que ya está interesada en el producto, y la valiosa modularidad y flexibilidad de OSS provienen de una comunidad de estas personas que se han desarrollado a lo largo de los años. Simplemente hacer un OSS de un producto GOTS cambiando la licencia y publicándolo en el sitio web expondría todos sus defectos a cualquier pirata informático interesado, pero no necesariamente atraería el interés de los seguidores, quienes en cualquier caso seguramente estarían interesados en Fuente desconocida el código es confuso. Una mejor manera de reemplazar las aplicaciones GOTS es buscar configuraciones de herramientas OSS existentes que se puedan usar para aproximar la funcionalidad GOTS. Luego intente comenzar a construir una nueva comunidad en torno a esa configuración como una emulación o extensión con todas las funciones de la herramienta GOTS original.
Fomentar una comprensión realista de la seguridad de todo el software comercial. Si el software se vende o distribuye como código binario, su estado de seguridad en el mundo moderno no es diferente al software distribuido como código fuente legible por humanos. La razón es que las herramientas modernas de piratería apuntan directamente al software en forma binaria para tratar de romperlo, lo que hace que la forma binaria sea superior en algunos aspectos a la forma legible por humanos, que es mucho más lenta de analizar. Por lo tanto, la preocupación comúnmente expresada de que el OSS no puede hacerse seguro porque "el código fuente está disponible" no tiene sentido.
- En cambio, muchos procesos propietarios que mantienen el código fuente aislado del mundo están plagados de problemas en múltiples niveles, lo que brinda a las personas la oportunidad de insertar cambios que podrían comprometer seriamente la seguridad de dichos sistemas. La conclusión es la siguiente: la seguridad es un proceso que se evalúa mejor en los detalles prácticos de cada caso; ya sea que se desarrolle utilizando métodos propietarios o de la comunidad OSS, cambia lo que debe examinarse. Los métodos propietarios tienen la ventaja de generar más dinero, mientras que los métodos comunitarios son más visibles para más usuarios. Cuando es activo y global, el OSS también puede atraer a expertos que tienen más probabilidades de detectar intentos de infiltración.
- El contraargumento de que el OSS siempre es más seguro porque "miles de ojos" lo están mirando también es falso por una simple razón: el hecho de que el código fuente esté publicado en un sitio web no significa que alguien lo esté mirando. El software propietario también puede promocionarse como más seguro porque ha sido "certificado" de una forma u otra. Desafortunadamente, debido a que ningún proceso de certificación de software ha demostrado en estudios de campo evaluados científicamente producir software que sea más seguro o más confiable que el software no certificado, no está claro si estas certificaciones implican que la empresa puede hacer algo. asumir el alto costo de dicha certificación. Las certificaciones se aplican de manera inconsistente y los escritorios federados a menudo ejecutan sistemas y aplicaciones que nunca han sido certificados o que fueron certificados hace tanto tiempo que la certificación ya no se aplica. El OSS a veces se considera inseguro porque "cualquiera puede insertar cambios en el código". Si bien es cierto que cualquiera puede realizar los cambios que desee en su copia del código fuente de OSS, la realidad es que los proyectos de OSS grandes y activos, como Linux, tienen procesos de control de código altamente automatizados y bien protegidos que solo permiten que el código entre en el código principal. El proceso es examinado rigurosamente por algunos de los principales expertos en kernel de sistemas operativos del mundo, un nivel de verificación que empequeñecerá a la mayoría de los procesos de control y revisión de código propietario.
Certificaciones de software: búsquelas, apoye para obtenerlas, pero nunca confíe en ellas. Como se señaló anteriormente, no hay evidencia científica de que la certificación de software tenga algún impacto en la confiabilidad o seguridad del software a nivel de campo. Aún así, son necesarios en muchas situaciones. Para OSS, empresas como IBM ayudan a proporcionar la certificación. Por lo tanto, las SE deben buscar certificaciones para el OSS relevante por si acaso, y ver cómo se comparan con los equivalentes propietarios. Los proyectos de interés también pueden ayudar a los grupos de OSS a lograr la certificación, por ejemplo, a través de pequeñas empresas propietarias que normalmente se ocupan del lado comercial del uso de componentes específicos de OSS. Finalmente, independientemente de si un componente de software comercial es OSS y está certificado, no se debe asumir que la seguridad general de un sistema de software en red ha sido probada; múltiples capas de seguridad son absolutamente necesarias.

Este artículo: https://architect.pub/mitre-open-source-software
Discusión: Knowledge Planet [Chief Architect Circle] o agregue la trompeta de WeChat [ca_cto] o agregue el grupo QQ [792862318]
sin publico	【jiagoushipro】【Super Arquitecto】 Brillante explicación gráfica y detallada de la metodología de la arquitectura, la práctica de la arquitectura, los principios técnicos y las tendencias técnicas. Te estamos esperando, por favor escanea y presta atención.
Trompeta WeChat	[ca_cea] Comunidad de 50 000 personas, que discute: arquitectura empresarial, computación en la nube, big data, ciencia de datos, Internet de las cosas, inteligencia artificial, seguridad, desarrollo completo, DevOps, digitalización.
grupo QQ	[285069459] Intercambio en profundidad de arquitectura empresarial, arquitectura empresarial, arquitectura de aplicaciones, arquitectura de datos, arquitectura técnica, arquitectura de integración, arquitectura de seguridad. Y diversas tecnologías emergentes como big data, cloud computing, Internet de las Cosas, inteligencia artificial, etc. Únase al grupo QQ para compartir valiosos informes y productos secos.
numero de video	[Super arquitecto] Comprenda rápidamente los conceptos, modelos, métodos y experiencias básicos relacionados con la arquitectura en 1 minuto. 1 minuto al día, la estructura es familiar.
planeta del conocimiento	[Círculo de arquitectos en jefe] Pregunte a los grandes nombres, póngase en contacto con ellos o comparta información privada.
Himalaya	[Super arquitecto] Aprenda sobre la última experiencia de arquitectura e información de tecnología negra en la carretera o en el automóvil.	[Momentos inteligentes, el Sr. Arquitectura les hablará de tecnología negra]
planeta del conocimiento	Conoce más amigos, lugar de trabajo y chat técnico.	Knowledge Planet【Lugar de trabajo y tecnología】
LinkedIn	Harry	https://www.linkedin.com/in/architect-harry/
grupo de LinkedIn	Grupo de arquitectura de LinkedIn	https://www.linkedin.com/groups/14209750/
Weibo‍‍	【Súper Arquitecto】	momento inteligente‍
bilibili	【Súper Arquitecto】
Tik Tok	【cea_cio】Super Arquitecto
trabajador rapido	【cea_cio_cto】Super Arquitecto
pequeño libro rojo	[cea_csa_cto] Súper Arquitecto
sitio web	CIO (director de información)	https://cio.ceo
sitio web	CIO, CTO y CDO	https://cioctocdo.com
sitio web	Arquitecto práctica compartida	https://arquitecto.pub
sitio web	Compartir el desarrollo de la nube del programador	https://pgmr.cloud
sitio web	Comunidad de arquitectos jefe	https://jiagoushi.pro
sitio web	Plataforma de desarrollo y desarrollo de aplicaciones.	https://apaas.dev
sitio web	Red de información sobre el desarrollo	https://xinxi.dev
sitio web	súper arquitecto	https://jiagou.dev
sitio web	Formación técnica empresarial	https://peixun.dev
sitio web	Libro del programador	https://pgmr.pub
sitio web	chat de desarrollador	https://blog.developer.chat
sitio web	Colección CPO	https://cpo.trabajo
sitio web	jefe de seguridad	https://cso.pub‍
sitio web	CIO genial	https://cio.cool
sitio web	información de CDO	https://cdo.fyi
sitio web	Información de CXO	https://cxo.pub

Gracias por su atención, reenvío, me gusta y ver.

[Gobernanza del software de código abierto] MITRE : Software de código abierto